10 exotische SEO-Fehler und elegante Lösungen dafür

Dabei handelt es sich nicht unbedingt um die 10 typischsten oder häufigsten SEO-Fehler, sondern einfach eine kleine Sammlung an typischen aber auch exotischen Fehlern, die mir in letzter Zeit begegnet sind. Vielleicht ist ja auch der ein oder andere Bereich dabei, den es sich mal lohnt auf eurer Seite zu prüfen oder der bei zukünftigen Projekten einfach schon mit bedacht werden sollte.

Die meisten Unternehmen arbeiten mit einer sogenannten Staging-Umgebung, um Änderungen an der Seite zu testen oder bspw. bei einem Relaunch der Seite die Qualitätssicherung vor dem GoLive durchzuführen.

Diese Umgebung ist dabei im Grunde eine 1 zu 1 Kopie der aktuellen oder neuen Seite und liegt häufig auf einer Subdomain wie z. B. staging.domain.com. Diese Seite sollte dabei allerdings nicht für den Googlebot crawlbar sein und keinesfalls indexiert werden (Duplicate Content!).

Sieht man sich allerdings einmal die SERPs per inurl:-Abfrage an, findet man jede Menge indexierte Staging-Umgebungen. Ob die eigene Staging-Umgebung im Index ist, erkennt man z. B. einfach mit der entsprechenden site:-Abfrage in Google. Lautet die Adresse der eigenen Staging bspw. http://staging.domain.com, gibt man einfach folgenden Befehl in Google ein: site:staging.domain.com und schon sieht man, ob die eigene Staging-Umgebung von Google indexiert wurde.

Wie verhindert man die Indexierung? Ein häufig gewählter Ansatz ist das Sperren der Staging-Umgebung über die robots.txt. Was dann passiert sieht man allerdings am Beispiel der Seite cinemacon.com:

Zumindest die Startseite der Staging-Version landet im Google Index – theoretisch könnten bei entsprechender externer Verlinkung aber auch alle anderen Seiten in den Index gelangen. Doch dazu später mehr.

Der sicherste Weg, um die Staging-Umgebung folglich aus dem Index zu halten ist ein Passwortschutz.

Ein weiterer häufiger Fehler, den man bei einem Relaunch oftmals sieht, ist die Verlinkung der neuen Seite auf die Testumgebung.

Die neue Seite wurde im Rahmen des Relaunches folglich live geschalten, einige dieser Links verlinken dabei aber auf die Testumgebung. Dies passiert häufig, wenn auf der Testumgebung mit absoluten Links statt mit relativen Links gearbeitet wurde.

Dabei muss es sich aber nicht ausschließlich um interne Links handeln, auch das hreflang oder Canonical-Tags verweisen nach einem Relaunch oftmals noch auf die Testumgebung.

Hier hilft nur ein ausgiebiges Testen der neuen Version und eine Überprüfung auf fehlerhafte Links, Canonical-Tags und hreflang-Anweisungen.

Fehler Nummer 4 ist wohl eher ein exotischer, aber nicht minder gravierender Fehler: ein falscher Status Code für die robots.txt.

Während vor einigen Jahren noch die Empfehlung galt, dass jede Seite eine robots.txt benötigt, sagt Google mittlerweile, dass eine robots.txt nicht zwingend notwendig ist. Wenn Google also unter im Root-Verzeichnis domain.com/robots.txt keine robots.txt findet, crawlt es die Seite dennoch.

Folglich sollte es zwei mögliche Szenarien geben. Entweder die Adresse domain.com/robots.txt spielt einen Status Code 200 aus und es wurde unter diese Adresse eine robots.txt hinterlegt. Oder aber Google bekommt beim Aufruf dieser Adresse einen Status Code 404 zurückgespielt, weiß somit, dass keine robots.txt hinterlegt ist und crawlt die Seite anschließend.

Ein sehr exotischer Fehler, welcher mir dabei im letzten Jahr begegnet ist, war der Fall, dass keine robots.txt hinterlegt wurde und der Aufruf der Adresse aber einen Status Code 500 (Serverfehler) zurückgegeben hat.

Dies führte dazu, dass Google sofort das Crawling einstellte und die Seite während diesem Zeitraum nicht mehr crawlte. Der Grund hierfür ist, dass Google bei einem 5xx Statuscode davon ausgehen muss, dass die Seite aufgrund eines Serverfehlers derzeit nicht erreichbar ist, aber auf dieser Seite eine robots.txt mit Sperr-Anweisungen hinterlegt sein könnte (siehe hierzu auch die entsprechenden Spezifikationen von Google).

Gerade Online-Shops, die aus Performance-Gründen nicht alle Artikel auf eine Seite darstellen wollen, nutzen eine Paginierung, um die Produkte über mehrere Seiten verteilt darzustellen.

