Entscheiden, ob die URLs tatsächlich Duplikate sind
Eine Canonical-URL ist die repräsentative Adresse für doppelte oder nahezu doppelte Seiten. Die link relation rel=canonical ist angebracht, wenn das Ziel denselben Inhalt oder eine Obermenge des Inhalts der verweisenden Seite enthält. Sie ist kein Weg, unterschiedliche Produkte, nützliche Filter, Artikel oder Locale zu verbergen.
Fragen Sie, ob ein Besucher wichtigen Inhalt, Auswahlmöglichkeiten oder Aufgabenabschluss verlieren würde, wenn diese URL durch die Kandidaten-URL repräsentiert würde. Wenn ja, behalten Sie sie getrennt und verbessern Sie Inhalt oder Lokalisierung. Wenn nein, wählen Sie eine stabile URL und dokumentieren Sie Regeln für Protokoll, Host, Pfad, abschließenden Schrägstrich und Parameter.
Fügen Sie jeder bevorzugten indexierbaren HTML-Seite ein selbstreferenziertes canonical hinzu, auch wenn heute kein Duplikat offensichtlich ist.
Zeigen Sie eine notwendige Kopie, z. B. eine Route mit Analytics-Parametern, nur dann auf die bevorzugte URL, wenn beide Seiten denselben Hauptinhalt zurückgeben.
Weiterleitung verwenden, wenn die alte URL verschwinden soll
Verwenden Sie eine permanente serverseitige Weiterleitung, wenn ein alter Pfad, ein stillgelegter Host oder eine HTTP-Version nicht länger Ziel für Besucher oder Crawler sein soll. Google behandelt Weiterleitungen als starkes Kanonisierungssignal und empfiehlt sie beim Deprecation eines Duplikats.
Verwenden Sie rel=canonical, wenn beide URLs Inhalte ausliefern müssen, aber eine die Gruppe in der Suche repräsentieren soll. Das Tag ändert nicht die Adresse des Besuchers und entfernt nicht die andere Route. Das Ziel sollte erreichbar sein und nicht weiterleiten oder selbst auf eine andere URL canonicalisieren.
Leiten Sie eine veraltete HTTP-URL direkt zur finalen HTTPS-URL und verwenden Sie diese HTTPS-URL überall sonst.
robots.txt, URL-Entfernungen und noindex drücken keine bevorzugte Duplikat-Wahl aus. Noindex blockiert stattdessen eine Seite aus der Suche.
Eine klare Annotation veröffentlichen
Für HTML platzieren Sie eine absolute rel=canonical-Angabe im Head. Prüfen Sie die ausgelieferte Quelle, nicht nur die CMS-Einstellung: Ein Theme, Plugin, Edge-Rule oder JavaScript kann den Wert ersetzen. Google empfiehlt, sie im HTML-Quelltext bereitzustellen und sicherzustellen, dass JavaScript sie nicht verändert.
Für ein Nicht-HTML-Dokument wie ein PDF verwenden Sie gegebenenfalls einen Canonical HTTP Link-Response-Header. Vermeiden Sie widersprüchliche HTML- und Header-Werte. Das Ziel muss zugänglich sein, darf keine 4xx-Antwort liefern und darf nicht weiterleitend oder verkettet sein.
Veröffentlichen Sie pro Ressource genau ein Canonical-Ziel; mehrere Ziele machen die Präferenz unklar.
Rufen Sie nach Template-, CDN-, CMS- oder Routing-Änderungen Beispielseiten und Header ab und bestätigen Sie das finale Ziel.
Unterstützende Signale abstimmen
Verlinken Sie intern zur bevorzugten URL in Navigation, Breadcrumbs, Body-Links und generierten Feeds. Listen Sie in der Sitemap nur URLs, die Sie in der Suche gezeigt haben wollen. Die Aufnahme in die Sitemap ist ein schwächeres Signal, verstärkt aber die Wahl, wenn sie mit Weiterleitungen und Annotationen übereinstimmt.
Generieren Sie vollständig qualifizierte Sitemap-URLs mit demselben Host, Protokoll und Slash-Stil wie das Canonical. Entfernen Sie umgeleitete und parameterisierte Duplikate. Testen Sie automatisch erzeugte Sitemaps nach Änderungen an Permalinks, Domain, Sprache oder E‑Commerce.
Ersetzen Sie Links zu getrackten, veralteten oder alternativen Host-URLs durch das ausgewählte Canonical.
Halten Sie HTTPS-Weiterleitungen, Canonical-Ziele, Sitemaps und Links konsistent; Zertifikat- und HTTPS-zu-HTTP-Fehler senden widersprüchliche Signale.
Parameter, Paginierung und Sprachen nach Zweck behandeln
Parameter sind nicht automatisch Duplikate. Analytics-Parameter lassen den Inhalt unverändert, während Filter und Sortierungen das Ergebnisset ändern können. Testen Sie repräsentative Kombinationen. Bewahren Sie jeden Parameter, der für Warenkorb, Login, Consent oder Konfiguration erforderlich ist; ein Canonical darf keinen Besucherfluss unterbrechen.
Kanonisieren Sie nicht jede paginierte Seite auf Seite eins: spätere Seiten enthalten in der Regel Inhalte, die Seite eins nicht hat. Bei Sprach- oder Länder-URLs benennen Sie die Seite mit derselben Sprache als Canonical, wenn sie existiert, und verwenden hreflang für Alternativen. Canonicalisierung ersetzt nicht das Design zur Lokalisierung.
Dokumentieren Sie, welche Filter als eigene Landingpages gelten und welche nur Duplikate oder Umorderungen sind, damit Produkt- und Engineering-Änderungen abgestimmt bleiben.
Verwenden Sie eine View-all-Seite nur, wenn sie eine brauchbare Inhalts-Obermenge ist; testen Sie ihre Ladezeit und Navigation vor der Auswahl.
Konflikte mit indexierten und live vorhandenen Belegen debuggen
Prüfen Sie in der Search Console die betroffene URL und vergleichen Sie das von Google ausgewählte indexierte Canonical mit dem vom Nutzer deklarierten Wert. Inspizieren Sie auch das Kandidat-Ziel. Der Indexbericht spiegelt wider, was Google zuletzt verarbeitet hat; ein Live-Test ist nützlich für den aktuellen Fetch, das gerenderte Seitenbild, Header und Ressourcen, kann aber die finale Kanonisierung nicht vorhersagen.
Wenn Werte abweichen, überlegen Sie, ob Google die bessere Repräsentation gewählt hat. Andernfalls verfolgen Sie Weiterleitungen, HTML- und HTTP-Header-Angaben, gerendertes Output, Links, Sitemap-Einträge, hreflang und Inhaltsähnlichkeit. Beheben Sie die Diskrepanz, dokumentieren Sie die Änderung und geben Sie Zeit für die Neubewertung.
Prüfen Sie Templates, Header, Host-Routing und Sicherheitsänderungen. Ein unerklärtes Cross-Domain-Canonical oder eine unerklärte Weiterleitung rechtfertigt eine Sicherheitsuntersuchung.
Vergleichen Sie ausgelieferte Quelle und Header mit den CMS-Einstellungen; ein Plugin oder Plattform-Regel kann einen anderen Wert ausgeben.
Canonical-Checks in SIU-Release-Hardening aufnehmen
Vor Domain-, HTTPS-, CDN-, CMS-, Template- oder Katalog-Releases holen Sie Stichproben der Startseite, Inhalts- und Produktseiten, einer Parameter-Route, einer Locale, einer Legacy-URL und veröffentlichter Dokumente ein. Dokumentieren Sie Status, finale URL, Canonical-Ziel, Sitemap-Aufnahme und ein Beispiel für einen internen Link.
Halten Sie Fixes reversibel: Erfassen Sie die aktuelle Zuordnung, ändern Sie eine Regeln-Gruppe, verifizieren Sie die betroffenen Routen und behalten Sie einen Rollback‑Plan. Das unterstützt proaktive Uptime-Optimierung, indem stabile öffentliche Pfade während Änderungen geschützt werden; es liefert jedoch keine Ausfallüberwachung und garantiert kein Indexieren.
Weisen Sie Canonical-Regeln zwischen Marketing und Engineering zu und protokollieren Sie hinter jeder Änderung das Template-, Redirect-, Sitemap- oder Plattform-Update.
Fügen Sie dem Release-Ticket ein kleines Vorher‑/Nachher-URL- und Header‑Beispiel bei, um die Fehlerbehebung zu beschleunigen.