Google crawlt JavaScript fehlerhaft – „Sorry, we have no imagery here“ in Suchergebnis und Content-Keywords

In den praktischen Google Webmaster Tools findet sich eine Auflistung aller Keywords, die Google auf einer gecrawlten Webseite erkennt – sortiert nach Häufigkeit auf der gesamten Webseite („Google-Index“, „Content-Keywords“). Da diese Liste einen wichtigen Ranking-Faktor für Google darstellt, behalte ich sie immer im Auge. Unlängst staunte ich nicht schlecht, als dort die Worte „have„, „imagery“ und „sorry“ mit hoher Relevanz in der Top5 auftauchten. Ein kurzer Check der Seite zeigte: Keine einzige Unterseite der deutschsprachigen Webseite beinhaltete diese Worte. Woher kamen sie also – und dann noch in dieser sehr relevanten Menge?

Ursache: Fehler in Google Maps API Karte
Des Rätsels Lösung ist in mehrfacher Hinsicht interessant: Der Google Crawler scheint mittlerweile das Javascript einer Webseite auszuführen und indiziert den Inhalt der Webseite NACHDEM das JavaScript ausgeführt wurde. Meine von der Keyword-Verwirrung betroffene Webseite enthält auf sehr vielen Unterseiten Karten der Google Maps API. Bei einer hohen Zoomstufe und fehlenden Bildern wird hier pro Bildkachel die Fehlermeldung „Sorry, we have no imagery here“ ausgegeben. Der Google Spider scheint diesen Fehler zu verursachen – ironischerweise bei seinem eigenen Google Maps API JavaScript. In Folge dessen werden die wichtigsten Wörter des Satzes mit in den Google Content Index aufgenommen. Da der Satz für jede Bildkachel mit fehlenden Bildinformationen ausgegeben wird, entsprechend mehrfach pro Seite.

Die Folge ist dramatisch: Die kruden Keywords „have“, „imagery“ und „sorry“ erscheinen sehr weit oben in Googles Keyword-Wahrnehmung der betroffenen Webseiten. Googelt man den Satz „Sorry, we have no imagery here“ listet Google mittlerweile Millionen Webseiten mit dem vermeintlichen Text im Inhaltsbereich der Webseite (derzeit 4,590,000,000). Selbst die offizielle Webseite der Google Maps API Dokumentation ist betroffen. In Sachen SEO (Suchmaschinenoptimierung) sicherlich ein Albtraum.

Lösung
Abhilfe schafft hier ein kleiner Hack: Im Normalfall sieht Googles Crawler „GoogleBot“ es nicht gerne, wenn man ihm andere Inhalte serviert als normalen Benutzern. Aber in diesem von Google selbst verschuldeteten Fall bleibt scheinbar keine andere Wahl und Google drückt hoffentlich ein Auge zu. Sobald der GoogleBot vorbei schaut, muss die Google Maps API Karte runter von der Webseite, damit der fehlerhafte Inhalt nicht indiziert wird. Hierzu gibt es mehrere Möglichkeiten, bei allen wird abhängig vom erkannten UserAgent ein spezielles Verhalten getriggert:

Lösung 1: Clientseitiger Check im JavaScript
Die Google Maps API Karte wird nur angezeigt, falls der UserAgent per JavaScript nicht als GoogleBot erkannt wird. Sollte überall funktionieren, macht Google aber auch im JavaScript-Code transparent, dass man für den GoogleBot eine Sonderlocke strickt.

if (navigator.userAgent.toLowerCase().indexOf(‚googlebot‘) < 0) {
   // Code for Google Maps API
}

Lösung 2: Serverseitiger Check, z.B. im PHP
Als Best Practice zur Einbindung einer Google Maps API Karte hat sich eingebürgert, auf der Webseite ein leeres DIV als spätere Zeichenfläche für die Google Maps Karte anzulegen. Dieses wird mit einer HTML-Klasse oder -ID adressiert, der DOM-Knoten auf Existenz geprüft und dann per JavaScript mit der gewünschten Karte befüllt. Einfachster Ansatz in der serverseitigen Lösung: Bei einem Besuch des GoogleBot wird die entsprechende HTML-Klasse/-ID einfach leicht abgeändert. Das JavaScript der Webseite findet so das DIV für die zu zeichnende Karte nicht mehr, rendert keine Karte, es gibt für den Google Bot also auch keinen Fehler. Eine charmante Lösung, da für Google von der Codeseite her nicht gleich transparent ist, dass man für den GoogleBot separaten Code ausliefert. Zum Testen einfach mal die Webseite mit einem UserAgentSwitcher als „GoogleBot“ aufrufen (UserAgentSwitcher für Firefox, UserAgentSwitcher für Chrome).

<div class=“googleMapsCanvas<?php
echo (stripos($_SERVER[„HTTP_USER_AGENT“], „Googlebot“) ? ‚Foo‘ : “);
?>„>

Praxistest
Die serverseitige Lösung habe ich nun seit etwa einem Monat auf der betroffenen Webseite laufen. In den Content-Keywords erscheinen die fehlerhaften Keywords „sorry“, „have“ und „imagery“ jetzt nur noch weit hinten innerhalb der Top 20. Sobald Google alle Unterseiten der Webseite neu indiziert hat, sollten sie komplett verschwunden sein. Die GoogleBot-spezifische Auslieferung der HTML-Klasse/-ID hat Google bisher nicht beanstandet.