Suchmaschinenoptimierung ist ein Allround-Thema. Marketing- und Design-Kenntnisse spielen ebenso eine Rolle wie das Wissen um technische Zusammenhänge. Mein Eindruck aus Beratungsprojekten der letzten Monate ist nun, dass sich die Bedeutung von SEO in Marketing- und sogar in Entscheiderkreisen weitgehend etabliert hat. Unter Technikern hingegen erscheint mir das Wissen um suchmaschinenfreundliche Technik immer noch recht rar zu sein. Daraus leitet sich die erste Regel für SEO-Consultants ab. Sie lautet:
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.
- „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. - 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. - 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. - 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 aufwww.example.comzufällig aufwww1.example.comoderwww2.example.comweiterleitet!
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. - 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 vomhttpbis zum abschließenden.php. Wobei URLs mit der Endung.phpsowieso 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? - 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 entsprechendenSet-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. - 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 einemnoscript-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.