Bei der Suchmaschine Google rausgeflogen? Einer Website kann kaum etwas Schlimmeres passieren. Dieser Beitrag erzählt, warum das Google-Update „Allegra“ eine Website erst herausgeworfen und dann doch wieder aufgenommen hat.
Das ist einer der Augenblicke, in dem mir viele Filmzitate einfallen. Zum Beispiel „Oops“ – das der Protagonist praktisch jedes Hollywood-Films murmelt, Sekundenbruchteile bevor etwas explodiert. Dieser Augenblick findet statt am 2. Februar 2005. Und es ist gar nicht witzig. Von einer Stunde auf die andere verschwinden die Besucher von der Site, die mein Kollege Markus und ich über Jahre aufgepäppelt haben. Wir können das prima an unserem Besucherzähler sehen: Von 450 auf 80 in zwei Stunden.
Oops.
Schuld an allem ist Allegra. Das Google-Update, das im Februar 2005 für viel Aufruhr unter Webmastern sorgt. In Foren wie Webmasterworld häufen sich die Klagen. Besonders solche Sites sind betroffen, die seit mehreren Jahren – fünf oder sechs – online sind und vor allem eins bieten: Eigenen Content.
Nun ist eigener Content so etwas wie die Lebensversicherung einer Site. Das Credo: „Biete Deinen Lesern einmalige, gute Texte und viel Information. Dann geht’s Dir gut bei Google.“ Doch dieser Glaubensgrundsatz scheint erschüttert. Google hat Content-Seiten nicht mehr lieb.
Einige Sites verschwinden so ausführlich von der Bildfläche, dass die Suche nach dem Namen der Website selbst nur andere Seiten zum Vorschein bringt. Das ist frustrierend, wenn man den eigenen Firmennamen eingibt und nur noch irgendwo auf Seite zwei oder drei der Suchergebnisse zu finden ist.
Aber halt. War da nicht etwas? Genau, Ende Januar nämlich habe ich alle URLs der Homepage durchgehend auf Kleinschrift umgestellt. Aus „www.meineseite.foo/Ein-toller-Text_id100.html“ wurde „www.meineseite.foo/ein-toller-text_id100.html“. An sich nichts spektakuläres. Aber, wie sich später herausstellt, wohl der Tropfen, der das Fass zum Überlaufen bringt.
Alte Sites voller Content
Was haben nun die Sites gemeinsam, denen Allegra den Weg in die Bedeutungslosigkeit zeigt? Die meisten sind schon älter, die meisten haben Content. Viele haben sich in den letzten Jahren weiter entwickelt – und viele zwischendurch ihre URLs umgestellt, viele sind über mehrere Domain-Namen erreichbar, etwa www.meineseite.foo und meineseite.foo. Aha.
Der Verdacht: Google mag es nicht mehr gerne, wenn der gleiche Inhalt mehrfach, also unter verschiedenen Adressen zu erreichen ist. Das Schlagwort „Duplicate Content“ geistert durch die Foren.
Bei unserer Seite bin ich mir nicht sicher: War’s der Duplicate Content oder das Umbenennen der Seite, die für das Verschwinden verantwortlich ist. Inzwischen hat sich experimentell herausgestellt: Sobald ich die URL einer Seite ändere, verschwindet diese erst einmal. Klar, denn für Google ist das eine neue Seite. Und die will erst einmal richtig einsortiert werden. Allerdings fliegt die alte Seite bei dieser Gelegenheit auch aus dem Index heraus. Wohl wegen Duplicate Content.
Aber das ist wohl nicht das einzige Problem. Denn mit der Zeit haben wir mehrfach die Verfahren geändert, wie ein Eintrag aus der Text-Datenbank zu erreichen ist, nämlich über
show.php3?id=100
show.php?id=100
show.php?id=100&title=Toller+Text
Toller_Text_id100.html
Toller-Text_id100.html
toller-text_id100.html
Und all diese Zugriffsmethoden sind jetzt bei Google zu finden. Damit nicht genug, wartet unsere Site auch noch unter drei verschiedenen Domain-Namen auf Besucher. Die sind jeweils auch noch mit oder ohne vorangestelltes www zu finden. Also nochmals zwei Versionen jeder Domain.
Rechnen wir zusammen: sechs URLs mal drei Domains mal zwei Versionen macht 36 Wege, über den ein einziger Eintrag auf dem Server aufgerufen werden kann.
Ein paar Tage später fällt mir auf: Unser Server ist sogar mit seiner IP-Adresse bei Google zu finden. Stimmt: Da war mal ein Server-Umzug während dem wir vorsichtshalber auf die IP umgeleitet haben. Prima. Macht 36, und noch einmal 6 dazu – 42. Komisch, irgendwie läuft es immer auf diese Zahl hinaus.
Also aus dem Duplicate-Content ist ein 42facher Content geworden. Das könnte ein Problem sein.
An die Arbeit
Also ran an die Arbeit. Dieser Wust an Adressen muss bereinigt werden. Am besten geht das zunächst einmal mit konsequenten Redirects. Sprich: Wann immer eine URL aufgerufen wird, die nicht in die neue Namens-Konvention passt, muss sie auf die richtige Bezeichnung umgeleitet werden. Ziel der Aktion: Bei Google soll nur eine Version jedes Textes auf der Seite erfasst sein. Alles andere soll aus dem Index verschwinden.
Die Redirects sind schnell gesetzt. Die folgenden Zeilen trage ich in die Datei .htaccess eingetragen. Die liegt im Root-Verzeichnis des Webservers und wird bei jedem Aufruf einer Seite aus diesem Verzeichnis abgearbeitet:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^123.123.123.123$ [OR]
RewriteCond %{HTTP_HOST} ^meinesite.foo$
RewriteRule ^(.*)$ http://www.meinesite.foo/$1 [R=permanent,L]
Hier klären zunächst zwei Abfragen, wie denn die aufgerufene URL aussieht. Handelt es sich um die IP-Adresse der Seite, im Beispiel 123.123.123.123 oder um die Adresse ohne vorangestelltes www, so wird in der letzten Zeile umgeleitet auf die komplette URL, inklusive vorangestelltem www. Die Umleitung ist zudem mit [R=permanent] als ständige Umleitung deklariert. Die Suchmaschine merkt anhand des zurück gegebenen Codes 301, dass die betreffende Seite umgezogen ist und wird dies im Suchindex ändern. Mehr zum Aufbau der Datei .htaccess lesen Sie auf Seite XX.
Die Startseite ändern
Noch ein Problem zeigt sich während der Aufräumarbeiten: Die Startseite ist sowohl mit www.site.foo/welcome.php also auch nur mit www.site.foo/ zu erreichen. Duplicate Content?Ich gehe kein Risiko ein. Also durchforste ich den kompletten Quelltext des Webauftritts nach Links, die auf welcome.php zeigen und ändere sie alle so, dass sie immer nur www.site.foo/ aufrufen.
Dann setze ich noch eine Umleitung: Alles, was an welcome.php ankommt, soll nach / gehen. Die Syntax dazu sieht so aus:
RewriteRule ^welcome.php$ / [R=permanent]
Doch das reicht noch nicht ganz. Denn die ebenfalls in der .htaccess eingetragene Zeile
DirectoryIndex welcome.php
sorgt dafür, dass jede Umleitung auf / automatisch zum Aufruf von welcome.php führt. Und das verursacht wieder eine Umleitung auf /. Das Resultat ist eine Endlosschleife, die der Server zum Glück abbricht.
Also benenne ich die welcome.php um in index.php. Das ist ohnehin der näher liegende Dateiname. Und dann ändere ich auch noch den DirectoryIndex:
DirectoryIndex index.php
Fertig. Die Startseite ist sauber. Damit gar nix schief geht, packe ich noch ein
Disallow: /welcome.php
in die Datei robots.txt. Damit verbiete ich Suchmaschinen, die Seite welcome.php abzurufen – die es ja eh nicht mehr gibt. Das ist also eher als zusätzlicher Hinweis zu verstehen, diese Seite auch aus dem Index zu werfen.
Und wenn ich schon gerade bei unangenehmen Arbeiten bin, durchsuche ich den Code noch einmal nach Links. Im Visier stehen Querverweise, die Verzeichnisse oder die oberste Ebene aufrufen und nicht auf / enden, zum Beispiel www.meineseite.foo/verzeichnis. An solche Links hänge ich ein /, damit das Ergebnis so aussieht: www.meineseite.foo/verzeichnis/. In einer so korrigierten Link-Struktur findet sich Google besser zurecht.
URLs entfernen
Nach ein paar Tagen hat sich noch nichts getan. Die Seite ist immer noch tief versunken im Google-Sumpf. Also müssen weitere Maßnahmen her. Ich beschließe, doppelt vorhandene Seiten von Hand zu löschen. Auch hier hilft Google mit der URL-Konsole. Die erlaubt, einzelne Seiten von Hand aus dem Google-Index zu werfen. Das klappt im Normalfall innerhalb weniger Tage.
Bevor es los geht, bedarf es einiger Vorbereitung. Denn die Konsole arbeitet nur, wenn auf der Homepage eine robots.txt vorhanden ist oder wenn die zu löschenden Seiten ein spezielles Meta-Tag in sich tragen. Das Meta-Tag sieht so aus:
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
Dieses Meta-Tag teilt allen Suchmaschinen („robots“) mit, dass die Seite nicht indexiert werden soll. Ebensowenig sollen die Suchmaschinen den Links in der Seite folgen. Soll diese Regel ausschließlich für Google gelten, muss sie so aussehen:
<META NAME="GOOGLEBOT" CONTENT="NOINDEX, NOFOLLOW">
Ich verlasse mich aber lieber auf die Variante mit robots.txt. In diese Datei trage ich alle Seiten ein, die gelöscht werden sollen. Zunächst sind alle Seiten dran, die dynamischen Inhalt und damit auch Dubletten erzeugen. Im Beispiel sieht das so aus:
User-agent: *
Disallow: /show.php
Disallow: /search.php
Disallow: /list.php
Damit verbietet die robots.txt allen Suchmaschinen noch Dateien einzulesen, die dynamische Inhalte liefern. Denn das ist auch nicht mehr nötig, nachdem meine Site ja fast echte HTML-Links erzeugt, die dann auf die entsprechenden dynamischen Einträge umleiten. Von dieser Umleitung bekommen die Suchmaschinen nichts mit. Deswegen kann ich auch die PHP-Seiten bequem löschen.
Den Gedanken, generell alle php-Seiten zu entfernen lasse ich zunächst einmal fallen. Denn mit der von Google vorgeschlagenen Syntax
User-agent: Googlebot
Disallow: /*.php$
wäre ich die schnell los. Allerdings halte ich das für den verkehrten Weg. Besser ist: Immer explizit angeben, was gelöscht werden soll und keine Wildcards. Nur dann ist sicher, dass nicht zu viele Inhalte der Website aus dem Google-Index verschwinden. Übrigens: Die Syntax Disallow: /*.php$ entspricht nicht dem Standard für robots.txt, sondern ist eine eigene Erweiterung von Google.
Davor,
User-agent: Googlebot
Disallow: /
zu setzen, um alle Inhalte der Dubletten-Site meineseite.foo zu löschen, haben mich einige warnende Forumsbeiträge bei Webmasterworld abgehalten. Denn mit diesem Verfahren verloren andere Webmaster nicht nur alle Einträge für ihreseite.foo, sondern auch für www.ihreseite.foo. Sie waren ganz aus dem Index gelöscht. Kleiner Trost für die Betroffenen: Nach einem halben Jahr nimmt Google die gelöschten Seiten wieder in den Index auf.
Also bleibt es bei der Aufzählung der PHP-Dateien. Ich speichere die robots.txt auf dem Server. Danach rufe ich die Konsole unter http://services.google.com:8882/urlconsole/controller auf und registriere mich mit meiner E-Mail-Adresse und einem Kennwort.
Danach gebe ich unter Löschen Sie Seiten, Unterverzeichnisse oder Bilder mithilfe einer robots.txt-Datei die exakte Adresse der robots.txt-Datei ein. Google wird die sofort einlesen und sich an die Arbeit machen. In einer Liste zeigt das Tool, wie weit es mit dem Entfernen der Daten ist. Zwei Tage später sind die Files wirklich weg – und damit schon einmal eine Menge doppelter Content.
Das hat geholfen
Nach gut anderthalb Monaten – es ist schon Ende März zeigt sich der erste Hoffnungsschimmer. Offenbar hat das Umbenennen und Umleiten der Startseite geholfen. Der Pagerank bei Google steigt von 5 auf 6. Pagerank ist ein Gradmesser für die Beliebtheit der Site im Netz. In erster Linie speist sich dieser Gradmesser aus der Anzahl und der Qualität der Links, die auf eine Seite zeigen.
Alle anderen Seiten, die zuvor ihren Pagerank verloren hatten, bekommen ihn wieder zurück. Aufatmen. Nun mag man über den Pagerank geteilter Meinung sein: Die einen halten ihn für komplett unnütz und wirkungslos, die anderen bauen ganze Marketing-Strategien darauf auf. Die Wahrheit mag mittendrin liegen. Das Pagerank-Update zeigt zumindest, dass sich Google noch mit der Site beschäftigt. Außerdem lässt es auf ein umfangreicheres Update hoffen.
Dennoch: Die Abrufe bleiben schlecht, sind sogar noch schlechter als unmittelbar nach dem Allegra-Update. Die Maßnahmen bislang haben also noch nichts gebracht.
In den Foren schreiben alle: Geduld haben, weiter an der Site arbeiten. Aber wenn die Seite nun schon seit über einem Monat aus dem Index verschwunden ist, verliert man die Geduld.
Also gucke ich weiter und sehe zu, wo ich noch etwas an der Seite drehen kann. Mir fallen noch ein paar andere Ungereimtheiten auf: Sobald ich die Überschrift ändere, ändert sich auch die URI eines Beitrages. Sprich: Einige Einträge sind nach Änderungen in der Headline unter zwei oder mehreren URIs zu erreichen – nochmal Gefahr von Duplicate Content.
Dem ist mit .htaccess nicht beizukommen. Denn von dort komme ich nicht an die Daten aus der Datenbank, um die Überschrift zu vergleichen. Das geht nur in PHP: Überprüfen, mit welcher URL ein Beitrag aufgerufen wurde, aus der Überschrift in der Datenbank die tatsächliche URI bilden und beide vergleichen. Sind sie identisch, ist alles in Ordnung. Sind sie nicht gleich, setze ich von PHP aus eine permanente Umleitung.
Als PHP-Code sieht das etwa so aus:
if ((urldecode($_SERVER['REQUEST_URI']) <> urldecode('/'.makeUri($id)))
OR
(preg_match("/show.php?id=[0-9]+$/",$_SERVER['REQUEST_URI'])))
{
Header("HTTP/1.1 301 Moved Permanently");
Header("Location: ".$makeUri($id) );
exit();
}
Zunächst vergleicht die Abfrage den Inhalt der Umgebungsvarialben
REQUEST_URI
mit dem Ergebnis der Funktion makeUri. Diese Funktion erzeugt beispielsweise aus einer ID-Nummer die URI, unter der ein Eintrag normalerweise zu erreichen ist. Um das Ergebnis vergleichen zu können, muss dieses ebenfalls mit
urldecode()
behandelt sein.
Alternativ prüft der Test, ob die Datei mit ihrem PHP-Dateinamen aufgerufen wird. Diese Prüfung findet über einen regulären Ausdruck statt, der lässt nur Aufrufe nach dem Schema
show.php?id=xx
durch, wobei xx eine Zahl ist. Diese Links werden dann auch an die richtige URI weitergeleitet. Das geschieht über den Header-Befehl in PHP. Achtung: Der muss abgesetzt werden, bevor irgendwelche anderen Daten an den Browser gehen. Nur dann funktioniert die Umleitung.
Noch mehr löschen
Ende März gibt es noch ein kleineres Google-Update. Im Zuge dessen verschwinden weitere Seiten, die ebenfalls a) alt eingesessen und b) reich an Inhalten sind. Ich beginne, mir Sorgen zu machen, ob Google mich überhaupt jemals wieder haben will.
Mit den Sorgen kommen neue Gedanken: Vielleicht sind doch die „Zusätzlichen Ergebnisse“ Schuld, dass keine Abrufe von Google kommen. Ich beschließe, auch die alten Links in gemischter Groß- und Kleinschreibung zu entfernen, also alle die, nach diesem Schema aufgebaut sind: „www.meineseite.foo/Ein-toller-Text_id100.html“. Das ist allerdings etwas aufwändig. Denn es geht um mehrere Tausend Einträge. Die wollen alle in die robots.txt geschrieben werden.
Da es sich um dynamisch erzeugte Überschriften handelt, erzeuge ich diese Überschriften noch einmal mit einem PHP-Skript und schreibe sie als Liste in eine Datei. Vor jedem Eintrag steht ein Disallow.
Allerdings hat Google noch eine kleine Hürde gesetzt: Nach 100 Einträgen in der robots.txt ist Schluss. Also teile ich die Arbeit in 100er-Schritte auf. Das ist zwar ein wenig aufwändig, aber nach einer kleinen Modifikation im Skript schnell erledigt.
Von der ursprünglichen robots.txt lege ich eine Sicherungskopie an, danach packe ich die neu erzeugte Version auf den Server, werfe die URL-Konsole an und entferne gleich danach wieder die robots.txt. Danach erzeuge ich die nächste robots.txt, packe sie auf den Server und starte erneut die URL-Konsole. So geht es weiter, bis ich gut die Hälfte aller alten Einträge entfernt habe. Bevor ich weiter mache, will ich erst einmal sehen, ob das was bringt.
Die Hoffnung, schon nach wenigen Tagen Besserung zu sehen, wird enttäuscht. Es passiert wieder nichts – lediglich die Anzahl der „Zusätzlichen Ergebnisse“ ist zurückgegangen.
Ich gebe auf und erlebe eine Überraschung
Anscheinend hilft alles nichts. Auch das Entfernen der Dubletten bringt die Besucher nicht zurück. Statt weiter an der Seite herumzubasteln, kümmere ich mich um andere Aufgaben und warte ab. Irgendwann muss ja das nächste große Update kommen. Erst dann wird sich zeigen, was die Änderungen gebracht haben.
So vergehen die Wochen, der April ist vorbei, der Mai hat sich auch schon fast erledigt.
Und dann kommt „Bourbon“.
Der 21. Mai steht rot markiert in meinem Kalender. Seit diesem Samstag ist die Site wieder da. Google bringt zwar nicht so viele Besucher wie vor dem bösen Update Allegra. Aber immerhin um die 70%.
Offenbar hat das Aufräumen genutzt. Welche Maßnahme nun genau die Erlösung gebracht hat, vermag ich nicht zu sagen. In jedem Fall aber haben die drei Monate der Site eine Menge gebracht: Die Struktur ist aufgeräumt, Suchmaschinen finden sich besser zurecht, ich habe eine Menge gelernt und die Seite ist wieder da. Bis zum nächsten „oops“.
Das kam am 22. September.
Ursachen für Duplicate Content
(1) Die Site ist unter mehreren Domains zu erreichen und indexiert, zum Beispiel unter www.domain.foo und domain.foo. Dazu muss man nicht einmal die Domain explizit unter beiden Namen bei Google gemeldet haben. Es genügt, dass ein anderer freundlicher Webmaster im Netz einen Link auf Ihre Site unter dem zweiten Namen gesetzt hat.
(2) Die Site ist unter dem Domain-Namen und zusätzlich unter der IP-Adresse erreichbar. Das kommt vor, wenn während eines Domain-Umzugs von der ursprünglichen Adresse schon auf den neuen Server verlinkt wird – eben unter Angabe der IP-Adresse. Kommt Google während dieser Umzugszeit vorbei wird die Site auch unter der IP-Adresse erfasst.
(3) Auf der Site sind die Inhalte unter verschiedenen URLs lesbar. Das kommt vor allem auf Sites mit dynamischen Inhalten vor. Die hatten früher ihre Texte unter URIs wie /inhalt.php?id=10 auf dem Server und haben dann umgestellt auf scheinbar statische URLs /das_ist_mein_text_id_10.html. Noch besser: Erst auf statische URLs umstellen und dann noch die Schreibweise ändern, also von /das_ist_mein_text_id_10.html auf /das-ist-mein-text-id_10.html.
Das hilft gegen Duplicate Content
Maßnahme Nummer 1 gegen Duplicate Content: Versuchen Sie die Dubletten so schnell wie möglich los zu werden. Das Problem mit der Erreichbarkeit unter mehreren Domains bekommen Sie mit einem Rewrite in den Griff. Diese Rewrite-Rules landen auf Apache-Servern in der Datei .htaccess im Root-Verzeichnis der Website, zum Beispiel:
RewriteEngine onRewriteCond %{HTTP_HOST} ^xyz.foo$RewriteRule ^(.*)$ http://www.xyz.foo/$1 [R=permanent]
Besonders wichtig ist dabei das [R=permanent]. Das sorgt dafür, dass ein Client – auch der Googlebot – das richtige Signal mit dem Code 301 erhält: Diese Adresse ist dauerhaft umgezogen. Mit der Zeit wird Google diese Neuerungen aufnehmen und umsetzen. Aber haben Sie Geduld, das kann Monate dauern.
Mehr zu Rewrite-Regeln unter Apache lesen Sie auf:
http://httpd.apache.org/docs/mod/mod_rewrite.html
Um zu prüfen, ob so eine Umleitung funktioniert, verwenden Sie zum Beispiel curl:
curl -I http://domain.com/adresse.html
Schneller geht’s mit den Dubletten innerhalb der Site. Falls Sie schon auf die neue, statische Schreibweise umgestellt haben, müssen Sie dem Googlebot nur noch verbieten, die alten Dateien zu lesen. In obigem Beispiel müssten Sie also die inhalt.php ausschließen. Das geht am besten in der Datei robots.txt. Die sitzt im Root-Verzeichnis der Website:
User-agent: *Disallow: /inhalt.php
Mit dieser Anweisung verbieten Sie allen Bots, die Seite index.php zu lesen. Nach kurzer Zeit schon werden die entsprechenden Seiten aus dem Index verschwinden.
Mehr zu robots.txt erfahren Sie unter http://www.robotstxt.org/wc/exclusion.html.
Der Google GAU von 2002
Vor einem Monat kam es zum Super-Such-GAU: Meine Website ist bei Google rausgeflogen. Die Folge: Zwei Drittel weniger Besucher und Pageviews. Und das, obwohl ich mich den ganzen Sommer auf Abrufzahlen bis zu 10.000 Pageviews am Tag hochgearbeitet hatte.
Ob mir Google etwas übel genommen hat? Nein, das kann eigentlich nicht sein. Ich bin mit jedenfalls keiner Schuld bewusst. Weder Meta-Tag-Spamming noch unsichtbare Texte oder ähnliches unsauberes Werkzeug habe ich verwendet. Auch auf das in letzter Zeit populäre Spamming mit rekursiven Querverweisen auf meine Seite habe ich verzichtet.
Suchmaschinen-Spamming bringt meiner Ansicht eh nicht viel. Meine These: Google richtet sich in erster Linie nach Titelzeile und dem Textinhalt der Seite.
Dennoch hat mein Problem wohl bei der Suche nach dem besseren Google-Ranking begonnen: Irgendwo habe ich gelesen, dass im Google-Ranking steigt, wer einen Suchbegriff auch in der URL unterbringt. Bislang hat ein Skript aus den dynamischen Daten, statische, durchnummerierte Dokumente erzeugt und den Suchmaschinen vorgeworfen, die nicht gerne in Datenbanken buddeln. Übrigens scheint auch Google diese statischen Seiten allem dynamischen vorzuziehen. Meine Idee: an Stelle der Nummern in den Dateinamen könnte doch gleich die Titelzeile des entsprechenden Textes aus der Datenbank stehen. Gedacht, programmiert. Das PHP-Skript holt sich den Titel eines Beitrags aus der Datenbank, ersetzt alle Leerzeichen mit einem Unterstrich:
$FilePrefix=ereg_replace("[[:space:]]","_", $row["thead"]);
wirft alle Tags heraus,
$FilePrefix=ereg_replace("<[^>]*>","",$FilePrefix);
entfernt Entities,
$FilePrefix=ereg_replace("&[^;]*;","",$FilePrefix);
ersetzt Umlaute,
$FilePrefix=str_replace("ä", "ae", $FilePrefix);
[..]
und wirft alles heraus, was nicht Buchstabe oder Zahl ist:
$FilePrefix=eregi_replace("[^a-zA-Z0-9_]","",$FilePrefix);
Das Problem war nur: als ich dachte, das Programm wäre ok, habe ich alle bislang verwendeten statischen Dateien gelöscht. Das war ein Fehler. Und aus dem folgt Merksatz Nummer 1: Löschen Sie niemals alte Daten auf Webseiten, bevor nicht die neuen Dateien fertig, verlinkt und auffindbar sind.
Danach habe ich eine Weile herumgewurstelt und das Umwandlungsprogramm von seinen bösen Fehlern gereinigt. Schließlich war es spät am Abend und ich habe die Arbeit eine Nacht ruhen lassen. Das waren Fehler und Merksatz Nummer 2: Wenn Sie an einem lebenden Web-Server operieren, hinterlassen Sie nie halbfertige Arbeit.
Vermutlich hat Google genau in dieser Nacht vorbei geschaut. Die ursprünglich gut bei Google vertretenen statischen Dateien mit den Zahlen als Dateinamen waren nicht mehr da. Die anderen statischen Seiten mit den langen Dateinamen waren noch nicht da. Google – dumm wie ein Computer nur sein kann – zieht sich daraufhin zurück.
Jetzt sitze ich hier und rufe stündlich das Weblog meines Servers auf. Immer in der Hoffnung, Google erbarmt sich meiner Seiten und schaut wieder rein.
Die Moral von der Geschicht‘ ist nicht nur eine technische sondern auch eine netz-politische. Falls es noch niemand gemerkt hat: Google ist auf dem Weg zum Suchmonopol.
Denn Google ist die beste Suchmaschine. Und Google hat so gute Technik, dass sie alle anderen Suchmaschinen aussticht. Außerdem breitet sich Google immer mehr aus. AOL sucht mit Google, Yahoo sucht mit Google und Web.de auch. Sprich: Fällt man ein Mal aus Google heraus, existiert man auch in diesen Partner-Suchmaschinen nicht mehr.
Gut, man kann Google kein aggressives Marketing vorwerfen. Die Marktmacht resultiert aus überlegener Technik. Dennoch sollten sich im Interesse des Internet und der User alle anderen Suchmaschinen anstrengen und an Google abgegebene Marktanteile zurück gewinnen. Dann schmerzt der nächste Google-Rauswurf auch nicht mehr so sehr.
Aus Google verschwunden wegen Session ID
Endlich: Die Google-lose Zeit ist vorbei. Die Suchmaschine hat mich wieder. Sie kommt jeden Tag vorbei und crawlt und crawlt. Wie es zur Rückkehr kam, erzählt der dritte Teil der Google-Trilogie.
Wohin wendet sich ein Webmaster in aller Verzweiflung? An eine Newsgroup. Doch das fällt nicht leicht. Denn man weiß nie, was einen dort erwartet. Sind es freundliche Gesellen, die geduldig auch die dümmste Frage beantworten? Oder sind es die, die sich sofort auf den Newsgroup-Beitrag stürzen, jeden Kommafehler ankreiden und darauf hinweisen, dass die Frage schon zehn mal gestellt wurde und man sich doch gefälligst in die nächste FAQ verziehen möge?
Zum Glück ist die Google-Support-Newsgroup google.public.support.general gefüllt mit freundlichen Vertretern der ersten Gattung. Zwei Tage nach meiner Frage, warum Google nur die Eingangsseite erkennt und den Rest liegen lässt, hatte ich die Antwort. Der freundliche Zeitgenosse hatte sich meine Site angesehen und folgendes festgestellt: Da werden Session-IDs vergeben. Diese von PHP erzeugten Zeichenungetüme gibt es auf meiner Seite dann, wenn der Client keine Cookies annimmt. Nun sei es unwahrscheinlich, klärte mich der freundliche Helfer auf, dass der Googlebot sich mit Cookies abgeben würde. Also findet der Bot die Session IDs – und die wechseln mit jedem Besuch. Offenbar ist dieser Wechsel ein Knock-out-Kriterium für Google.
Also habe ich meine Header-Datei so umgebaut, dass sie den Googlebot erkennt und in diesem Fall die Session-Behandlung und damit Cookies wie IDs abschaltet. Nach ein paar Tagen war es endlich so weit: Google hatte uns wieder. Die Abrufzahlen verdoppelten sich innerhalb von zwei Wochen. Und nun hoffe ich, dass bald wieder das alte Niveau erreicht ist.
Das komische: An allem ist reine Angeberei schuld. Ich wollte wie viele andere Seiten im Web auch so einen tollen Besucherzähler. Und der geht nicht ohne Session-Handling. Denn schließlich muss jeder User eindeutig identifiziert werden. Mit der Einführung dieses an sich nutzlosen Features kamen auch die Session-IDs. Das allein hat aber für die Katastrophe nicht gereicht. Auch die zeitweise Abwesenheit wichtiger Seiten des Servers haben ihren Teil beigetragen: Google hat die alten Seiten aus dem Index geschmissen und konnte die neuen Versionen wegen der Session-IDs nicht aufnehmen. Das war die berühmte Verkettung unglücklicher Umstände.
In jedem Fall ist es ärgerlich, dass das Wohlergehen einer Site so sehr von einer Suchmaschine abhängt. Denn auch wenn sich in der Google-losen Zeit ordentlich Besucher von MSN-Search oder der T-Online-Suchseite kamen: Diese Suchdienste konnten kaum liefern, was Google gebracht hat. Da fürchtet man ein Suchmonopol und schon malen einige Google-Gespenster von Zensur und Medien-Macht an die Wand. Doch ganz so schlimm wird es nicht werden, wenn sich andere Suchmaschinen am Riemen reißen und endlich nachholen, was Google ihnen vorgemacht hat. Doch dafür ist es höchste Zeit.
Ein Gutes hatte der Google-Crash immerhin. Ich habe seitdem so gut wie alle Tipps umgesetzt, die das Googlebot-Wohlwollen wecken könnten: Javascripts sind in Extra-Dateien ausgelagert, ebenso CSS-Vorlagen. Ich habe alle Dateien nach Fehlern in der HTML-Syntax durchforstet und bin zu meinem Entsetzen mehr als einmal fündig geworden. Der Text auf meinen Seiten ist im HTML-Dokument weiter nach vorne gerückt. Und die robots.txt sowie die robot-Meta-Tags sind auf Hochglanz poliert. Doch ob das die drei Monate mit einem Drittel der Abrufzahlen wert war? Ich glaube nicht.
Rote Karte von Google
Ich wollte nicht schon wieder über Google schreiben. Aber es bleibt mir nichts anderes übrig. Denn am 22. September 2005 gab es mal wieder die rote Karte von der Suchmaschine. Meine Homepage ist aus dem Index praktisch verschwunden. Nach zwei Tagen Frustration folgt die Analyse: Im Google-Index sind rund dreimal so viele Seiten von meiner Homepage zu finden wie üblich. Das ist ein klarer Hinweis auf Duplicate Content. Hier ist Google seit diesem Jahr besonders empfindlich.
(erschienen 2005 in Internet Professionell)
Im Februar gab es schon ein ähnliches Problem. Damals lag die Ursache in mehreren Domain-Namen, unter denen die Seite zu finden war und in unterschiedlichen URLs, unter denen ein und der selbe Eintrag erreichbar war. Nach fleißigem Aufräumen war die Ursache beseitigt und die Homepage kehrte nach drei Monaten in den Index zurück. Beim Aufräumen habe ich mit Hilfe der URL-Removal-Console von Google die doppelten Versionen rausgeschmissen. Mit Einträgen in der robots.txt blieben diese Dubletten auch weiter vom crawlen ausgeschlossen.
Dann aber habe ich einen Fehler gemacht. Bislang galten die Regeln meiner robots.txt für alle Suchmaschinen. Es gab nur Einträge unter „User-agent: *“. Dann aber habe ich einen Eintrag hinzugefügt, der speziell nur für Google vorgesehen war. Meine Annahme erwies sich bald als falsch, Google würde zunächst die für alle User Agents gültigen Regeln lesen und dann zusätzlich die für „User-agent: Googlebot“. Im Gegenteil Google hat nur die Regeln im „Googlebot“-Eintrag gelesen und alles andere ignoriert. Google fing also an, fleißig die doppelten Versionen zu crawlen. Mit einem Schlag war das Problem wieder da und meine Seite weg. Und alles nur, weil es zu jedem Artikel auf der Seite eine Druckversion gibt.
Seit dieser Erfahrung habe ich die robots.txt überarbeitet, nochmal alle doppelten Seiten mit der URL-Removal-Console rausgeworfen und zusätzlich die Dubletten-Seiten in der .htaccess gegenüber dem Googlebot gesperrt.
Wenn Sie also mit der robots.txt arbeiten und Probleme mit doppeltem Content drohen, denken Sie daran, für jede Suchmaschine komplett alle Einträge zu wiederholen. Halten Sie die Augen offen und sehen Sie sich genau Ihre Logs an. Sobald Google anfängt Dubletten zu crawlen, läuft etwas schief. Ich passe ab jetzt auch besser auf.
Lesen Sie hier weiter: Inhalt zuerst