Technisches SEORatgeber

Canonical-Tag: doppelte Inhalte steuern

Der Canonical-Tag ist ein Link-Element im Kopf einer Seite, mit dem du angibst, welche von mehreren gleichen oder sehr ähnlichen Adressen die bevorzugte ist. Google wertet rel="canonical" als starkes Signal, behandelt die Angabe aber als Hinweis und keine feste Regel. Welche Adresse Google gewählt hat, zeigt das URL-Prüftool der Search Console.

Mehrere gleiche Keramiktassen in einer Reihe auf einem hellen Holzregal, eine Tasse steht etwas weiter vorn
Bild: KI-generiert

Viele Websites liefern denselben Inhalt unter mehreren Adressen aus: mit und ohne Parameter, über HTTP und HTTPS, als gefilterte und als ungefilterte Liste. Google wählt dann eine dieser Adressen aus und zeigt meist nur sie in den Suchergebnissen. Mit dem Canonical-Tag sagst du, welche Adresse du bevorzugst. Hier erfährst du, wie die Angabe funktioniert, wann eine Weiterleitung besser passt und wie du kontrollierst, ob Google deiner Wahl folgt.

Was der Canonical-Tag ist

Der Canonical-Tag ist ein Link-Element im <head> einer HTML-Seite, zum Beispiel <link rel="canonical" href="https://www.example.com/schuhe/">. Beschrieben ist die Link-Relation "canonical" in RFC 6596 aus dem April 2012, verfasst von Maile Ohye und Joachim Kupke. Das Dokument beschreibt sie informell als die vom Autor bevorzugte Version einer Ressource [3]. RFC 6596 hat den Status "Informational" und ist damit kein Internet-Standard im engeren Sinn [3].

Google spricht von Kanonisierung, wenn es aus mehreren gleichen Seiten die repräsentative Adresse auswählt. Die kanonische URL ist nach Googles Definition die Adresse, die Google unter mehreren duplizierten Seiten als die repräsentativste ausgewählt hat [1]. Den Vorgang nennt Google auch Deduplizierung [1]. Deine Angabe und Googles Auswahl können sich unterscheiden, denn laut Google ist eine kanonische Präferenz ein Hinweis und keine Regel [1].

Wie doppelte Inhalte entstehen

Google nennt mehrere typische Ursachen für Duplikate [1]:

  • Regionsvarianten, etwa getrennte Seiten für die USA und Großbritannien mit fast gleichem Inhalt in derselben Sprache,
  • Gerätevarianten wie eine eigene mobile Version neben der Desktopversion,
  • Protokollvarianten, also dieselbe Seite über HTTP und HTTPS,
  • Websitefunktionen wie Sortier- und Filterfunktionen einer Kategorieseite,
  • versehentliche Varianten, zum Beispiel eine Demoversion, die Crawler erreichen können.

Eine Strafe droht dafür nicht. Google schreibt, dass eine gewisse Menge an Duplicate Content auf einer Website normal ist und kein Verstoß gegen die Spamrichtlinien [1]. Ärgerlich wird es aus anderen Gründen: Nutzer finden womöglich eine Variante, die du nicht zeigen willst, und die Leistung einer Seite lässt sich schwerer beobachten, wenn sie sich auf mehrere Adressen verteilt [1].

Die Methoden im Vergleich

Den Canonical-Tag gibt es in mehreren Formen, und er ist nicht das einzige Mittel. Google stuft die Methoden unterschiedlich stark ein [2]:

MethodeSignal laut GoogleEinsatz
Weiterleitung (dauerhaft, 301)starkes Signalwenn die doppelte Adresse wegfallen soll
rel="canonical" im HTMLstarkes Signalwenn beide Adressen erreichbar bleiben
rel="canonical" im HTTP-Headerwie das Link-Elementfür Dateien ohne HTML-Kopf, etwa PDF; nur für die Websuche
Eintrag in der Sitemapschwaches Signaleinfach zu pflegen, vor allem auf großen Websites

