Dass Google mittlerweile JavaScript liest und mindestens seit Mitte des Jahres auch zumindest teilweise ausführt, dürfte sich herumgesprochen haben. Nachdem seit kurzem in den Webmaster-Tools auch eine Art Mobile-UX-Monitoring verfügbar ist (Suchanfragen -> Benutzerfreundlichkeit auf Mobilgeräten) kam am Donnerstag die Ankündigung, dass Google entsprechend „sauberen“ Seiten ein eigenes „Mobile-friendly“-Label in den SERPs spendiert und außerdem bei der Mobilen Suche auch mit dem Ranking Algorithmus experimentiert.

Google interpretiert JavaScript/CSS…

Das kann Google natürlich nur, wenn bei der Beurteilung der Optik einer Webseite nicht nur der HTML-Quellcode herangezogen wird, sondern Google es schafft, die Seite zu zu sehen wie der Nutzer sie auf seinem Gerät sehen würde. Auch dafür gibt’s bereits seit einiger Zeit in den Webmaster-Tools unter Crawling -> Abruf wie durch Google -> Abrufen und Rendern und schließlich dann den Klick auf die URL in der Liste eine Möglichkeit, hier eventuelle Probleme selbst ermitteln zu können. Als hilfreichen Tipp erhält man dort auch mit auf den Weg:

Sorgen Sie für eine optimale Indexierung Ihrer Inhalte: Stellen Sie sicher, dass der Googlebot auf alle eingebetteten Ressourcen zugreifen kann, die für die sichtbaren Inhalte oder das Layout Ihrer Website von Bedeutung sind.

Tatsächlich ist es nun wirklich wichtig, dass man seine Webseite prüft und Google ggf. auch bisher möglicherweise via robots.txt blockierte Ressourcen (JavaScript, CSS, ggf. Webfonts u.ä.) wieder zur Verfügung stellt. Seokratie fordert hier etwas arg provokant „Weg mit der robots.txt“.

… aber leider nicht immer richtig

In einer besseren Welt würde man dem Folge leisten und alles wäre in Butter. Leider ist Google aktuell noch nicht ganz so weit – speziell der Snippet-Extraktor macht immer mal wieder Probleme:

Suchergebnis mit falschem Description-Text
Suchergebnis mit falschem Description-Text

Was läuft hier schief? Der Text 2 Klicks für mehr Datenschutz: … taucht in unserem HTML-Quelltext gar nicht auf. Dafür gibt’s ein <meta name=“description“ … > und um den korrekten sichtbaren Introtext ein <div class=“intro“ itemprop=“description“ >. Der besagte Text kommt aus einem JS-Widget, das in einem externen minifyten JavaScript-Include liegt. An der Stelle an der das Ding tatsächlich eingebunden ist (unmittelbar über dem Intro), ist nur ein leeres div:

Noch besser: Der fälschlicherweise extrahierte Text wird erst via MouseOver angezeigt, ist also auch für den „average user“ beim Aufruf der Seite zunächst gar nicht sichtbar. In den Webmaster Tools stellt sich das auch unproblematisch und absolut korrekt dar:

Rendering von Abruf wie durch Google aus den Webmaster Tools
Kein Problem sichtbar beim Rendering über Abruf wie durch Google

Wir hatten an der Stelle getan was wir konnten, um Google das korrekte Identifizieren der Description zu erleichtern. Das Problem war neu und tauchte erst seit wenigen Tagen auf, es gab allerdings in den letzten Monaten keinerlei Änderungen an unseren Templates für diese Seite in diesem Bereich. Die Ursache musste also an irgendeiner Änderung auf Seiten des Crawlers liegen.

Nach einer Anfrage über das Report-Formular kam tatsächlich eine Antwort, die mich etwas überrascht hat:

Thank you for letting us know.

One way to prevent JavaScript or CSS in separate files from being crawled is to block them (say, with robots.txt) so that Googlebot can’t retrieve them and our indexing systems won’t be able to see your site like an average user.

Das läuft nun auf den ersten Blick ein wenig konträr zu der Ansicht, man solle Google für alles freigeben, was die Optik der Seite in irgendeiner Form beeinflusst.

Google wertet optische Hervorhebungen als semantisch bedeutsam

Ergänzend sei noch ein anderer Fall dargestellt: Für pcgames.de wurde beim letzten Redesign in den Artikeln eine Darstellung gewählt, die die Hierarchie Produkt -> Artikel unterstreichen soll:

Artikel-Header auf PC Games

Die Produkt-/Themenbezeichnung steht gefettet und einen Tick größer über der eigentlichen Artikelüberschrift.

Der HTML-Quelltext für diese beiden Zeilen sieht so aus:

Natürlich ist im <head> auch ein

gesetzt. Genug, so sollte man meinen, dass Google weiß, welche Überschrift der Artikel hat. Tatsächlich entschied sich Google allerdings von Zeit zu Zeit, bei manchen (nicht bei allen) Beiträgen statt des <title>-Elements den zunächst in <h2> gesetzten Produktnamen im SERP-Snippet zu verwenden, auch die Änderung auf die Nutzung von <span> brachte da keine Abhilfe. Selbstverständlich zeigte das Rich Snippet Testing Tool keinerlei derartige Aussetzer.

Das Design der Sturheit des Bots unterzuordnen erschien nun nicht sonderlich attraktiv. Stattdessen hatten wir hier zu einem Design-Trick gegriffen, der leichten Black-Hat-Geruch hat: Wir haben das Design zwar geändert, korrigieren es allerdings anschließend per JavaScript und untersagen Google den Zugriff auf eben jenes JS. Um diesen Design-Hack möglichst performant umzusetzen, geben wir dem <html>-Element via JavaScript einfach eine Zusatzklasse und ändern die Optik dieses Bereichs je nach Vorhandensein dieser Zusatzklasse. Auf die gleiche Weise wird auch das eigentlich über dem Produktnamen eingebundene Produktbild, das von Google trotz der unmittelbaren Nähe zum <h1> zunächst geflissentlich ignoriert wurde, noch einmal direkt im Description-Block mit einzubinden. Google sieht den Artikelkopf also nun so:

Darstellung des eines PC Games Artikels in den Google Webmaster-Tools
Google-Rendering des PC Games Artikels

(1) ist das eigentliche (meist manuell zugeschnittene) Artikelbild, (2) ist das Default-Bild zum Artikel, das wir Google im Text anfüttern und das normale User dann in der Bildergalerie des Artikels finden. (3) ist der verkleinerte und abgeblasste Produktname, (4) ist die unveränderte Headline.

Während der Hack für das Bild auf Anhieb funktioniert hat, kam es trotz der Design-Anpassung des Produktnamens dennoch vereinzelt zu falsch extrahierten Headlines bei Google. Ein Muster war nicht auszumachen. Seit ungefähr zwei Wochen ist allerdings auch dieser Spuk vorbei, ohne dass wir weitere Maßnahmen ergriffen hätten.

Dies gilt übrigens auch für das Phänomen des fälschlicherweise extrahierten JS-Widget-Texts – seit einigen Stunden ist das Problem nun nicht mehr aufgetreten, es bleibt allerdings abzuwarten, ob dieser Zustand von Dauer ist.

