Springe zum Inhalt

In einer Standard-WordPress-Installation ist es sehr einfach möglich, die Namen der unterschiedlichen Autoren herauszubekommen. An die URL der Seite hängt man dazu ein /?author=1, /?author=2 usw. an. Diese Informationen könnten von mißliebigen Zeitgenossen unter Umständen dann dazu verwendet werden, Logins mit nun bekannten korrekten Benutzernamen auszuprobieren.

Verhindern kann man den Zugriff auf die Namen der unterschiedlichen Autoren (und damit auch die Information, ob es evtl. nur einen einzigen Autor im Blog gibt) mit dem Umschreiben der URL.

Apache

In der Datei .htaccess trägt man dazu folgendes ein:

Das Modul mod_rewrite muss aktiv sein, damit diese Konfigurationsanweisungen ausgewertet werden.

Nginx

In der entsprechenen Konfigurationsdatei für den Server trägt man folgendes ein:

Danach werden alle Anfragen zur Auflistung der Autoren auf die Hauptseite der WordPress-Installation umgeleitet.

So merkwürdig der Titel klingt, denn im allgemeinen möchte man die Seiten seiner Webseite ja eher gerne in den Google-Suchmaschinen-Index aufgenommen sehen, so ergibt sich doch ab und an die Anforderung, eine Seite oder z.B. Bilder nicht in den Google-Index aufnehmen zu lassen.

Verzeichnisse mit robots.txt ausschließen

Früher konnte man das relativ einfach durch einen Eintrag in der Datei robots.txt, welche im Hauptverzeichnis der Webseite liegen muss regeln. Zu beachten ist jedoch, dass die Crawler der verschiedenen Suchmaschinen sich nicht daran halten müssen. Google jedenfalls beachtete den Inhalt dieser Datei. So z.B. konnte man mit folgendem Eintrag ein bestimmtes Verzeichnis ausschließen:

In der ersten Zeile wird festgelegt, für welche Crawler folgende Angaben gelten sollen. Hier im Beispiel durch die Angabe eines Sterns für alle Crawler. In der zweiten Zeile erfolgt dann die Angabe eines Verzeichnisses, welches vom Crawler nicht besucht werden soll.

Einsatzgebiete für diese Methode könnte etwa sein, das Verzeichnis mit JavaScript-Dateien vom Crawlen auszuschließen.

Leider kann diese Methode seit kurzem nicht mehr verwendet werden, wenn Pfade in der robots.txt eingetragen werden sollen, deren Inhalte für das Rendern der Webseite in einem Browser erforderlich sind, so z.B. oben erwähnte JavaScript-Dateien. Google versucht seit längerem, die Seiteninhalte anhand ihrer grafischen Darstellung zu analysieren. Dazu muss die entsprechende Seite natürlich von Google gerendert werden. Ressourcen, auf die nicht zugegriffen werden kann, erzeugen dann eine Fehlermeldung.

Seiten mit META-Angaben ausschließen

Die bewährte Methode, um Seiten von der Indexierung auszuschließen, ist eine spezielle META-Angabe im Kopf der HTML-Datei zu machen. Innerhalb des Elements <head> trägt man dazu z.B. Folgendes ein:

Damit wird der Googlebot angewiesen, die Datei nicht zu indexieren. Ohne weitere Angaben folgt der Crawler jedoch den Links in der Datei, um andere Seiten zu finden. Weitere Möglichkeiten, um dem Googlebot z.B. auch das Folgen der Links zu verbieten finden sich in der unten angegebenen Google-Hilfeseite.

Problematisch bei dieser Methode ist, dass sie nur auf HTML-Dateien angewendet werden kann. Bilder und JavaScript-Dateien haben keinen solchen Eintrag. Hier bleibt nur folgendes Verfahren:

Ressourcen mit HTTP-Headerangaben ausschließen

