Trotzdem können wir daraus viel lernen: Wenn DAUs schreien, das Internet sei kaputt, dann ist ausnahmsweise Google nicht erreichbar. Und wenn wir SEOs schreien, Google macht schon wieder Update, dann hat ausnahmsweise Sistrix falsche Daten …

Anfang Mai gab’s das Mayday-Update, das zu etlichen Verlusten etablierter Websites im Longtail-Bereich führte. Davon waren auch Websites von Kunden betroffen, so dass ich seither neben diesen Kundensites eine Menge an Websites regelmäßig begutachte, die eine ähnliche Charakteristik aufweisen. Wie ich heute beim Check dieser Websites feststelle, haben sich die Sichtbarkeitsindizes gerade der Sites deutlich verschlechtert, die beim Mayday-Update vor drei Monaten relativ ungeschoren davon kamen.

Hier eine Auflistung von Websites und deren aktuelle Verluste des Sichtbarkeitsindex gegenüber der Vorwoche. In der dritten Spalte zum Vergleich die Änderungen während des Mayday-Updates vom 26. April bis zum 17. Mai.

Diese Websites stammen aus drei verschiedenen Branchen. Der Sichtbarkeitsindex reicht von 7 bis etwa 80. Auch bei den aktuellen Änderungen scheinen vor allem wieder die Longtail-Rankings eine Rolle zu spielen. Allen ist gemeinsam, dass die Anzahl der Keywords, unter denen sie in den Top100 zu finden waren, deutlich weniger wurden. Und alle Websites haben eine nicht unerhebliche Menge an Seiten mit sehr wenig Content im Index – es passen also wieder genau jene Beschreibungen wie bereits zum Mayday-Update. Habt Ihr ähnliche Erfahrungen? Beobachtungen? Erklärungen?

<link rel=”canonical” href=”http://www.example.com/original/” />

Soweit die langweilige Einführung zur Syntax des Canonical Tags. Spannend wird es, wenn der von URL-Umbauten genervte SEO hofft, sich – oder seinen noch mehr genervten Kunden – damit eine Konsolidierung der URLs ersparen zu können. Es soll Beratungsprojekte geben, in denen dem SEO bereits das Wort “Duplicate Content” verboten wurde …

Zwar schreibt Google in seinem Webmaster Blog über den Canonical Meta-Tag:

It also helps to make sure that properties such as link popularity are consolidated to your preferred version.
(Er hilft auch zu gewährleisten, dass solche Größen wie etwa Link Popularity auf die bevorzugte Version übertragen werden.)

Allerdings glaube ich den Mitteilungen aus dem Hause Google erst dann, wenn ich die aufgestellten Behauptungen selbst experimentell überprüfen konnte. Also habe ich vor etlichen Wochen einen kleinen Versuch aufgebaut, um die genaue Wirkungsweise des Canonical Tag zu überprüfen. Dazu erstellte ich eine Kopie namens copy.html einer bereits existierenden Seite (original.html). Diese copy.html habe ich leicht verändert: Ich habe den Titel etwas modifiziert und einen kurzen Satz mit einem recht außergewöhnlichen Wort (“WORT_A”) eingefügt; ebenso den entsprechenden Canonical Meta-Tag: <link rel=”canonical” href=”original.html”>. Das Original wie die Kopie liegen auf der selben Domain. Um Googles Behauptung, der Canonical Tag würde “Link Juice” weiterreichen, zu überprüfen, habe ich von einer fremden Domain einen Link auf die copy.html gesetzt. Der Linktext besteht dabei aus einem weiteren recht seltenen Wort: “WORT_B”. Das Szenario ist in dieser Grafik zusammengefasst:

Nachdem ich Google nun einige Wochen Zeit gelassen habe, meine Konstruktion entsprechend zu würdigen, bestätigt sich im Wesentlich das, was Google behauptet:

• Die Seite copy.html wird von Google nicht aufgenommen.
• WORT_A wird auf der Domain, auf der das Experiment durchgeführt wurde, nicht gefunden.
• WORT_B hingegen wird gefunden – und zwar auf der Seite original.html.