Fazit

  1. Google experimentiert v.a. für Google News seit einigen Monaten ziemlich heftig am Extraktor, um die optische Darstellung stärker zu berücksichtigen
  2. Dabei kommt es immer wieder zu Bugs bzw. unerwünschten Ergebnissen, weil Google teilweise offenbar nicht immer korrekt rendert (JS-Widget, die Webmaster-Tools-Anzeige ist hier nicht immer hilfreich) oder auch optische Gestaltung mit semantischer Bedeutung gleichsetzt (Hierarchie vs. Wertigkeit z.B. durch Fettungsgrad bei den Überschriften)
  3. Die Render-Ansicht in den Webmaster-Tools entspricht offensichtlich nicht 1:1 dem, was der Indexer tatsächlich nutzt. Das ist soweit auch logisch, denn Google wird schon aus Performance-Gründen irgendeine Form von Lightweight-Rendering für Indexing-Zwecke einsetzen, die wiederum für Menschen nicht unbedingt immer attraktiv aussehen wird. Die Render-Ansicht in den Webmaster-Tools ist daher manchmal hilfreich, im Zweifelsfall aber eben nicht unbedingt ausschlaggebend.
  4. Wir müssen uns in naher Zukunft darauf einrichten, dass es zunächst verstärkt zu solchen Fehlern kommt. Die werden selten ursächlich nachvollziehbar sein und was heute funktioniert, kann morgen zu Fehlern führen.
  5. Google lernt allerdings offenbar durch Fehlermeldungen der Publisher und scheint auch schnell zu reagieren. Sehr wahrscheinlich werden wir es im Laufe der Zeit dann auch mit immer weniger solcher „Kinderkrankheiten“ zu tun haben.
  6. Die Nutzung des Report-Formulars sollte im Falle von Google News also immer der nächste Schritt sein, wenn interne Fehlerquellen ausgeschlossen wurden.
  7. Neben semantischem Quelltext wird jedoch ab sofort auch ein optisches „Webdesign für doofe Bots“ wichtiger – es muss einfach optisch unmissverständlich sein, was Headline, Intro, Text, Artikelbild etc. sind. Extravaganzen, die ein Mensch problemlos toleriert (wie eben die fetten Produktnamen über der eigentlichen Headline) werden den Bot möglicherweise verwirren. Wenn sich so etwas vermeiden lässt, dann ist das einfacher, als hinterher Workarounds zusammenzuhacken.
  8. Das selektive Blockieren von JavaScript/CSS als (idealerweise vorübergehenden) Workaround für solche Probleme ist zwar hässlich, allerdings unproblematisch und zumindest bis zum Zeitpunkt der besseren Reife des Extraktors auch die von Google offiziell empfohlene Maßnahme. Die Block-Maßnahme bei Babel2 ist also nicht nur unkritisch, sondern offenbar offiziell sanktioniert. Man darf dennoch nicht vergessen, dass das ein letztes Mittel bleiben sollte, keinesfalls der neue Modus Operandi – man segelt hier hart am Cloaking.
  9. Die Wichtigkeit von semantischem Quelltext (Microdata, Schema.org/RDFa) nimmt hierdurch trotzdem nicht unbedingt ab, da davon auszugehen ist, dass Google das auch nach wie vor einliest und zu verschiedensten Zwecken auch auswertet und diese Auszeichnungen auch in Zukunft noch mehr an Bedeutung gewinnen werden.
  10. Wir dürfen allerdings eben nicht mehr davon ausgehen, dass eine semantisch korrekte Auszeichnung unseres Quelltextes bereits hinreichend geeignet ist, um den Extraktor auf den richtigen Trichter zu bringen und zu verhindern, dass der irgendwelchen Blödsinn abgreift. Wir wissen auch aus eigenen Erfahrungen, dass die article/aside-Auszeichnung beispielsweise alleine nicht immer ausreicht, um SERP-Snippet-Darstellungsfehler zu korrigieren; hier half dann bisweilen tatsächlich erst einmal nur ein JS-Workaround.

Durch die Hinzunahme der gerenderten Ergebnisse sowie durch die Anforderungen von Mobile/Responsive, ohne dass man sich dabei über die Bedingungen der Vermarktung hinwegsetzen kann, wird SEO in den kommenden Monaten und Jahren auch technisch immer anspruchsvoller. Mit Langeweile ist jedenfalls auf absehbare Zeit sicher nicht zu rechnen.

Ein Gedanke zu „Googles Snippet-Extraktor vs. JavaScript

  1. Interessante Erkenntnisse – am einfachsten hat man es wohl, wenn das Design der semantischen Auszeichnung entspricht (Gewünschter Titel das größte Element z.B.)

    Das es ständig technische Neuerungen gibt beobachten wir aber auch – Google experimentiert auch sonst in den SERPs gerne mal etwas rum. Ist nur die Frage ob es besser wird dadurch bzw. was Google sich davon verspricht, etablierte Auszeichnungen schwächer zu bewerten bzw. zu ignorieren.

    Kommentiere

Kommentar verfassen