Von Google gebannt wegen Duplicate Content

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.