Ganz offensichtlich “biegt” der Canonical Meta-Tag den Link, der auf copy.html zeigt, auf die Originalseite um und weist den Linktext der original.html zu. Interessant ist auch noch ein kleiner Nebeneffekt: Die Website, auf der die Tests durchgeführt wurden, ist noch unter einer anderen Domain zu erreichen. Von dieser Spiegeldomain war bislang in Google nichts zu finden. Seit dem Experiment ist die copy.html unter der Spiegeldomain zu finden – auch bei einer Suche nach dem nur auf copy.html enthaltenen WORT_A. Anscheinend schließt Google die copy.html nur auf der Domain von einer Indexierung aus, auf der auch das Original liegt.

Was machen denn eigentlich die anderen Suchmaschinen? Yahoo nimmt “brav” die copy.html auf und findet diese Seite sowohl unter WORT_A als auch unter WORT_B. Microsofts Live Search hingegen macht’s genau anders herum: Hier ist die copy.html überhaupt nicht zu finden, und die Versuchswebsite taucht weder für WORT_A noch für WORT_B auf. Es scheint so, als würde Yahoo den Canonical Metatag gar nicht beachten, während Microsoft das “canonical” als “noindex” interpretiert.

Natürlich ist mit dem Experiment noch nicht geklärt, ob durch das Umbiegen womöglich etwas Linkpower verloren geht. Ich würde das eigentlich erwarten. Trotzdem stimmt mich das Ergebnis bei Google zuversichtlich, dass manche Optimierungen großer Redaktionssysteme, die häufig extreme Duplicate-Content-Generatoren sind, mithilfe des Canonical Meta-Tag einfacher durchgeführt werden können.

Sei auf alles gefasst – und bereite dich darauf vor, trotzdem überrascht zu werden.

Als Anregung für alle Techies, deren SEO-Kenntnisse noch in den Kinderschuhen stecken, stelle ich hier ein paar der herausragendsten Fehler zusammen, die mir zuletzt in Beratungsprojekten untergekommen sind. Dabei geht es nicht darum, irgendwen bloß zu stellen. Die aufgeführten Lösungen funktionieren alle und sind aus rein technischer Sicht absolut in Ordnung. Suchmaschinen-Robots stellen allerdings hie und da andere Anforderungen.

1. “Seite nicht gefunden”-Seiten zeigen Statuscode 200
   Auf klassischen HTML-Websites ohne Datenbank-Unterstützung war die Sache einfach. Konnte der Webserver eine Seite nicht finden, schickte er eine (eventuell zuvor passende gestaltete) Fehlerseite als Antwort und dazu den Statuscode 404. Dieser Code sagt dem Client, also dem Webbrowser oder dem Robot der Suchmaschine, dass die gewünschte Seite nicht auffindbar ist. Für die Suchmaschine heißt das also: Ich nehme diese Seite nicht auf bzw. lösche sie, falls vorhanden, aus meinem Index.
   Die heutigen Redaktionssysteme fangen solche Situationen meist ab; ein Request auf eine unbekannte URL dringt erst gar nicht bis zum Webserver durch. Denn ein CMS ist ja häufig so konzipiert, dass sich die URLs erst gar nicht als Datei auf dem Server befinden, sondern erst bei einer Anfrage aus der Datenbank generiert werden. Also ist das CMS für die Erstellung der Fehlerseiten zuständig – etwa dann, wenn ein Artikel aus der Datenbank gelöscht wurde.
   Kommt nun aber eine Anfrage nach einem solch gelöschten Artikel, sollte das CMS einen Statuscode 404 zurückliefern, damit die Suchmaschinenrobots wissen, dass der Artikel nicht mehr existiert. Ich habe aber mehr als nur einmal Kundenprojekte vorgefunden, die in einem solchen Fall einfach den Inhalt der Startseite mit dem Statuscode 200 (heißt so viel wie “alles okay”) zurückgeliefert haben.
   Das Ergebnis dieser Konfiguration: Das System läuft jahrelang wunderbar, auch Google hat nichts auszusetzen, denn 404-Fehler kommen selten vor. Eine Umstellung des URL-Schemas aber führt zu komplett neuen URLs mit der Konsequenz, dass die vielen externen Links auf Unterseiten zu 404-Fehlern führen. Das System sendet aber einen Statuscode 200 und Google nimmt somit unter den URLs des alten Schemas jeweils den Inhalt der Startseite auf. Irgendwann wird es Google zu viel und die Website wird wegen des so erzeugten Duplicate Contents abgestraft.
