Suchmaschinen und HTTP-Header

Jeder Seitenaufruf wird durch einen sog. HTTP-Request, d.h. die Anforderung einer genannten Datei, ausgelöst. Das eine URL aufrufende Programm, z.B. der Browser eines Anwenders oder der Spider einer Suchmaschine, schickt eine Anfrage an einen Web Server, die u.a. folgende Dinge enthält:

gewünschte URL,
Version des von der Anwendung beherrschten HTTP-Protokolls,
Host-Namen des Servers für den Fall dass auf einer Maschine, die sog. virtuelle Server betreibt, eine Vielzahl von Domains untergebracht ist,
fast immer einen sog. User-agent oder Kennung des Programms, z.B. Mozilla/3.04 (X11; I; Linux 2.0.35 i686)
evtl. den Server betreffende Cookies
ggfls eine verschlüsselte Login/Passwort-Kombination,
gefolgt von einer den Abruf beendenden Leerzeile.

GET / HTTP/1.1
Host: red.kso.co.uk
User-agent: Mozilla/3.04 (X11; I; Linux 2.0.35 i686)

Der Web Server beantwortet die Anfrage mit der von ihm beherrschten HTTP-Versionsnummer, einem Status-Code, und optional Serversoftware-Kennung, dem Datum [Last-Modified] der letzten Aktualisierung der URL, Länge [Content-Length] der gelieferten Daten und je nach Fähigkeit zusätzliche Informationen.

Entscheidend für die Suchmaschinen-Optimierung ist bei manchen Suchmaschinen das Datum der letzten Aktualisierung, die Datei-Länge [d.h. Zahl der gelieferten Bytes] und evtl. der sog. ETag, eine dynamisch vom Web Server berechneten Chiffriersumme.

Werden Seiten dynamisch durch Programmausführung erstellt, liefert der Web Server, je nach Konfiguration, das augenblickliche oder kein Datum. Beide Alternativen legen nahe, dass es sich um eine dynamisch erzeugte Seite handelt. Da die "Dateigrösse", d.h. der Umfang der ausgegebenen Daten, zu Beginn der Programmausführung nicht bekannt ist, fehlt auch diese Angabe oft.

Suchmaschinen, die "gealterte" Seiten bevorzugen, berücksichtigen, bevor überhaupt Vergleiche mit der letzten im Datenbestand gehaltenen Seite angestellt werden, das gelieferte Last-Modified-Datum, Content-Length und seltener den ETag.

HTTP/1.1 200 OK
Date: Thu, 12 Jul 2001 11:06:50 GMT
Server: Apache/1.3.14 (Unix) mod_fastcgi/2.2.8
Last-Modified: Tue, 26 Jun 2001 16:09:17 GMT
ETag: "6200d-769-3b38b3ad"
Accept-Ranges: bytes
Content-Length: 1897
Connection: close
Content-Type: text/html

Wer überwiegend dynamische Seiten liefert, sollte deshalb einen suchmaschinengerechten Satz statischer Seiten bereithalten oder auf dem Server laufende Software so modifizieren, dass gelieferte Seiten nicht als dynamisch erzeugte erkannt werden.

Manche Suchmaschinen benutzen das letzte Aktualisierungsdatum und die vom Webserver gemeldete Dateigrösse bei folgenden Spider-Läufen zu konditionalen Abrufen, d.h. der Server wird beauftragt, die Seite nur dann zu liefern, wenn diese nach dem vom Spider mit der Anfrage übermittelten Datum aktualisiert wurde oder eine andere als die ebenfalls mitgelieferte letzte Dateigrösse hat.

In diesem Fall wird der Seitenabruf durch den Spider präzisiert:

GET /
If-Modified-Since: Tue, 26 Jun 2001 16:09:17 GMT; length=1879
usw...

Befindet Ihr Webserver, dass die Seite zwischenzeitlich nicht verändert wurde, antwortet er mit dem Status-Code 304 statt 200, die Übertragung der eigentlichen Seite unterbleibt.

Gelegentlich sehen Sie in Ihren Protokolldateien HEAD- statt GET-Abrufe. Hierbei wird der Server beauftragt, nur eine Statusmeldung, nicht aber die eigentliche Datei zu schicken. Da viele Programme, die dynamische Seiten erzeugen, hierauf nicht vorbereitet sind, kann der Server in solchen Fällen nur eine Fehlermeldung - Status 500 - liefern. Dass es sich bei solchen URLs um dynamisch erstellte Seiten handelt, ist jetzt kein Geheimnis mehr.

Suchmaschinen-Tutorial: Inhalt
Weiter: Optimieren oder bei Verzeichnissen anmelden?