Die Tücken der robots.txt
(5 votes, average: 4.80 out of 5)
Loading ...Mit der robots.txt können Webmaster die großen Suchmaschinen anweisen, bestimmte Bereiche oder Dateien der Domain nicht zu indizieren. Dass gesperrte Dokumente trotzdem im Index zu finden sind ist bekannt. Am Beispiel des RSS-Reader der Datenkrake Google sorgen zahlreiche Links dafür, dass das gesperrte Dokument ohne Description, Cache-Link und eigentlichem Title in den Suchergebnissen sogar auf Platz Eins steht.
Nun habe ich heute mal geschaut, ob sich Google immer noch als Datenkrake bezeichnet, Antwort ist ja – machen sie. Dann habe ich selbige Suchanfrage “Google RSS” bei Google.com eingegeben und siehe da, das erste Ergebnis ist die Anmeldeseite des Google Reader mit original Titel, Description und Cache-Link, eigentlich ist dieses Verzeichnis ja per robots.txt gesperrt.
Auszug aus der robots.txt von google.com/de:
Warum greift also die robots.txt bei google.de, nicht aber bei google.com?
Die Antwort liegt im Detail… Für die .com-Version fehlt bei genauerer Betrachtung des Screenshot ein “/” am Ende des angezeigten URL. Kleines Zeichen mit großen Auswirkungen, denn nun greift die robots.txt nicht mehr.
Google sollte hier nur als Beispiel dafür dienen, dass Webmaster genauer hinschauen sollten, wenn es um sensible Bereiche geht, die im Google Index nichts verloren haben. Prüfen lässt sich dies zum Beispiel mithilfe Google Webmaster Tools:
Das virtuelle Verzeichnis /feed/ ist gesperrt, nicht aber die virtuelle Datei, die dadurch entsteht, dass der Redirect auf die Version mit “/” fehlt, und die Version ohne “/” angelinkt wird.
Der Beitrag wurde
am Freitag 31. Oktober 2008 um 16:56 veröffentlicht
und wurde unter Google, SEO-Risiken abgelegt.
Du kannst die Kommentare zu diesen Eintrag durch den 
RSS 2.0 verfolgen.
Du kannst einen Kommentar schreiben, oder einen TrackBack auf deiner Seite einrichten.
20. November 2008 um 23:34
Habt Ihr Erfahrung mit der Nutzung von Wildcards in der Robots.txt am Beispiel von SessionIDs, die man nicht indexiert haben möchte.
Welche Version ist richtig, falls ich alle URLs in deren String “sessionID” vorkommt disallowen möchte?
Disallow: /*sessionID
oder
Disallow: /*sessionID*
Der Teufel liegt hier im Detail mit nur einem Zeichen – welches ist also die richtige Alternative?
21. November 2008 um 17:09
Hi Tobias,
Variante 1 müsste schon ausreichen. Der Stern vor “sessionid” ist zwingend notwendig, sofern der string nicht direkt hinter dem Root-Verzeichnis kommt. Der zweite Stern am Ende wie bei Variante 2 kann gesetzt werden, ist aber so wie der Robots Exclusion Standard fuktioniert überflüssig, es wird nicht indiziert, ob dann nun noch die Nummer folgt oder nicht. Wichtig ist nur, dass hinter sessionID kein “/” folgt, was für Session IDs allerdings auch keinen Sinn ergebe. In der Regel folgt ja der Ankündigung einer ID schließlich auch die Nummer nebst =-Zeichen ohne Verzeichnis-Trennung.
Es gehen also hier beide Varianten.
Hast du das schon mal mit Webmaster Tools geprüft?
7. Januar 2009 um 15:57
Sehr interessantes Thema! Ich würde auch Variante 1 empfehlen. Meistens reicht der Eintrag “Disallow /*?” aus, um den gesamten dynamischen Anteil aus dem Weg zu gehen.
27. Januar 2009 um 21:30
Also ich habe es auch bei einem Webshop mit der Variante 1 hinbekommen, dass er die Sessions nicht indexiert.