2. Interne Fehler ergeben Statuscode 404
   Interessanterweise kommt auch der umgekehrte Fall in der Praxis vor. Dort wo ein Statuscode 500, der einen internen Fehler anzeigt, oder vielleicht Statuscode 408, der auf einen Timeout hinweist, angebracht wäre, wird ein Statuscode “404 – Seite nicht gefunden” gesendet. Die Reaktion von Google darauf ist klar: Anstatt die Seite etwas später nochmals zu besuchen, wird die URL aus dem Index gelöscht. Da bei einem neuen Crawl die URL aber wieder über die interne Navigation auftaucht, wird Google die Seite künftig wieder aufnehmen – falls dann technisch alles in Ordnung ist. Deshalb fällt dieser Fehler selten unmittelbar auf. Wenn solche Fehler aber zusammen mit anderen Problemen auftreten, kann dies ein weiteres Mosaiksteinchen für erhebliche Google-Probleme sein.
   Auch dies ist ein Fehler, der gerne zusammen mit “geschickt” programmierten Inhouse-Redaktionssystemen oder besonders innovativen Web-Frameworks auftritt.
3. Wackelige Technik
   Spätestens mit Ruby on Rails wurden die MVC-Frameworks sehr beliebt. Und in der Tat erlauben es diese Frameworks, komplexe Websites in kürzester Zeit aufzusetzen. Doch kommt Bequemlichkeit selten umsonst: Um all die schicken Features zu ermöglichen, sind im Hintergrund viele Datenbankzugriffe nötig und werden allerhand Verrenkungen angestellt. Nicht selten ist das Ergebnis eine Website, die nicht wirklich stabil läuft. Zwar sind Nutzer wie Suchmaschinen-Robots in Web-2.0-Alles-ist-Beta-Zeiten temporären Aussetzern recht tolerant gegenüber; trotzdem ist eine instabile Plattform, nun ja halt eine instabile Plattform. Gelegentliche Nichterreichbarkeit ist für Google nicht sofort ein Killerkriterium, doch in Kombination mit anderen Problemen kann es der Auffindbarkeit der Website sehr wohl schaden. Deshalb gehört zu einer ordentlich Suchmaschinenoptimierung auch, das technische Fundament sauber zu legen.
4. URL-basiertes Load Balancing
   Stellt euch vor, euch gehört eine uralte und höchst etablierte Website mit sehr viel eigenständigem Content. Irgendwann macht ihr sogar etwas SEO dafür und der sowieso schon ordentliche Traffic steigt weiter an. Nun ergibt sich die Notwendigkeit, für die Website ein Load Balancing einzuführen. Welche Art des Load Balancing solltet ihr auf keinen Fall einsetzen? Genau: Ein Load Balancing, das jeden Request auf www.example.com zufällig auf www1.example.com oder www2.example.com weiterleitet!
   Genau das hat ein Kunde (bevor er mein Kunde war *g*) aber gemacht, mit der schönen Konsequenz, dass Google die Website plötzlich ganz schlecht (Duplicate Content!) fand und der Suchmaschinentraffic entsprechend eingebrochen ist. Wieso jemand auf die Idee kommt, eine derartige Pseudo-Lösung einzusetzen? Nun ja, im konkreten Fall war das Load Balancing keine technische Notwendigkeit, sondern eher eine politische Vorgabe, weil zwei der Gesellschafter eigene Rechenzentren hatten und die Website sollte in beiden Rechenzentren gehostet werden.
5. URLs werden ohne Not geändert
   Daraus lernen wir eine weitere Lektion für jeden Webmaster: Ändere nie die URLs, wenn es keine zwingenden Gründe dafür gibt. Und mit URL ist alles gemeint, angefangen vom http bis zum abschließenden .php. Wobei URLs mit der Endung .php sowieso eine ganz schlechte Idee sind. Will man diese Endung auch in fünf Jahren noch nutzen, wenn das System längst unter Ruby on Rails, Python on Paths oder Scheme on Streets läuft?
