Die schönsten technischen SEO-Fehler

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.

  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.

Newsletter-Anmeldung

*Pflichtfeld
– Anzeige –

29 thoughts on “Die schönsten technischen SEO-Fehler

  • 14. Oktober 2008 at 16:23
    Permalink

    „Wobei URLs mit der Endung .php sowieso eine ganz schlechte Idee sind.“

    -> Das möge mir bitte genauer erklärt werden – hier gehen die Meinungen sehr stark auseinander. Ich denke nicht das Google heute noch Probleme mit dynamischen URLs hat.

  • 14. Oktober 2008 at 16:45
    Permalink

    @Mitterich
    Es geht dabei nicht um „dynamischen URLs“ (eine .php Endung ist zudem auch keine), sondern, wie im folgenden Satz erwähnt, um eine Umstellung auf ein anderes System bzw. einen anderen Applikationsserver (z.B. Ruby).

  • 14. Oktober 2008 at 16:53
    Permalink

    Ich denke, der Autor wollte sagen, dass man bei der Endung .php Probleme bekommen kann, wenn man irgendwann einmal die Website mit einer anderen Technik realiseren sollte. Der Name der verwendeten Technik sollte demnach nicht Bestandteil der URL sein.

  • 14. Oktober 2008 at 17:11
    Permalink

    Herrliche Beispiele – mich würde interessieren wie lange die Geschichte mit der JavaScript Browserweiche aus ist. Das es sowas noch gibt und das niemand merkt??

  • 14. Oktober 2008 at 17:29
    Permalink

    @Mitterich
    Google stört sich in der Tat nicht an irgendwelchen Endungen (so lange es nicht gerade .exe oder .jpg ist). Wollte mit dem Beispiel nur verdeutlichen, dass man beim Starten eines Systems mal kurz übers URL-Design nachdenken sollte. Ansonsten muss man die URLs irgendwann ändern oder man lässt sie, muss dann aber immer die Endung .php mitschleppen, auch wenn die Site schon längst nicht mehr mit PHP läuft.

    @Klaus,
    die Browserweiche liegt schon etliche Jahre zurück, aber ich gehe jede Wette ein, dass derartige „Tricks“ noch immer irgendwo im Einsatz sind. Und alle anderen Beispiele sind topaktuell, aus den Jahren 2007 (Load Balancing) und 2008.

  • 15. Oktober 2008 at 08:16
    Permalink

    Ok, aber warum gerade PHP als Beispiel =)

    Wenn ich das richtig verstehe gibts da doch das identische Problem mit Endungen wie .htm, .html, .jsp, .aspx, etc. – oder?

  • 15. Oktober 2008 at 09:34
    Permalink

    PHP war wohl ein Bsp, da sehr häufig verwendet. Und was willst du anderes verwenden, wenn nicht HTML? 😀

  • 15. Oktober 2008 at 10:58
    Permalink

    .php hab ich halt als Beispiel benutzt, weil es in der typischen Leserschaft von SuchmaschinenTricks am häufigsten verwendet wird. Vielleicht wäre es eindeutiger gewesen, .php3 als Beispiel zu nehmen. Damit würde mein Punkt noch klarer: filetype:php3

  • 15. Oktober 2008 at 13:00
    Permalink

    Zu Punkt 6: Gemäß Deiner eigenen, verlinkten Erläuterung ist das selbstverständlich kein Cloaking, da die Inhalte exakt gleich sind.

  • 15. Oktober 2008 at 14:28
    Permalink

    Das ist die Frage, was du unter „exakt gleichen Inhalten“ verstehst. Auf alle Fälle unterschiedlich ist, dass der Robot einen Status 200 erhält, der Browser eine Antwort mit Status 302, also eine Weiterleitung. Dass nach der Weiterleitung der Browser den gleichen Inhalt erhält wie der Robot ohne diese Weiterleitung, muss der Robot erst mal rausfinden. Und selbst dann ist fraglich, ob der Inhalt „exakt“ gleich ist: Denn mit gestarteter Session sind natürliche andere Funktionalitäten zugänglich, die es sonst nicht gibt – und schon unterscheiden sich die Inhalte wieder. Also ist es sehr wohl Cloaking, denn die gesendeten Antworten sind eben nicht „exakt gleich“.

  • 15. Oktober 2008 at 17:14
    Permalink

    Rein technisch ist es natürlich Cloaking. Man muss sich bei solchen Konstruktionen immer vor Augen halten, das dies nicht von einem Menschen bewertet wird (der die durchaus legitime Intension erkennen würde) sondern von einem Algorithmus der mit dafür verantwortlich ist, die SERPs sauber zu halten. Und aus Sicht einer Suma gilt eben nicht „im Zweifel für den Angeklagten“ sondern für das Gesamtergebnis „saubere SERPs“ ist es vorteilhafter auch einmal einen vermeintlich Unschuldigen durch’s Raster fallen zu lassen.

  • 15. Oktober 2008 at 21:12
    Permalink

    Nachdem ich diesen Artikel inklusive aller Kommentare gelesen habe, ist mir in der Adressleiste meines Browsers ein .php am Ende der URL aufgefallen.
    Auch Profis treffen somit Entscheidungen, die sie später als wenig hilfreich für die Zukunft empfinden. 🙂

  • Pingback: hype.yeebase.com

  • 16. Oktober 2008 at 13:46
    Permalink

    @Hannes,
    jetzt ist mir doch tatsächlich jemand auf die Schliche gekommen. :-/
    Aber die Endung .php ist schon ein großer Fortschritt und letztendlich der (für Webzeiten) langen Historie dieser Website geschuldet. Zum Start der Site hatte ich Frames(!) benutzt und die Endung lautete .php3(!) – beides hat mich bei den folgenden Umstellungen einige Nerven gekostet.

  • Pingback: Die 3 interessantesten Links der Woche - KW 41 : Webdesign & Programmierung Halle - Leipzig

  • 21. Oktober 2008 at 18:25
    Permalink

    „Web-2.0-Alles-ist-Beta-Zeiten“

    *g* sehr schön formuliert. Danke Google!

  • 27. Oktober 2008 at 17:02
    Permalink

    Informativer Artikel, zwei der Fälle habe ich ihn ähnlicher Form auch schon bei einem Kunden erlebt. Gerade mit den Weiterleitungen wird ja gerne mal Schindluder getrieben, meist aus Ermangelung besseren Wissens.

  • 27. Oktober 2008 at 20:59
    Permalink

    Solche Zusammenfassungen sind immer wieder hilfreich für den eigenen Alltag, den der Fehlerteufel schläft bekanntlich nie. Aus diesem Grund vielen Dank für die zahlreichen Hinweise. Ralph

  • 31. Oktober 2008 at 10:53
    Permalink

    Ich nutze mod_rewrite, um die Endung .php in .htm zu rewriten. Genauso kann die jeweilige Endung auch in jede andere Endung rewrited werden. Was meinst Du dazu?

  • 13. November 2008 at 11:08
    Permalink

    @ Wulffy
    Der ModRewrite liefert die Seite anders aus – vor der Auslieferung bleibt alles gleich (also inkl. PHP-Parser), das heißt für mich Deine Lösung ist gut

  • 8. Dezember 2008 at 13:59
    Permalink

    Klar sehr gute Zusammenfassung allerdings für alte Hasen nichts neues, oder?

  • 18. Dezember 2008 at 12:20
    Permalink

    Neues nicht, aber viele Dinge sind drinne, die man schon ganz vergessen hatte, weil man kaum noch damit rechnet, dass jemand diese benutzt.

  • 24. Dezember 2008 at 21:17
    Permalink

    Wo Menschen arbeiten, werden auch Fehler gemacht … Egal ob SEO oder Leihe ;o)

  • 2. Januar 2009 at 12:21
    Permalink

    Na ja, URLs welche mit php enden finden auch nicht gut gelungen, auch wenn die Meinungen da ganz unterschiedlich sind. Ohnehin gibt es nach wie vor Probleme mit dynamischen URLs. Und bei den “dynamischen URLs” geht es in der Tat um die Umstellung auf beispielsweise einen anderen Applikationsserver. Dennoch sind dies schöne Beispiele.

  • 3. Januar 2009 at 22:30
    Permalink

    also „URLs werden ohne Not geändert“ ist der dümmste Fehler überhaupt! und hierzu: „PHP war wohl ein Bsp, da sehr häufig verwendet. Und was willst du anderes verwenden, wenn nicht HTML“ Ich verwende immernoch HTML, zwar sehr anstrengend alles abzuändern, aber nun ja, bin halt „old School“

  • 7. Januar 2009 at 07:12
    Permalink

    “Wobei URLs mit der Endung .php sowieso eine ganz schlechte Idee sind.”

    “ch denke, der Autor wollte sagen, dass man bei der Endung .php Probleme bekommen kann, wenn man irgendwann einmal die Website mit einer anderen Technik realiseren sollte. Der Name der verwendeten Technik sollte demnach nicht Bestandteil der URL sein.”

    -> Den Ansatz finde ich interessant. Zum einen kann man ja jedoch für den Fall einer Änderung der URL Endung eine Weiterleitung über die Konfigurationsdatei für entsprechende URL bereitstellen.

    Zum anderen würde mich jedoch auch interessieren, welche Möglichkeiten es gibt, statische Seiten ohne eine Endung in der URL auszugeben?! Es besteht ja die Möglichkeit mode_rewrite einzusetzen, aber nicht jeder Hoster gestattet eine eigene htaccess Datei.

  • 29. Januar 2009 at 18:01
    Permalink

    Den schönsten Fehler den ich jemals gesehen hab war auf einer Frame Seite auf die ein SEO Losgelassen wurde.
    SEO war auch sehr fleißig in Sachen Onpage Optimierung (Achtung Ironie…). 5.000 Seiten per Hand Meta-Tags eintragen… auf allen Seiten die Absolut gleiche und die alte hat er nicht gelöscht so das Meta-Tags zudem noch doppelt waren. Ebenfalls hat er auf allen Seiten per Hand den gleichen Title eingetragen der nun auch doppelt war.
    Das die Komplete Seite aus Frames bestanden hat ihn aber nicht weiter gestört und das ein kleines leeres Miniframe auf Platz 1 bei Google Rankte selbst wen man nach dem firmen Namen suchte und nicht mal einen Frame Breaker hatte 😀

    BTW. Kommt demnächst ein neuer beitrag hast schon einen Monat nichts mehr geschrieben!?

  • 8. März 2009 at 13:11
    Permalink

    AAuch mir ist beim Drübeschauen der url aufgefallen, dass es sich bei dieser Seite auch um eine php-Endung handelt. Also wieschon gesagt, viele Seos benutzen diese Endung ohne sich darüber Gedanken zu machen.

Comments are closed.