Für diese Methode wird der Zugang zur Webserverkonfiguration benötigt. Der Webserver muss angewiesen werden, für die auszuschließenden Seiten oder Dateien einen speziellen Antwort-Header einzufügen. Um die Seite oder Datei komplett vom Index auszuschließen muss z.B. folgender HTTP-Header gesendet werden:

Die Angaben hinter X-Robots-Tag sind dabei die gleichen, wie sie auch in der robots.txt verwendet werden können.

Apache - X-Robots-Tag einfügen

An ensprechender Stelle der Webserverkonfiguration muss z.B. Folgendes eingetragen werden:

Zu beachten ist, dass für die Direktive "Header" das Modul mod_headers im Apache geladen sein muss.

Nginx - X-Robots-Tag einfügen

Analog wird in die Serverkonfiguration von Nginx Folgendes eingetragen:

Überprüfen kann man die korrekte Ausgabe der HTTP-Header anschließend mit dem Browser. In Firefox und auch Chrome kann durch Drücken von F12 ein Fenster für Webentwickler geöffnet werden. Im Tab Netzwerk und nach dem Neuladen der jeweiligen Webseite kann man sich alle gesendeten wie auch vom Webserver empfangenen HTTP-Header anschauen.

Weitere Informationen zu diesem Thema findet man auf einer entsprechenden Hilfeseite von Google.

Wer Memcached zusammen mit Nginx oder PHP einsetzt, der möchte in der Konfigurationsphase sicher einmal debuggen, ob die Einstellungen auch korrekt sind und Daten an Memcached übergeben und von dort gelesen werden. Leider bietet Memcached kein Kommandozeilentool, mit dem man sich einfach Statistiken zu Memcached anzeigen lassen könnte. Es existiert zwar ein Munin-Plugin, welches eine einfache Grafik der Memcached-Auslastung anzeigt, Inhalte sieht man dort jedoch auch nicht.

Mit phpMemcachedAdmin ist es möglich, umfangreiche Statistiken zu Memcached aufbereitet auf einer Webseite zu erhalten. Es lassen sich mehrere Memcached-Server verwalten und auch Inhalte zu einzelnen Keys abrufen. Außerdem können Kommandos an den Memcached-Server geschickt werden.

Screenshot phpMemcachedAdmin

Unter See this Server Stats kann auf die einzelnen Items in Memcached zugegriffen werden.

Titelbild: MT4C1024-HD by ZeptoBars

Mit Linux Mint 17 kommt auch Apache 2.4 auf den Rechner. Gegenüber der Version 2.2 gab es auch Änderungen bei der Vergabe von Zugriffsberechtigungen auf URLs. Leider bringt die Installation von Munin nur Einstellungen mit, die kompatibel mit der Apache Version 2.2 sind. Nach der Installation auf dem lokalen Host erscheint beim Zugriff auf http://localhost/munin nur ein "Forbidden".

Folgender Eintrag in der Datei /etc/apache2/conf-enabled/munin.conf innerhalb <Directory /var/cache/munin/www> schafft Abhilfe:

Nach einem Neustart des Apache können dann wieder die Munin-Auswertungen angesehen werden.

Ein Konfigurationsbeispiel eines name-based vhosts aus der Praxis:

  • mehrere Subdomains zur Domain example.com
  • jede eigene Subdomain hat ihren eigenen name-based virtuellen Hosts in Apache eingestellt
  • reverse Mapping im DNS ist so eingestellt, dass example.com zur gleichen Adresse wie www.example.com auflöst

Was passiert nun, wenn http://example.com angesteuert wird?

Der Apache sucht sich den ersten virtuellen Host heraus, den er beim Starten eingelesen hat und liefert diese Seite aus. Das ist natürlich nicht im Sinne des Erfinders.

Abhilfe schafft die ServerAlias-Direktive, die in der jeweiligen vhost-Konfigurationsdatei anzugeben ist. Mit

in der vhost-Definition von www.example.com wird beim Aufruf von http://www.example.com oder http://example.com anschließend die richtige Seite ausgeliefert.