6. Weiterleitungen zum Cookie-Setzen
   Ein Kunde hatte diese Aufgabenstellung: Kommt ein Nutzer auf die Website, muss sofort ein Cookie gesetzt werden, um eine Session zu starten. Denn schon auf der ersten Seite, egal ob Homepage oder Unterseite, muss eine Session-ID vorliegen, um AJAX-basierte Funktionalitäten nutzen zu können. Gelöst wurde diese Aufgabe zunächst dadurch, dass eine Weiterleitungsantwort (Statuscode 302) mit einem entsprechenden Set-Cookie-Header gesendet wurde. Die Weiterleitung erfolgte auf eine zweite Version der Seite, indem einfach ein Parameter angehängt wurde. Diese zweite Seitenversion konnte dann sofort erkennen, ob der aufrufende Client das gesetzte Cookie angenommen hat und entsprechend die Funktionalität bereitstellen.
   Google fand diese Lösung nicht so schick. Denn der Googlebot sah die verlinkten URLs (erste Version) als auch die Ziel-URLs (zweite Version). Da es sich um eine 302-Weiterleitung handelte, fing er zunächst an, beide URLs aufzunehmen. Dann aber strafte er die Seiten im Ranking ab, denn die massenhaften Weiterleitungen gefielen ihm gar nicht.
   Hierfür eine sinnvolle Lösung zu finden, ist gar nicht so einfach. Mein Vorschlag, das Cookie gleich im <head> der ersten (und damit einzigen) Version per JavaScript zu setzen, fand mein Kunde nicht so schick. Dafür setzten sie eine andere, gefährliche Lösung um: Die 302-Weiterleitung wird nur gesendet, wenn der Zugriff nicht von einem Googlebot stammt. Natürlich ist das Cloaking und natürlich habe ich auf die damit verbundenen Gefahren hingewiesen. Aber letztendlich ist der Kunde Herr der Umsetzung – und muss die eventuell eintretenden Konsequenzen tragen. Bisher klappt aber diese gefährliche Lösung. Noch.
7. JavaScript Browserweiche
   JavaScript ist ein ewiger Quell spannender SEO-Probleme. Mein Lieblings-JavaScript-Fehler liegt nun schon etliche Jahre zurück, aber das soll nicht heißen, dass derartige Methoden heute nicht mehr eingesetzt würden.
   Die Website, auf der diese Lösung im Einsatz war, hatte wunderbaren Inhalt, der in dieser Qualität und Tiefe nirgendwo sonst im Web vorkam. Die Site war zudem bestens verlinkt, denn es handelte sich um einen kleinen, aber feinen Fernsehsender mit durchaus hohem Bekanntheitsgrad. An sich wunderbare Voraussetzungen für beste Platzierungen in Google. Doch das Problem zeigte sich sehr schnell: Von den etwa 4.000 Seiten mit tollem Content hatte Google nur zwei Seiten, darunter die Homepage, aufgenommen.
   Der Grund dafür war eine JavaScript-Browserweiche, die in einem noscript-Tag eine Meta-Refresh-Weiterleitung auf eine Hinweisseite enthielt. Auf dieser Hinweisseite war dann zu lesen, dass zur Nutzung der Website JavaScript benötigt würde und der Nutzer doch einen JavaScript-fähigen Browser installieren solle. Google folgte brav dieser Weiterleitung und nahm außer der Homepage nur diese Hinweisseite auf.
   Kaum war die alberne Browserweiche entfernt, nahm Google die Seiten auf, der Traffic stieg rapide und alle waren glücklich. Denn der eigentliche Clou dieser Geschichte ist, dass die Website auch ohne JavaScript problemlos zu nutzen war.

Lasst uns also eines ein für alle Mal klarstellen: Es gibt keine “Duplicate Content-Penalty”.

Das klingt so überzeugend, dass man fast glauben könnte, Google hätte das Problem nun endgültig gelöst. Doch in der weiteren Folge finden sich eine ganze Reihe von Einschränkungen dieser Kernaussage – alle zusammengenommen ergibt sich ein ganz anderes Bild zum Thema Duplicate Content.

Zunächst stellt Google klar, dass Duplicate Content auf unterschiedlichen Websites, sei es durch Scraping oder Partnerprogramme erzeugt, sehr wohl ein Problem ist und zur Abstrafung führen kann:

Es gibt einige Penalties, die mit dem Konzept zusammenhängen, dass eine Site den gleichen Content hat wie eine andere Site. (..) Wenn ihr beispielsweise Content wiederveröffentlicht ohne Mehrwert hinzuzufügen.

