Die OneBox ist für uns eine überaus wichtige Traffic-Quelle. Umso wichtiger ist es, dass unsere News-Artikel hier zeitnah auflaufen und auch angemessen ranken. Die Mechanismen für Google News sind selbstverständlich umgesetzt, neben dem Basis-Programm wird Google auch via Sitemap-Ping unmittelbar zur Veröffentlichung einer News informiert – wir haben bisweilen eine neue News innerhalb von 30 Sekunden nach Veröffentlichung in der OneBox gesehen.

Unser Problem mit der OneBox bei einer unserer Seiten betraf allerdings News, die schon ein paar Minuten alt waren. Dort hatte Google bisweilen das Datum der News in die Vergangenheit verlegt, so dass eine News, die gerade erst eine dreiviertel Stunde online war nun plötzlich als „vor drei Tagen“ in der OneBox auflief – wenn denn überhaupt, denn mit der vermeintlichen Altersschwäche der Artikel sank auch die Wahrscheinlichkeit, überhaupt in der OneBox zu ranken – kein Wunder, da es dem Artikel nach Googles Ansicht ja an „Freshness“ mangelte.

Das Problem betraf allerdings exklusiv die OneBox, in Google News selbst war der Zeitstempel zu jedem Zeitpunkt korrekt. Selbstverständlich war das Artikeldatum sowohl in der Sitemap als auch über Schema.org im Artikel selbst richtig deklariert.

Die ganzen Details des Elends habe ich im Webmaster-Forum beschrieben, ich hatte das zusätzlich auch als Frage an John Müller im Webmaster Hangout gestellt, doch beides letztlich ergebnislos.

Der Weg der Fehlersuche und -Korrektur war recht lang. Dabei haben wir erfahren, dass die News in der OneBox sich keineswegs exklusiv aus Google News speisen. Google Search nutzt Google News nur für die allerneuesten Artikel, die erst wenige Minuten alt sind, später wird das mit eigenen, nach Google Search-Ermessen „passenden“ Daten angereichert bzw. überschrieben. Hierbei werden auch die Snippets mitsamt dem erkannten Artikeldatum, die Google News bereits korrekt extrahiert hat, durch Google Search-Daten überschrieben.

Google News setzt schon aus Gründen der Beschleunigung des Parsings ausschließlich auf Signale aus Sitemap und Quelltext. Für unsere Seiten ist hier zum besseren Ausschluss von nicht-News-würdigen Inhalten das Sitemap-only-Crawling für Google News aktiviert (geht über Anfrage via Support-Formular).

Google Search setzt dagegen auf eine Kombination von Rendering der Artikelseiten und Quelltext-Analyse aus dem Crawler. An welcher Stelle und nach welchen Kriterien das kombiniert wird, ist niemals völlig transparent. So kommt es vor, dass trotz Sitemap-Only-Google-News-Crawling in der OneBox auch Artikel und URLs landen, die in der News-Sitemap gar nicht aufgeführt sind und sogar ein

enthalten.

Und so konnte es vorkommen, dass Google sich hier an einem völlig falschen Element im Quelltext vergriff.

Das eigentliche Artikeldatum war, wie bereits erklärt, mit Schema.org-Microformaten als solches ausgezeichnet. Dieses Datum war auch sowohl im Quelltext das allererste Datum als auch in der gerenderten Seite weit oben prominent platziert (mit Rendering-Ansicht in Webmaster-Tools überprüft). Das Datum, das Google sich gegriffen hat, stand im Quelltext verhältnismäßig weit unten, in der gerenderten Ansicht in der rechten Spalte als Teil eines Teasers für weiterführende Artikel zum Thema.

Interessanterweise blenden wir diesen gesamten Block via CSS in einigen unserer News-Artikel sogar aus, wenn die linke Spalte zu kurz gerät, um dieses Element in der rechten Spalte unterzubringen. Das vollständige Fehlen des Elements in der gerenderten Ansicht hindert Google Search allerdings nicht daran, auch in diesem Fall das falsche Datum aus diesem Element zu extrahieren und damit das richtige Datum, das auch von Google News korrekt erkannt wurde, zu überschreiben.

