Nach einem Relaunch ist die bevorzugte URL korrigiert, die Sitemap neu eingereicht und der Redirect getestet. Trotzdem zeigt Google noch die alte Adresse oder behandelt zwei Seiten weiterhin als Duplikate. Genau für diese Situation hat Google seine Canonical-Dokumentation präzisiert: Selbst nach behobenen Inhaltsproblemen können Seiten noch bis zu zwei Wochen in einem Duplicate-Cluster bleiben. Deutlich unterschiedliche Inhalte werden laut Google tendenziell schneller neu getrennt.

Für österreichische Unternehmen ist diese Klarstellung vor allem ein Schutz vor Aktionismus. Wer nach zwei Tagen erneut Canonicals, Weiterleitungen und Seitentexte ändert, erzeugt zusätzliche Signale, bevor die erste Korrektur überhaupt neu bewertet wurde. Die Zwei-Wochen-Angabe ist allerdings keine garantierte Frist. Sie ist ein realistischer Beobachtungsrahmen, in dem Technik, Inhalt und Search-Console-Befunde geordnet kontrolliert werden sollten.

Der operative Anlass betrifft nicht nur große Shops. Duplicate-Cluster entstehen auch bei WordPress-Relaunches, neuen Produktfiltern, Druckansichten, Kampagnenparametern, Sprach- und Regionsversionen oder einem Wechsel von HTTP auf HTTPS. Entscheidend ist deshalb nicht eine einzelne Canonical-Zeile, sondern die Übereinstimmung aller Signale.

Was Google bei Canonical-Problemen klargestellt hat

Google fasst Canonicalisierung als Auswahl einer repräsentativen URL für gleiche oder sehr ähnliche Inhalte zusammen. Mehrere URLs werden zu einem Cluster gebündelt; anschließend wählt Google jene Version, die aus Sicht seiner Systeme am vollständigsten und nützlichsten erscheint. Website-Betreiber können eine Präferenz signalisieren, aber die endgültige Auswahl nicht erzwingen.

Die aktualisierte Google-Anleitung zur Behebung von Canonical-Problemen nennt drei wichtige Punkte:

  • Eine korrigierte Seite kann noch bis zu zwei Wochen im bisherigen Duplicate-Cluster bleiben.
  • Klare, wesentliche Inhaltsunterschiede helfen Google, Seiten schneller voneinander zu trennen.
  • Die erneute Indexierung kann für wichtige URLs angefordert werden, die Funktion ist jedoch kontingentiert und sollte gezielt eingesetzt werden.

Das ist keine Aufforderung, Inhalte künstlich umzuschreiben. Wenn zwei URLs tatsächlich dieselbe Seite darstellen, sollten ihre Signale auf eine gemeinsame Hauptversion zeigen. Unterschiedliche regionale Leistungen, Produkte oder Standorte müssen dagegen auch inhaltlich so eigenständig sein, dass der Unterschied für Menschen erkennbar ist.

Das Canonical ist ein starkes Signal, kein Schalter

Ein häufiger Denkfehler lautet: Sobald rel="canonical" richtig gesetzt ist, muss Google die angegebene URL übernehmen. Google beschreibt Canonical-Angaben und permanente Redirects als starke Signale. Die Aufnahme einer URL in die Sitemap ist ein schwächeres Signal. Zusätzlich berücksichtigt das System unter anderem interne Links, HTTPS, Weiterleitungen, hreflang-Cluster und den tatsächlichen Seiteninhalt.

Widersprüche entstehen beispielsweise, wenn:

  • die alte URL per Canonical auf die neue zeigt, interne Links aber weiter zur alten führen,
  • die Sitemap die neue URL enthält, ein Redirect jedoch in einer Kette auf einer dritten Adresse endet,
  • die neue Seite sich selbst als Canonical nennt, das CMS im gerenderten HTML aber ein zweites Element ergänzt,
  • eine österreichische de-at-Seite im hreflang-Cluster fehlt,
  • eine HTTPS-Seite auf HTTP weiterleitet oder ein ungültiges Zertifikat verwendet,
  • zwei Standortseiten bis auf Ortsnamen und Footer denselben Hauptinhalt haben.