Doch schon Duplicate Content innerhalb einer Website, so wie ihn viele CMS von Haus aus erzeugen, kann zu Schwierigkeiten führen – falls Google glaubt, das geschehe, um zu manipulieren:

Duplizierter Content auf einer Website ist kein Grund für Maßnahmen gegen diese Website, außer es scheint, dass mit diesem duplizierten Content Nutzer getäuscht bzw. Suchmaschinenergebnisse manipuliert werden sollen.

Der ganze Artikel liest sich wie die alten Radio Eriwan-Witze, die leider außer Mode gekommen sind:

• Frage an die Google Webmaster-Zentrale:
  Kann Duplicate Content meiner Website schaden?
• Anwort der Google Webmaster-Zentrale:
  Im Prinzip nein. Außer ihr habt Pech.

Wer sich auf das Glücksspiel also nicht einlassen möchte, sollte sich auch weiterhin um das Thema Duplicate Content ernsthaft kümmern.

In einem heute auf deutsch erschienenen Artikel nimmt Vanessa Fox vom Google Webmaster Central Blog anlässlich einer Diskussion auf einer Suchmaschinenkonferenz nochmals dazu Stellung. Neben einigen interessanten Ansätzen, was Google denn tun könnte, um Duplicate Content-Probleme für legitime Webseiten zu verhindern, veröffentlicht Google hier wieder einige Aussagen, die zumindest missverständlich sein könnten; ich würde sie eher als falsch bezeichnen.

Duplicate Content führt nicht dazu, dass eure Site in die Supplemental Results rutscht. Allerdings kann dies indirekt ausgelöst werden, falls verschiedene Links auf die unterschiedlichen Versionen eurer Seite zeigen und so einen niedrigeren PageRank verursachen.

In dieser Aussage kommt es auf die feine Unterscheidung zwischen Site und Seite an. Sicherlich rutscht eine komplette Website nicht als ganzes in den Zusatzindex ab, nur weil viel Duplicate Content auf dieser Site zu finden ist. Das Problem ist ja vielmehr, dass Google Seiten als Duplikate qualifiziert und in den Zusatzindex schiebt, die keine Duplikate sind oder zumindest keine sein sollten. Gleichzeitig bestätigt diese Aussage, dass ein niedriger PageRank ein wichtiges Kriterium dafür ist, ob eine Seite in den Haupt- oder den Zusatzindex gesteckt wird.

Duplicate Content auf eurer Site führt nicht zu Penalties. Wenn doppelte Seiten erkannt werden, taucht im Interesse der Ergebnisvielfalt nur eine Version in den Suchergebnissen auf.

Klingt gut, allein mir fehlt der Glaube. Denn ich habe Websites gesehen, die in der Tat nicht als ganzes im Zusatzindex landeten, von denen aber zu einzelnen Artikeln keine einzige Version in Googles Index zu finden war. (Eines dieser Beispiele habe ich auf meiner Suchmaschinen-Trainings-DVD vorgestellt.)

Google will einmalige Ergebnisse liefern und wählt deswegen automatisch eine Version aus, falls eure Websites Duplicate Content aufweisen. Falls ihr euch also nicht die Mühe machen wollt, eure Duplikate auszusieben, könnt ihr einfach uns dafür Sorge tragen lassen.

Angesichts der vielen Probleme, die ich auf diversen Seiten dank Duplicate Content sehe, ist dieser Rat mit Sicherheit vollkommen unsinnig, ja schon fast zynisch. Vor allem wenn ich mir anschaue, welch ausgiebige Hilfestellungen Google gibt, um Duplicate Content zu vermeiden.

Duplicate Content ist also nach wie vor ein richtiges Problem für jeden Webmaster, auch wenn Google derzeit versucht, uns das Gegenteil einzureden.

Soweit Matt Cutts. Doch müssen seine Ausführungen ergänzt werden, oder zumindest sollte der geneigte Suchmaschinenoptimierer genau lesen, was da steht. Wenn Cutts schreibt, dass das “Zusätzliche Ergebnis” kein Anzeichen für eine Abstrafung ist, dann heißt das eben auch: Natürlich können Seiten zur “Strafe” für Spam oder Duplicate Content in den Zusatzindex wandern.

