JavaScript SEO-Überraschung! Google verwendet JS-injected Canonical Tags.

Auf der I/O 2018 gab Google bekannt, dass sie keine kanonischen Tags verwenden, die nur im gerenderten HTML und nicht im HTML-Quelldokument zu finden sind. Unsere Testergebnisse legen nahe, dass diese Aussage nicht stimmt.

Auf der I/O 2018 hielten John Mueller und Tom Greenaway von Google einen hervorragenden Vortrag über SEO für JavaScript-Websites. Während des Vortrags erwähnte Tom Greenaway, dass Google nicht nach Canonical Tags im gerenderten HTML einer Seite sucht. John Mueller bestätigte diese Aussage später mehrfach auf Twitter. Die Ankündigung machte uns neugierig, denn wir hatten zuvor Tests durchgeführt, die uns glauben ließen, dass kanonische Tags, die mit JavaScript über den Google Tag Manager injiziert wurden, NICHT funktionieren. Nach der I/O-Ankündigung beschlossen wir, einen neuen Test durchzuführen. Hier sind die Ergebnisse.

Beachte, dass es bei diesem Experiment nicht darum geht, ob du GTM oder JavaScript verwenden solltest, um kritische Elemente in eine Seite einzubauen oder nicht. Das Problem, um das es in diesem Test geht, ist die Frage, wie Google mit Websites umgeht, die seitens des Clients von JavaScript abhängen - eine Frage, die im Zeitalter der beliebten JavaScript-Frameworks äußerst wichtig ist.

Du bist in Eile? Hier geht es direkt zur TL;DR Abschnitt!!

Rückblick auf unseren Test "Canonical Tags über GTM" vom letzten Jahr

Die Ankündigung von Google hat uns überrascht, denn unsere früheren Tests hatten angedeutet, dass kanonische Tags und andere SEO-relevante Elemente immer aus dem gerenderten HTML gezogen werden, sobald sie verfügbar sind, und nicht mehr aus dem HTML-Quelldokument. Hat Google die Art und Weise geändert, wie sie mit JS-injizierten kanonischen Tags umgehen? Oder war unsere Interpretation der früheren Testergebnisse falsch?

Unser Canonical-Tags-Testergebnis vom letzten Jahr basierte auf nur einer URL. Wir hatten also ziemlich schwache Beweise für die Behauptung, dass Google kanonische Tags verwendet, die mit JS injiziert werden. Das Ergebnis unseres Tests könnte einfach nur ein großer Zufall gewesen sein: Google könnte sich aus anderen Gründen dazu entschieden haben, unsere Test-URL mit dem Ziel unseres JS-injizierten kanonischen Tags zu kanonisieren.

Das ist ein allgemeines Problem beim Testen, ob kanonische Tags funktionieren oder nicht: Du kannst kanonische Tags nur zwischen sehr ähnlichen Seiten verwenden, die wahrscheinlich sowieso kanonisiert werden. Andernfalls riskierst du, dass deine kanonischen Tags komplett ignoriert werden. Andererseits kannst du, wenn deine Seiten mit kanonischen Tags kanonisiert werden, nicht 100% sicher sein, dass dies wirklich auf die kanonischen Tags zurückzuführen ist.

Info: Wenn du denkst: "Warum prüfen sie nicht einfach die neuen GSC-Index-Coverage-Berichte?", dann habe bitte etwas Geduld und lies weiter. Wir kommen schon noch dazu.

Bei unserem Test im letzten Jahr haben wir ein kanonisches Tag in meine Autorenseite auf der englischen Version dieses Blogs eingefügt, das auf die Hauptseite des Blogs verweist. Seitdem ist die Autorenseite auf die Hauptblogseite kanonisiert, was verifiziert werden kann mit der Verwendung von info: Search Operator für die URL in Google (Bildschirmfoto vom 11. Mai 2018):

Die Kanonisierung erfolgte, nachdem wir mit dem Google Tag Manager ein kanonisches Tag mit JS injiziert hatten, und keine anderen Autoren- oder Kategorieseiten auf unserer Website waren jemals auf ähnliche Weise kanonisiert worden (mit oder ohne JS-injizierte kanonische Tags). War das wirklich nur ein Zufall?

Einrichten unseres neuen Tests nach der E/A

Nach Googles Ankündigung auf der I/O wollten wir genau dieses Ergebnis für weitere URLs replizieren. Also haben wir JS und GTM verwendet, um kanonische Tags zu injizieren, die auf die Hauptblogseite zeigen, in vier weitere Kategorie- und Autorenseiten auf unserem Blog einzufügen. Wir haben auch darauf geachtet, zwei ähnliche Seiten (meine deutsche Autorenseite und Michaels englische Autorenseite) unberührt zu lassen, um eine Kontrollgruppe von URLs zu haben, die keine kanonischen Tags erhalten, die auf andere Seiten verweisen, und die daher von Google nicht kanonisiert werden sollten. Wenn eine unserer Kontroll-URLs auf die Hauptblogseite kanonisiert wurde, ohne dass wir ein kanonisches Tag eingefügt haben, könnte das bedeuten, dass die Test-URLs aus anderen Gründen als den von JS eingefügten kanonischen Tags kanonisiert wurden.