Wir haben das Problem nun behoben, indem wir in diesem Element fürs erste vollständig auf die Ausgabe des Artikeldatums der verlinkten Artikel verzichten – wir wollten erst einmal auf Nummer sicher gehen, was die korrekte Identifizierung der Ursache angeht. Der eigentliche Grund, warum Google Search aber auf dieses Datum angesprungen ist und dafür das Schema.org-Datum verschmäht, liegt darin, dass Google trotz vieler Beteuerungen zumindest für manche Einsatzzwecke immer noch nicht wirklich auf den HTML5-/Mikroformate-Zug aufgesprungen ist und stattdessen auf archaischere Methoden setzt.

In der Urzeit, kurz nachdem die Molche aus dem Wasser gekrochen sind, vor der Erfindung von HTML5 und Mikroformaten, kam Google wohl auf die Idee, der Parser sollte auf Signale aus Klassennamen anspringen, um solch wichtige Daten wie eben das Publishing-Datum aus dem Quelltext zu extrahieren. Diese Mechanismen unter dem Oberbegriff „semantisches CSS“ sind immer noch vorhanden und haben unglücklicherweise offensichtlich zumindest in manchen Fällen eine höhere Signalstärke als die eindeutigen Schema.org-Auszeichnungen und Angaben in den Sitemaps.

Konkret hatten wir das Datum der „Aktuelles zu“-Artikel mit einem

ausgezeichnet. Die timeago-Klasse wurde für die im Design vorgesehene Ersetzung des Datums mit einer „vor x Minuten/Stunden…“-Angabe benötigt, die articleTime-Klasse ist für das gewünschte Aussehen dieses Elements zuständig.

Böser Fehler. „articleTime“ ist ein semantischer Klassenname. Das ist zwar nirgendwo offiziell standardisiert oder auch nur konsistent dokumentiert, doch deskriptive Klassennamen, aka semantisches CSS, können dazu führen, dass ein Suchmaschinen-Parser aus dem Tritt gerät.

In unserem Fall haben wir Google hier unabsichtlich auf eine falsche Fährte geführt und der Google Search Parser fand diesen roten Hering offenbar leckerer als jede itemprop=“datePublished“-Schema.org-Auszeichnung.

Die Empfehlung kann daher nur lauten, auf semantisches CSS dort zu verzichten, wo bereits HTML5- und/oder Schema.org zur semantischen Deklaration eingesetzt wird. Der Einsatz der neueren, eindeutigeren Spezifikation genügt nicht, um hier gegenüber möglicherweise vorhandenen veralteten Mechanismen zu gewinnen. Selbsterklärende Klassennamen sind natürlich eine gute Praxis, allerdings müssen solche Klassennamen mit Bedacht gewählt werden, immer unter dem Gesichtspunkt: Könnte ein pseudo-intelligenter Parser hier möglicherweise etwas falsches hineininterpretieren?

Das ist teilweise nicht so einfach, wenn einerseits gewährleistet werden soll, dass auch externe Designer (v.a. im Offshoring-Kontext) im Bedarfsfall schnell in die Projektarbeit integriert werden können, was unweigerlich die möglichst konsistente Verwendung englischer Begriffe bedingt. Es gibt sicher erst einmal keine Patent-Lösung des Dilemmas, außer dem Parser das Erkennen dieser Begriffe hinreichend zu erschweren. Lolspeak wäre eine Option:

Denn ich, der HERR, dein Gott, bin ein eifriger Gott, der da heimsucht der Väter Missetat an den Kindern bis in das dritte und vierte Glied [..].

2. Mose 20,5

Dass für die Sünden der Vergangenheit noch lange gebüßt werden muss gilt eben auch für die Vermischung von Semantik und CSS.

Kommentar verfassen