Die Methoden lassen sich kombinieren [2]. Eine Weiterleitung passt, wenn Besucher die doppelte Adresse gar nicht mehr sehen sollen, zum Beispiel nach einem Umzug auf HTTPS. Für Varianten, die für Nutzer erreichbar bleiben sollen, etwa eine Farbvariante mit Parameter in der Adresse, ist der Canonical-Tag das passende Mittel. Wie du dauerhafte Weiterleitungen sauber planst, steht unter Weiterleitungen und SEO: 301, 302 und 410. Bei HTTP und HTTPS bevorzugt Google ohnehin die HTTPS-Version, solange es dort keine Probleme gibt, etwa ein ungültiges Zertifikat [2]. Den Umstieg erklärt domain-root.de unter Von HTTP auf HTTPS umstellen.

rel="canonical" richtig setzen

Für das Link-Element nennt Google diese Regeln [2]:

  • Jede kanonische Seite verweist auf sich selbst.
  • Die Adresse ist absolut, also mit Protokoll und Domain, statt eines relativen Pfads.
  • Interne Links zeigen auf die kanonische Adresse und nicht auf eine Variante.
  • Jede Seite nennt nur eine kanonische Adresse, egal mit welcher Methode.
  • Bei Seiten mit JavaScript steht die kanonische Adresse möglichst schon im HTML-Quellcode und wird nicht erst per Skript geändert.
  • Das Element steht im <head>; für PDF und andere Dateien ohne HTML-Kopf dient der HTTP-Header.

RFC 6596 ergänzt Fehler, die Programme dazu bringen können, die Angabe zu ignorieren [3]. Das Ziel soll keinen Fehlercode liefern, etwa einen 4xx-Status. Es soll nicht selbst auf eine andere Adresse kanonisieren, denn verkettete Canonicals nennt das Dokument ausdrücklich als fehlerhaft. Das Ziel soll auch nicht der Ausgangspunkt einer dauerhaften Weiterleitung sein. Und je Ressource gehört nur eine canonical-Relation in den Code [3]. Bei fehlerhaften Angaben dürfen Anwendungen laut RFC eigene Heuristiken anwenden [3].

Häufige Varianten und was zu ihnen passt

In der Praxis tauchen immer wieder dieselben Arten von Duplikaten auf. Die folgende Übersicht ordnet ihnen die Lösung zu, die Google in seiner Dokumentation nennt:

VarianteLösung nach Google
dieselbe Seite über HTTP und HTTPSWeiterleitung, Canonical-Tag oder HSTS; Google bevorzugt ohnehin HTTPS [2]
Produktvariante mit Parameter, etwa ?color=greeneigene Adresse, Canonical auf die Adresse ohne Parameter [5]
Tracking-Codes und Sitzungs-IDs in Adressennicht in interne Links aufnehmen, Sitzungs-IDs in Adressen vermeiden [5]
Groß- und Kleinschreibung, die der Server gleich behandeltdurchgängig eine Schreibweise verwenden [5]
Sortierungen einer Ergebnisliste, etwa nach Preisnicht indexieren lassen, per noindex oder Sperre des Adressmusters in der robots.txt [4]
PDF mit demselben Inhalt wie eine HTML-Seiterel="canonical" im HTTP-Header [2]

Bei den Sortierungen weichen zwei Google-Seiten im Ton voneinander ab: Die Seite zur Kanonisierung rät für Duplikate von noindex ab und empfiehlt rel="canonical" [2], die Seite zum Seitenumbruch nennt für Sortiervarianten derselben Liste noindex oder robots.txt [4]. Beides passt zusammen, wenn man den Zweck trennt: Der Canonical-Tag bündelt Duplikate auf eine Adresse, noindex und robots.txt halten Listen fern, die gar nicht in der Suche erscheinen sollen.

Viele Redaktionssysteme setzen den Canonical-Tag selbst. WordPress gibt seit Version 2.9 für einzelne Beiträge und Seiten automatisch ein rel="canonical" aus, auf Archiven und der Seite mit den neuesten Beiträgen dagegen nicht [8]. Was Erweiterungen dort ergänzen, beschreibt SEO für WordPress.

Was nicht zur Kanonisierung taugt

Google rät bei der Kanonisierung von diesen Mitteln ab [2]:

  • robots.txt: Eine gesperrte Adresse kann Google trotzdem indexieren, nur ohne ihren Inhalt zu kennen. Mehr dazu unter robots.txt richtig schreiben.
  • Das Tool zum Entfernen von URLs: Es blendet alle Versionen einer Adresse aus, also auch die gewünschte.
  • noindex: Die Seite verschwindet ganz aus der Suche. Für Duplikate ist rel="canonical" laut Google vorzuziehen.
  • Fragmente nach dem Zeichen #: Google unterstützt sie in der Regel nicht als kanonische Adresse.