Hier sind die vier neuen Test-URLs, für die wir am 11. Mai, einen Tag nach Googles I/O-Ankündigung, JS-injected canonical tags eingerichtet haben (alle Screenshots wurden am 11. Mai aufgenommen).

Englische Kategorieseite "SEO-Experimente":

Englische Kategorieseite "SEO für Website-Relaunches":

Deutsche Kategorieseite "SEO für Website-Relaunches":

Michaels deutsche Autorenseite:

Beachte, dass die letzte Test-URL oben, Michaels deutsche Autorenseite, zum Zeitpunkt der Einrichtung des kanonischen Tags auf seine englische Autorenseite kanonisiert war, ein Problem, das wir oft bei verschiedenen Sprachversionen von Seiten sehen, die keine korrekten hreflang-Anmerkungen haben. Zum Zeitpunkt des Screenshots fehlten die hreflang-Anmerkungen, die jetzt auf der Seite zu finden sind. Keine der anderen drei Seiten war zum Zeitpunkt der Screenshots kanonisiert und unseres Wissens nach waren sie auch zu keinem Zeitpunkt in der Vergangenheit kanonisiert worden.

Warten auf die Ergebnisse

Nachdem wir die kanonischen Tags eingefügt hatten, warteten wir ungeduldig. Aus unserer Erfahrung mit früheren Tests wussten wir, dass dies Zeit braucht, da solche Änderungen mehrere Monate dauern können, bis sie wirksam werden. Das liegt daran, dass Google Seiten nicht so oft rendert, wie sie neu gecrawlt werden, ohne sie zu rendern. Und je weniger wichtig eine Seite ist, desto seltener wird sie neu gecrawlt und noch seltener gerendert. Wenn du ein SEO-relevantes Element wie ein kanonisches Tag, eine hreflang-Anmerkung oder ein "noindex" in das gerenderte HTML einfügst, es aber nicht in das HTML-Quelldokument einfügst, musst du dich darauf einstellen, dass du lange warten musst, bis du Ergebnisse siehst.

Google beginnt, unsere Test-URLs zu kanonisieren

Die erste unserer Testseiten, die auf das Ziel unseres JS-injizierten canonical Tags kanonisiert wurde, war unsere englische Kategorieseite "SEO für Website-Relaunches". Wir bemerkten die Änderung am 21. Mai, 10 Tage nach der Einfügung des Canonical Tags. Hier ist ein neuer Screenshot der entsprechenden info: Such-Operator Ergebnis:

Als Nächstes wurde die englische Kategorieseite "SEO-Experimente" kanonisch gemacht. Dies dauerte deutlich länger und wir bemerkten die Veränderung am 3. Juni, 23 Tage nach dem Einfügen des kanonischen Tags:

Am 4. Juni, 24 Tage nach dem Einfügen des kanonischen Tags mit JavaScript, wurde die deutsche Kategorieseite "SEO für Website-Relaunches" auf die Hauptblogseite unserer deutschen Website-Version kanonisiert:

Unsere vierte Test-URL, Michaels deutsche Autorenseite, ist zum Zeitpunkt des Verfassens dieses Artikels (25 Tage nach dem Einfügen des kanonischen Tags) noch nicht kanonisiert worden, aber wir sind sehr zuversichtlich, dass auch diese Seite innerhalb des nächsten Monats oder so auf das Ziel des von JS eingefügten kanonischen Tags kanonisiert werden wird:

Update (13. Juni 2018): Diese URL ist jetzt kanonisiert worden, 34 Tage nach dem Einfügen des kanonischen Tags.

Was denkst du, wenn du dir diese Daten ansiehst? Ist es ein Zufall, dass drei unserer vier Test-URLs auf die Ziele der kanonischen Tags, die wir mit JavaScript injiziert haben, kanonisiert worden sind? Oder verwendet Google immer noch JS-injizierte kanonische Tags, obwohl sie offiziell erklärt haben, dass dies nicht der Fall ist? Und wenn ja, warum haben sie gesagt, dass sie es nicht tun?

Bevor wir voreilige Schlüsse ziehen, lass uns über einige andere Dinge sprechen, die du über diesen Test wissen solltest.

"Fetch and render > Request indexing" in GSC scheint die Dinge nicht zu beschleunigen

Nachdem wir am 11. Mai die kanonischen Tags eingefügt hatten, führten wir für alle unsere Test-URLs einen "Fetch and render > Request indexing" durch:

Am 22. Mai haben wir Crawling und Indexierung für unsere Hauptblogseiten und alle verlinkten Seiten angefordert, da alle unsere Test-URLs direkt von den Hauptblogseiten verlinkt sind. Am 1. Juni führten wir einen weiteren "Fetch and render > Request indexing" für die drei verbleibenden Test-URLs durch, die zu diesem Zeitpunkt noch nicht kanonisiert worden waren.