Und zum guten alten PageRank. Anders als oftmals zu lesen ist, hat er natürlich noch einen erheblichen Einfluss aufs Google-Ranking. Natürlich nicht im engeren Sinne, dass Seiten mit hohem PageRank besonders weit vorne stehen. (Aber dafür war der PageRank meines Erachtens eh schon immer überbewertet.) Der PageRank ist heute für andere Dinge wichtig, etwa dafür, wie viele Seiten von Google aufgenommen werden und ob diese Seiten im Haupt- oder im Zusatzindex landen.

Doch auch hier ist Matt Cutts etwas halbherzig. Ich habe Seiten gesehen, die intern bestens verlinkt waren, auf einer seit vielen Jahren etablierten deutschen Website mit PageRank 7 lagen und trotzdem im Zusatzindex landeten. Der Grund war wohl eine Mischung aus Duplicate Content und fehlenden externen Deep-Links. Das heißt, dass selbst ein guter PageRank für eine Seite nicht ausreicht, im Hauptindex zu landen, wenn andere Faktoren dagegen sprechen.

Wie fast immer bei der Google-Optimierung in letzter Zeit gibt es ein Wundermittel gegen das “Zusätzliches Ergebnis”-Problem: Eine möglichst natürliche Verlinkung. Doch genau darauf legen im Übrigen regelmäßig Suchmaschinen-Optimierer zu wenig Gewicht. Ich hatte in letzter Zeit mehrmals mit Aufräumarbeiten zu tun, wo Optimierer die Unternehmens-Website klassisch gut optimiert hatten, aber die natürliche Verlinkung sträflich vernachlässigten. Wer Kunden-Websites optimieren möchte, sollte halt zumindest ab und zu dann doch Matt Cutts lesen.

Dass Duplicate Content in der Tat ein erhebliches Problem darstellt, macht allein die Ansetzung eines eigenen Panels im Rahmen der New Yorker Search Engines Strategies Conference (SES) zu diesem Thema deutlich. Zwei Vertreter von großen Suchmaschinen – Rajat Mukherjee von Yahoo und Matt Cutts von Google – gestanden denn auch ein, dass Suchmaschinen hier ein Problem haben. “Wir wollen keine Inhalte abwerten, sondern die richtigen Inhalte nach vorne bringen,” erklärte Mukherjee. Da dies aber schwierig sei, empfehle er Doppelungen “wo immer möglich zu vermeiden”.

Cutts stellte anschließend klar, dass die etwa durch zwei Top-Level-Domains entstandene Spiegelung “keine Abstrafung durch Google” mit sich bringe und auch eine (zusätzliche) Druckversion einer Seite kein Problem darstellt. Meiner Erfahrung nach ist das aber nur die halbe Wahrheit. Denn oft genug sind das nicht die einzigen Vervielfältigungen, denen ein Seiteninhalt unterliegt: Zwei Top-Level-Domains und zu jeder normalen Seite eine (ebenfalls crawlbare) Druckversion ergibt bereits eine Vervierfachung – ein und der selbe Inhalt ist unter vier verschiedenen URLs zu erreichen. Für gewöhnlich ist dann jede Domain auch noch sowohl mit als auch ohne vorangestelltes www erreichbar, und schon sind wir bei acht Kopien angelangt.

Damit sind aber noch längst nicht alle Möglichkeiten moderner Webtechnologien erschöpft. Stellen Sie sich einen Online-Shop vor: Der Kopfbereich, die Navigation, Einkaufshinweise und der ganze Rattenschwanz an Kontakt-, Impressums- und Sonstwasangaben im Fuß der Seite machen oftmals 90 Prozent des Seiteninhalts aus. Ein anderer Fall, aber ähnlich problematisch sind Sites mit einem hohen Anteil an reinen Fotoseiten. Das kann etwa eine Ferienhausvermietung sein; für jedes Objekt eine eigene Seite, auf der nur das Foto und ein Standardtext erscheint – auch hier droht die Abstrafung wegen Duplicate Content.

Allein die Tatsache, dass das Thema Duplicate Content im Rahmen einer SES diskutiert wurde, erweckt die Hoffnung, dass die großen Suchmaschinen hier bessere Algorithmen finden, die oftmals sehr sinnvolle Wiederverwendungen von Inhalten auf einer Website gegenüber missbräuchlichem Duplicate Content abzugrenzen.