Google wählt fremde Casino-Seite als Canonical: John Müller erklärt, was dahinter stecken kann

Wenn Google statt der eigentlich richtigen URL einer Website eine fremde URL als Canonical wählt, kann das mit einem technischen Problem zu tun haben - und muss nicht auf einem Hack basieren.

 

 Anzeige

Selbst wenn alle Canonical-Signale stimmen, kann Google unter Umständen für eine oder mehrere Seiten komplett andere Domains wählen. Dann kann es so laufen wie in diesem Fall: Ein Website-Betreiber auf Reddit berichtete, dass seine Seiten nach und nach aus dem Google-Index verschwänden, und als Canonical wähle Google eine völlig fremde Casino-Domain. Laut John Müller liegt die Ursache dafür  vermutlich auf der eigenen Website. Die Lösung sind bessere Fehlerbehandlung und automatisierte Tests.

Firmenprofile werden einer Casino-Seite zugeordnet

Die betroffene Website enthält Seiten über Unternehmen und Lieferanten. Vor einiger Zeit stellte der Betreiber fest, dass immer mehr dieser Seiten deindexiert werden. In der Search Console habe sich gezeigt, dass Google für die URLs eine Seite der Domain 747live.bet als kanonische Version ausgewählt habe, ein Angebot für Casino-Wetten. Inhaltlich gebe es zwischen den beiden Websites keinerlei Überschneidungen. Auch bei einer Analyse der Casino-Domain fand der Betreiber nach eigener Aussage keine Seite, die seinen Inhalten auch nur ähnelt.

Die Spur: eine generische JavaScript-Fehlermeldung

Ein anderer Nutzer hatte das gleiche Problem und lieferte einen Hinweis. Sucht man bei Google nach der fremden Canonical-URL, erscheine sie mit dem Titel „Application error: a client-side exception has occurred“. Solche Standardmeldungen zeigen JavaScript-Anwendungen wie Next.js an, wenn die Seite im Browser nicht korrekt geladen werden kann. Die Website des Nutzers hatte bei vorübergehenden Ausfällen genau diese Meldung ausgegeben.

Die Vermutung: Der Googlebot habe irgendwann statt der eigentlichen Inhalte nur diese Fehlerseite gecrawlt. Viele URLs auf verschiedenen Domains zeigen den gleichen Fehlertext. Google behandele sie deshalb als Duplikate und wähle eine davon als Canonical, in diesem Fall zufällig die Casino-Seite. Hacking war nicht im Spiel. Bei ihm löste sich das Problem nach einigen Wochen von selbst.

John Müller bestätigte, dass dies eine plausible Erklärung sei. Er riet dazu, solche Fehler besser abzufangen und mit dem Live-Test der URL-Prüfung in der Search Console zu kontrollieren, was die Seiten tatsächlich an den Googlebot ausliefern. Es dürfe nicht passieren, dass Google eine Fehlermeldung bekomme, während Nutzer den normalen Inhalt sehen. Das Problem werde sich mit der Zeit selbst beheben.

SEO-Beratung: Wir sind Ihre Experten

Wir bringen gemeinsam Ihre Website nach vorne. Profitieren Sie von jahrelanger SEO-Erfahrung.

Unsere Beratungsleistungen

Christian Kunz

SEO Experte

David Wulf

SEO Experte

Sven Häwel

Offpage-Experte

Müller: Das Ergebnis ist in allen Fällen gleich

Auf die Frage, ob Google solche domainübergreifenden Verwechslungen nicht grundsätzlich verhindern könne, antwortete Müller, dies spiele letztlich keine große Rolle, auch wenn es verwirrend wirke. Er nannte drei mögliche Ergebnisse, wenn Google eine Fehlerseite crawlt:

1. Die eigene Seite bleibt Canonical, wird aber mit der Fehlermeldung indexiert.
2. Google stuft die Seite als Soft-404 ein. Das wäre laut Müller eigentlich das richtige Verhalten.
3. Eine fremde Seite wird zum Canonical.

In jedem dieser Fälle erscheine die Seite nicht mehr mit ihren eigentlichen Inhalten in der Suche - zumindest nicht für normale Suchanfragen. Wer das Problem an der Wurzel packen wolle, müsse verhindern, dass Google überhaupt eine Fehlerseite zu sehen bekomme.´

Automatisierte Tests und Monitoring

Müller empfahl, Fehler zu erkennen, bevor eine Website live geht. Für seine eigenen kleineren Websites lasse er vor jedem Deployment eine große Zahl automatisierter Tests laufen. Trete ein neuer Fehler auf, lasse er von einem Coding-Agenten einen zusätzlichen Test dafür schreiben. Die Tests dauerten nur ein paar Minuten und gäben deutlich mehr Sicherheit.

Als Alternative oder Ergänzung nannte Müller ein Monitoring der wichtigsten Seiten, selbst gebaut oder über ein externes Tool. Die kritischen URLs sollten etwa stündlich abgerufen und auf Probleme geprüft werden. So ließen sich Fehler beheben, bevor Suchmaschinen sie dauerhaft übernehmen.

Unterschiedliche Ergebnisse in den Testtools

Der Betreiber der betroffenen Website meldete sich noch einmal: Im Live-Test der Search Console wurden alle geprüften Seiten korrekt ausgeliefert und gerendert. Im öffentlichen Test für Rich-Suchergebnisse erhielt er dagegen die Fehlerseite. Laut Müller nutzen beide Tools leicht unterschiedliche User-Agents. Er vermute eher einen sporadischen Aussetzer, der sich nicht zuverlässig reproduzieren lasse.

Für die Ursachensuche schlägt er zwei Schritte vor:

• In den Server-Logs die Antwortgröße einzelner betroffener URLs vergleichen. Auffällig kurze Antworten zeigen, wann und wo die Fehlerseite ausgeliefert wurde.
• Im Code der Website die Stelle finden, an der die Fehlermeldung erzeugt wird, und dafür sorgen, dass sie mit dem HTTP-Statuscode 503 ausgeliefert wird. Google behandele die Antwort dann nicht als normale HTML-Seite und nutze sie weder für die Kanonisierung noch für die Indexierung.

Einordnung

Der Fall zeigt ein Risiko, das JavaScript-lastige Websites betrifft. Eine Fehlerseite mit Statuscode 200 ist für Google eine ganz normale Seite mit Inhalt, und dieser Inhalt ist auf Tausenden anderer Websites identisch. Wichtig ist dabei: Tritt der Fehler erst im Browser auf, hat der Server längst den Status 200 gesendet. Ein 503 lässt sich nur setzen, wenn der Fehler serverseitig erkannt wird, zum Beispiel beim Server-Side-Rendering. Wer seine Inhalte serverseitig ausliefert, bei Fehlern korrekte Statuscodes sendet und die wichtigsten Seiten regelmäßig automatisiert prüft, vermeidet solche Verwechslungen weitgehend.