Sonderfälle: Seitenfolgen, Varianten, Sprachen

Bei Seitenfolgen, etwa Seite 2 und 3 einer Kategorie, soll die erste Seite nicht als kanonische Seite dienen. Google empfiehlt, jeder Seite eine eigene kanonische Adresse zu geben [4]. Dasselbe steht in RFC 6596: Folgeseiten eines mehrteiligen Artikels sollen nicht auf Seite 1 kanonisieren, weil sonst Inhalte verloren gehen können [3]. Die Auszeichnungen rel="next" und rel="prev" verwendet Google laut eigener Aussage nicht mehr [4].

Produktvarianten wie Farben brauchen in Shops eine eigene Adresse. Stehen sie als Parameter in der Adresse, etwa ?color=green, soll die Variante laut Google auf die Adresse ohne Parameter als kanonische URL verweisen [5]. Für Filterseiten nennt Google den Verweis auf die ungefilterte Version als ergänzende Methode, mit der das Crawling der Varianten mit der Zeit abnehmen kann, schätzt ihn aber langfristig als weniger wirksam ein als das Sperren der Filteradressen per robots.txt [6]. Mehr dazu im Ratgeber SEO für Onlineshops.

Für Sprach- und Ländervarianten ist der Canonical-Tag das falsche Werkzeug. Ein rel="canonical" mit hreflang-, lang-, media- oder type-Attribut ignoriert Google bei der Kanonisierung; für alternative Sprachversionen sind rel="alternate"-Links mit hreflang vorgesehen [2]. Seiten in einem hreflang-Verbund bevorzugt Google bei der Auswahl [2]. Wie du solche Verweise aufbaust, erklärt hreflang für mehrsprachige Websites.

Googles Auswahl in der Search Console prüfen

Ob Google deiner Angabe folgt, zeigt das URL-Prüftool der Search Console. Es nennt zwei Werte: die vom Nutzer angegebene kanonische URL, also deine Angabe per Link-Element, HTTP-Header oder Sitemap, und die von Google ausgewählte kanonische URL [7]. Weichen beide voneinander ab, kann Google eine andere Seite für besser geeignet halten [7]. Der Wert bezieht sich auf die indexierte Version; der Live-Test prüft die Kanonisierung nicht [7]. Bei einer Seite ohne Duplikate ist der Eintrag "Keine" für deine Angabe laut Google unproblematisch [7].

Hat Google eine andere Adresse gewählt, lohnt ein Blick auf die Signale, die Google für die Auswahl nennt: HTTP oder HTTPS, Weiterleitungen, Einträge in der Sitemap und rel="canonical" [1]. Zeigen interne Links und Sitemap auf eine andere Variante als dein Canonical-Tag, widersprechen sich die Hinweise. Weitere Meldungen zum Indexstatus erklärt Seite wird nicht indexiert: Ursachen finden, die Sitemap behandelt XML-Sitemap erstellen und einreichen.

  1. Organisation Was ist Kanonisierung?. Google Search Central. Stand 09.09.2026. abgerufen am 29.10.2026
  2. Organisation Kanonische URL mit rel="canonical" und anderen Methoden angeben. Google Search Central. Stand 15.07.2026. abgerufen am 29.10.2026
  3. Gesetz RFC 6596: The Canonical Link Relation (M. Ohye, J. Kupke). IETF / RFC Editor. Stand 04.2012. abgerufen am 29.10.2026
  4. Organisation Paginierung, inkrementeller Seitenaufbau und ihre Auswirkungen auf die Google Suche. Google Search Central. Stand 18.12.2025. abgerufen am 29.10.2026
  5. Organisation URLs für E-Commerce-Websites gut strukturieren. Google Search Central. Stand 18.12.2025. abgerufen am 29.10.2026
  6. Organisation Crawling von Facettensuche-URLs verwalten. Google Search Central. Stand 06.03.2026. abgerufen am 29.10.2026
  7. Organisation URL-Prüftool. Search Console-Hilfe, Google. Stand ohne Datum. abgerufen am 29.10.2026
  8. Organisation rel_canonical(): Function. WordPress Developer Resources. Stand ohne Datum. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.

Weitere Artikel