Da sich auf diesen Seiten nur die Produkte selbst unterscheiden, bergen diese Seiten die Gefahr durch Google als Near Duplicate Content gewertet zu werden.

Die Empfehlung von Google lautet hierfür die Seiten entsprechend mit und rel="next" auszuzeichnen. Dadurch erkennt Google den Zusammenhang und indexiert (zumindest in der Theorie) nur die wichtigste Seite, welche im Normalfall die erste Seite ist. Oftmals werden zur Sicherheit auch noch die Folgeseiten auf „noindex" gesetzt.

Einen häufig beobachteten Fehler, den man bei der Paginierung aber keinesfalls machen sollte, ist das Setzen eines Canonicals von allen Folgeseiten jeweils auf Seite 1.

Dies führt dazu, dass der Linkjuice gebündelt auf Seite 1 weitergeleitet wird und dadurch die Produkte auf den Folgeseiten keinen Linkjuice erhalten.

Eine beliebte Methode, um mit Produktseiten mehr Aufmerksamkeit in den SERPs zu bekommen, ist die Auszeichnung der Produkt-Reviews (Sternebewertungen) mit strukturierten Daten.

Dadurch besteht die Möglichkeit, dass Google diese Sterne in den Suchergebnissen in Form von Rich Snippets einbindet:

Wichtig ist hierbei jedoch, dass tatsächlich nur Reviews ausgezeichnet werden dürfen, welche auch für den Nutzer auf der Seite sichtbar sind!

Die Auszeichnung von nicht auf der Seite vorhandenen Reviews ist ein klarer Verstoß gegen die Structured Data Guidelines und kann zu einer manuellen Penalty inklusive erheblichem Sichtbarkeits- und Trafficeinbruch führen, wie dies bei zahlreichen Seiten im Jahr 2017 der Fall war.

Über eine derartige manuelle Penalty wird man dann direkt in der Google Search Console benachrichtigt. Hat man den Rich Snippet Spam dann beseitigt und einen erfolgreichen Reconsideration-Request gestellt, dauert es ca. 2 Wochen bis Rankings und Traffic sich wieder vollkommen erholt haben.

Ein weiter kurioser Fehler ist mir im letzten Jahr begegnet, als ich bei einem Neukunden entdeckt habe, dass zahlreiche seit Jahren veraltete URLs im Index waren, von denen der Websitebetreiber sicher war, dass sie passend weitergeleitet wurden.

Hat man anschließend in den SERPs auf derartige Seiten geklickt, wurden diese augenscheinlich auch auf eine passende neue URL weitergeleitet.

Hat man die Weiterleitung allerdings mit einem Tool wie dem Link Redirect Trace von LRT geprüft, hat man schnell gesehen, dass es sich um keine serverseitige Weiterleitung handelte, sondern der Nutzer lediglich per Meta-Refresh auf die neue Seite geschickt wurde. Google konnte diesen Weiterleitungen also nie folgen, sdass diese veralteten URLs niemals aus dem Index verschwinden konnten.

Wichtig ist daher regelmäßig auch mal den Index zu prüfen (oder die Logfiles), um eventuelle Altlasten zu identifizieren und zudem veraltete Inhalte immer per 301 Redirect auf das neue Ziel zu leiten.

Hin und wieder erlebt man als SEO auch, dass die IT stolz berichtet, dass bspw. das hreflang-Attribut oder rel="prev" und rel="next" nun eingebunden sei. Allerdings ist es mit der alleinigen Einbindung dieser Elemente irgendwo auf der Seite nicht getan. Wichtig ist, dass diese auch an der richtigen Stelle eingebunden werden.

So verfällt die Wirkung der hreflang-Attribute oder von rel="prev" und rel="next", wenn diese im <body> der Seite eingebunden werden – dort werden sie von Google schlicht ignoriert. Hier also immer darauf achten und prüfen, ob die IT diese Elemente tatsächlich auch im <head> der Seite eingebaut hat.

Wichtig ist auch beim Auditing darauf zu achten, möglichst genau den Blick von Google auf eine Seite zu simulieren.

Dies bedeutet die Seite möglichst mit einem Google-User-Agenten zu crawlen, dabei idealerweise aber auch eine amerikanische IP (per Proxy / VPN) zu nutzen.

Möchte man nur einzelne Seiten betrachten, ist auch hier das Mobile-Friendly-Testing-Tool eine Quick-and-Dirty-Lösung.

Hier einfach die zu prüfende URL eingeben, im Testergebnis auf HTML klicken, Code in einen Editor hineinkopieren und schon lässt sich in Ruhe der Quellcode aus Sicht von Google analysieren.

Hier gab es durchaus schon Fälle, bei welchen man dann gesehen hat, dass aus der „index"-Anweisung, welche die manuelle Prüfung ergab, eine „noindex"-Anweisung für Abrufe mit amerikanischer IP wurde.