Der technische Befund braucht deshalb eine Signalmatrix. Wer nur den Quelltext einer URL ansieht, übersieht häufig Redirects, Sitemap-Einträge, interne Verweise und vom JavaScript veränderte Angaben.

Typische Canonical-Fälle nach einem Relaunch

Alte und neue URL-Struktur

Ein Unternehmen ersetzt etwa /leistungen/webdesign-wien/ durch /webdesign/wien/. Die alte URL sollte bei einer dauerhaften Ablöse serverseitig auf die neue führen. Interne Navigation, XML-Sitemap, Canonical und wichtige externe Profile müssen ebenfalls die neue Adresse verwenden. Bleibt die alte Seite mit Status 200 erreichbar und enthält denselben Inhalt, erhält Google zwei plausible Kandidaten.

Filter, Sortierung und Trackingparameter

Webshops und Verzeichnisse erzeugen Varianten wie Farbe, Sortierung, Kampagnenquelle oder Sitzungsparameter. Nicht jede Variante braucht einen eigenen Suchtreffer. Der Audit muss unterscheiden: Ist die URL nur eine technische Ansicht desselben Bestands oder erfüllt sie eine eigene Suchintention? Ein pauschales Canonical auf die Kategorieseite kann sinnvoll sein, kann aber auch eine wertvolle gefilterte Landingpage entwerten.

Österreichische und deutsche Sprachversionen

Eine de-at– und eine de-de-Seite sind nicht automatisch eigenständig, wenn sich nur Navigation, Währung oder Footer unterscheiden. Google weist darauf hin, dass Sprachversionen bei gleichem Hauptinhalt als Duplikate gelten können. Wer österreichische Leistungen separat sichtbar machen will, braucht korrekte hreflang-Verweise und einen echten inhaltlichen Bezug zu Österreich, etwa bei Angebot, Verfügbarkeit, Rechtsrahmen oder Kontaktweg.

PDF und HTML-Version

Whitepaper, Preislisten oder Anleitungen stehen manchmal als PDF und als HTML-Seite bereit. Für Nicht-HTML-Dokumente kann ein Canonical über den HTTP-Header angegeben werden. Trotzdem sollte vorab entschieden werden, welche Version für Suche, Aktualisierung und Conversion die Hauptrolle übernimmt. Zwei unkoordinierte Versionen erschweren sonst sowohl die Messung als auch die Pflege.

Die ersten 30 Minuten: Beweise sichern, nichts überstürzen

Bevor Sie Änderungen vornehmen, dokumentieren Sie den aktuellen Zustand. Das verhindert, dass eine nachträgliche Analyse auf Vermutungen beruht. Für eine kleine Website reicht ein Tabellenblatt mit zehn bis zwanzig betroffenen URLs.

  1. Google-Auswahl notieren: Prüfen Sie in der URL-Prüfung die vom Nutzer angegebene und die von Google gewählte Canonical-URL.
  2. Status und Redirects erfassen: Notieren Sie HTTP-Status, jede Weiterleitungsstufe und die endgültige Zieladresse.
  3. Gerendertes HTML prüfen: Kontrollieren Sie, welches Canonical nach Ausführung von Plugins und JavaScript tatsächlich vorhanden ist.
  4. Sitemap und interne Links vergleichen: Suchen Sie nach alten URLs in Navigation, Breadcrumbs, Fließtext, Bildlinks und XML-Sitemaps.
  5. Inhaltliche Ähnlichkeit bewerten: Markieren Sie, ob die Seiten gleich sein sollen oder eine eigene Suchintention erfüllen.
  6. Zeitpunkt festhalten: Dokumentieren Sie Deployment, Crawl-Hinweise und den Beginn der Beobachtungsphase.

Eine technische und inhaltliche Ist-Analyse ist auch der Ausgangspunkt der Suchmaschinenoptimierung von AdSimple. Beim Canonical-Audit ist diese Kombination entscheidend: Eine korrekte Anweisung kann keine fehlende inhaltliche Abgrenzung ersetzen, und ein guter Text kann widersprüchliche URL-Signale nicht ausgleichen.

Der Zwei-Wochen-Kontrollplan

Tag 0: Signale konsistent ausrollen

Legen Sie pro Cluster eine gewünschte Haupt-URL fest. Richten Sie bei dauerhaft entfernten Varianten passende serverseitige Redirects ein. Verwenden Sie auf indexierbaren Hauptseiten ein selbstreferenzielles Canonical. Aktualisieren Sie interne Links und Sitemap. Prüfen Sie, dass weder robots.txt noch das URL-Entfernungstool als Canonical-Ersatz eingesetzt werden. Google warnt ausdrücklich vor beiden Abkürzungen.

Vermeiden Sie mehrere konkurrierende Methoden. Die Sitemap darf nicht URL A bevorzugen, während das Canonical URL B nennt und die Weiterleitung zu URL C führt. Ein Signalprotokoll mit „Quelle, aktueller Wert, Zielwert, geprüft am“ macht solche Konflikte sichtbar.

Tag 1 bis 3: wichtigste URLs erneut anstoßen

Nutzen Sie die Indexierungsanfrage nur für zentrale Seiten, etwa die Startseite, wichtige Leistungsseiten oder umsatzstarke Produkte. Ein Massenklicken ist weder skalierbar noch von Google vorgesehen. Kontrollieren Sie außerdem Serverlogs oder Crawl-Statistiken, wenn diese verfügbar sind. Sie zeigen, ob Google die neue Zielstruktur überhaupt abruft.

In dieser Phase sollten Sie keine kosmetischen Änderungen am Canonical vornehmen. Korrigieren Sie nur eindeutige Fehler wie falsche Domains, Schleifen, mehrere Elemente oder Redirect-Ziele, die nicht erreichbar sind.

Tag 4 bis 7: Cluster statt Einzel-URL beurteilen

Prüfen Sie alle Varianten eines Problems gemeinsam. Wenn fünf Filter-URLs dieselbe Hauptseite meinen, ist eine einzelne grüne URL-Prüfung noch kein Abschluss. Vergleichen Sie Canonical, Status, interne Links und Sitemap für das gesamte Set. Achten Sie auf neue Varianten, die das CMS nach dem Relaunch erzeugt.

Der Beitrag „Google Spam Update: erst messen, dann umbauen“ beschreibt denselben Grundsatz für Ranking-Schwankungen: Erst Ursache und Umfang abgrenzen, dann gezielt ändern. Beim Canonical gilt das besonders, weil jede zusätzliche URL-Regel den Cluster neu beeinflussen kann.

Tag 8 bis 14: Ergebnis oder Eskalation

Bis zum Ende des Beobachtungsfensters sollte sich ein belastbares Muster zeigen. Drei Ergebnisse sind möglich:

  • Google übernimmt die gewünschte URL: Signale stabil lassen und das Monitoring in den Regelbetrieb überführen.
  • Google wählt weiterhin eine andere interne URL: Prüfen, ob diese für Nutzer tatsächlich vollständiger ist oder stärkere interne Signale erhält.
  • Google wählt eine externe oder unerwartete Domain: Serverkonfiguration, Hacking, Kopien und Cross-Domain-Canonicals priorisiert untersuchen.

Bleibt der Befund nach zwei Wochen unverändert, ist nicht automatisch mehr Wartezeit die richtige Antwort. Dann braucht es einen erneuten Cluster-Audit: Welche Signale widersprechen noch? Sind die Inhalte wirklich verschieden? Erzeugt das CMS nach jeder Veröffentlichung neue Parameter- oder Archivseiten?

Was Sie während der Wartezeit nicht tun sollten

Nicht täglich das Canonical wechseln. Eine wechselnde Präferenz macht die Bewertung unklarer und zerstört den Vergleich zum Ausgangszustand.

Nicht alle Duplikate per robots.txt sperren. Google kann eine gesperrte URL weiterhin ohne ihren Inhalt indexieren. Zudem kann der Crawler die Canonical-Angabe auf der gesperrten Seite nicht zuverlässig auswerten.

Nicht das Entfernungstool als Bereinigung verwenden. Es dient nicht zur Canonicalisierung und kann alle Varianten aus der Suche verbergen.

Nicht mit belanglosen Textvarianten arbeiten. Ein ausgetauschtes Synonym oder ein anderer Ortsname macht zwei Seiten nicht automatisch eigenständig. Der Hauptinhalt muss eine eigene Nutzerfrage beantworten.

Nicht nur Rankings beobachten. Kontrollieren Sie auch indexierte URL, Impressionen, interne Verlinkung, Crawl-Verhalten und Weiterleitungen. Ein Rankingverlust kann zeitgleich auftreten, ohne vom Canonical verursacht zu sein.

Eine kompakte Freigabematrix für Relaunch-Teams

Vor der Abnahme sollte jede wichtige URL mindestens diese Fragen beantworten:

  • Welche URL soll für Nutzer und Suche die Hauptversion sein?
  • Ist sie mit Status 200 erreichbar und selbstreferenziell kanonisch?
  • Führen alte, dauerhaft ersetzte URLs direkt zu ihr?
  • Verweisen Sitemap, Navigation, Breadcrumbs und Fließtext konsistent auf sie?
  • Ist die Seite im passenden hreflang-Cluster enthalten?
  • Unterscheiden sich Seiten mit eigener Suchintention auch im Hauptinhalt?
  • Wurden Test-, Staging-, HTTP- und Parameter-Varianten berücksichtigt?
  • Sind Deployment-Datum und nächster Kontrolltermin dokumentiert?

Bei größeren Relaunches sollte diese Matrix nicht erst nach einem Sichtbarkeitsverlust entstehen. Die SEO-Analyse und OnPage-Optimierung von AdSimple kann URL-Struktur, interne Links, Weiterleitungen und inhaltliche Signale gemeinsam bewerten. Das Ziel ist kein blindes Warten, sondern ein kontrollierter Zeitraum mit klaren Eskalationskriterien.

Verantwortung zwischen Redaktion, Entwicklung und SEO klären

Canonical-Probleme bleiben oft liegen, weil jede beteiligte Rolle nur einen Ausschnitt sieht. Die Entwicklung bestätigt den Redirect, die Redaktion prüft den sichtbaren Inhalt und das SEO-Team beobachtet die Google-Auswahl. Für die Freigabe muss eine Person den gesamten Cluster zusammenführen.

Ein praktikables Übergabeprotokoll nennt pro URL-Set die gewünschte Hauptversion, den Grund der Zusammenführung, die umgesetzten Signale, offene Ausnahmen und den nächsten Kontrolltermin. Die Entwicklung bestätigt Statuscodes und gerendertes HTML. Die Redaktion entscheidet, ob Varianten dieselbe oder unterschiedliche Nutzerfragen beantworten. SEO vergleicht Sitemap, interne Links, hreflang und Search-Console-Befunde.

Diese Aufteilung ist auch für kleine Unternehmen sinnvoll, selbst wenn Agentur und Inhaberin jeweils mehrere Rollen übernehmen. Sie verhindert vor allem zwei teure Missverständnisse: Eine inhaltlich eigenständige Seite wird nicht versehentlich auf eine allgemeine Seite kanonisiert, und ein technisches Duplikat erhält nicht nur deshalb einen neuen Text, weil die Weiterleitung noch fehlt. Nach der Abnahme sollte das Protokoll beim Relaunch-Ticket oder Website-Handbuch bleiben. Beim nächsten Plugin-Update, Domainwechsel oder Sprachrollout ist damit nachvollziehbar, welche URL-Entscheidung bewusst getroffen wurde.

Fazit: Zwei Wochen Beobachtung brauchen einen Plan

Googles neue Zeitangabe macht Canonical-Probleme nicht einfacher, aber besser planbar. Ein Fix kann korrekt sein, obwohl die Search Console noch einige Tage die alte Auswahl zeigt. Gleichzeitig darf „Google braucht Zeit“ nicht zur Ausrede für widersprüchliche Redirects, Sitemaps oder Inhalte werden.

Sichern Sie zuerst den Befund, rollen Sie konsistente Signale aus und kontrollieren Sie den gesamten Duplicate-Cluster in festen Intervallen. Wenn nach bis zu zwei Wochen weiterhin die falsche URL gewählt wird, beginnt die Ursachenanalyse erneut. So wird aus ungeduldigem Nachbessern ein nachvollziehbarer Relaunch-Prozess.

Quellen