Wir wissen, dass "Abrufen und Rendern > Indexierung anfordern" normalerweise eine fast sofortige Wirkung hat, wenn du damit eine neue URL übermittelst. Es scheint aber keinen Einfluss auf das Rendern einer Seite zu haben, zumindest nicht immer. Unsere Anfrage vom 1. Juni könnte die Kanonisierung von zwei unserer Test-URLs am 3. und 4. Juni ausgelöst haben, aber die Anfrage vom 11. Mai hatte sicherlich keine unmittelbare Auswirkung. Ein weiterer Faktor könnte sein, dass Google eine Seite mehr als einmal rendern muss, bevor es sich entscheidet, ein eingefügtes Canonical Tag zu übernehmen.

Der neue Search Console Index-Coverage-Bericht sagt nicht die ganze Wahrheit

Zum Zeitpunkt des Verfassens dieser Zeilen werden unsere Test-URL vom letzten Jahr und unsere neue Test-URL, die am 21. Mai kanonisiert wurde, im neuen Index-Coverage-Bericht der Google Search Console als "Eingereichte URL nicht als kanonisch ausgewählt" angezeigt:

Die beiden Test-URLs, die am 3. und 4. Juni kanonisiert wurden, werden immer noch als "Eingereicht und indexiert" angezeigt, weil die Daten, die GSC anzeigt, nicht aktuell sind, aber ich erwarte, dass sie in den nächsten Tagen als "Eingereichte URL nicht als kanonisch ausgewählt" angezeigt werden.

Wenn Google ein kanonisches Tag auf einer Seite findet und es respektiert, würden wir erwarten, dass der Status der URL im neuen Indexbericht "Alternative Seite mit richtigem kanonischen Tag" lautet. Was ist hier los?

Ich habe eine einfache Theorie, um dies zu erklären: Der Index-Coverage-Bericht der Google Search Console verhält sich genau so, wie es Tom Greenaway und John Mueller auf und nach der I/O angekündigt haben - er ignoriert kanonische Tags, die nicht im HTML-Quelldokument enthalten sind. Er spiegelt also das Verhalten wider, das Google offiziell kommuniziert, und nicht das, das die Ergebnisse dieses Tests offenbaren.

Die Google Search Console hat Informationen darüber, welche URLs indexiert werden, und sie hat eine Reihe von Regeln, von denen sie ausgeht, dass Google diese für die Indexierung verwendet. Dann verwendet es dieses Regelwerk, um Berichte zu erstellen. Wenn sich das Regelwerk, das GSC für die Erstellung seiner Berichte verwendet, von den Regeln unterscheidet, die Google tatsächlich für die Indexierung verwendet, zeigen die Berichte falsche Informationen.

Das scheint bei JS-injected Canonical Tags der Fall zu sein: Google verwendet sie zwar, um Seiten kanonisch zu machen, aber GSC glaubt, dass es das nicht tut. Deshalb werden diese URLs am Ende als "Übermittelte URL nicht als kanonisch ausgewählt" statt als "Alternative Seite mit richtigem kanonischen Tag" markiert. Und das könnte auch erklären, warum John Mueller 100% davon überzeugt ist, dass Google keine JS-injected Canonical Tags verwendet:

Ich bin mir sicher, dass John Mueller genau weiß, wie der GSC funktioniert, und ich bin mir auch sicher, dass das GSC-Team genaue Informationen liefern will. Aber wenn es innerhalb von Google ein Missverständnis oder einfach nur einen Fehler gibt (JS-injected canonical tags sollten nicht verwendet werden, werden es aber), dann können selbst offizielle Aussagen und Berichte von Google falsch sein.

TL;DR

  • Google hat kürzlich bekannt gegeben, dass kanonische Tags nicht verarbeitet werden, wenn sie nur im gerenderten HTML und nicht im HTML-Quelldokument zu finden sind.
  • Wir haben dies getestet, indem wir mithilfe von GTM kanonische Tags in vier URLs eingefügt haben, und unsere Testergebnisse legen nahe, dass Google dennoch diese kanonischen Tags verwendet.
  • Es dauerte mehr als drei Wochen, bis einige der getesteten URLs zu den Zielen der JS-injizierten Canonical Tags kanonisiert waren.
  • Die Funktion "Abrufen und Rendern > Indexierung anfordern" in der Google Search Console scheint nicht dazu beizutragen, das Rendern von Seiten zu beschleunigen.
  • Der neue Index-Coverage-Bericht in der Google Search Console ignoriert JS-injizierte kanonische Tags in seinen Berichten und steht damit im Einklang mit den offiziellen Aussagen von Google.
  • Der Grund, warum Google eine Ankündigung gemacht hat, die scheinbar falsch ist, könnte ein internes Missverständnis oder ein Fehler sein.

Diskussion

Ich würde mich freuen, deine Meinung zu all dem zu hören! Was habe ich übersehen? Wo liege ich falsch? Leider sind unsere Blog-Kommentare derzeit deaktiviert, bis wir eine GDPR-konforme Lösung implementiert haben (das tut uns leid!). Lass uns reden auf Twitter oder wo immer du willst!

Eine Antwort

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert