Canonical Tag
Das Canonical Tag zeigt Google die bevorzugte URL bei doppelten Inhalten. Syntax, Anwendungsfälle, typische Fehler und das Zusammenspiel mit Redirects.
Das Canonical Tag ist ein HTML-Element mit dem Attribut rel="canonical", das Suchmaschinen die bevorzugte URL-Version einer Seite mitteilt. Google, Yahoo und Microsoft führten das Tag 2009 gemeinsam ein, um das Problem doppelter Inhalte auf technischer Ebene zu lösen. Bei korrekter Implementierung konsolidiert das Tag alle Ranking-Signale auf eine einzige kanonische URL und verhindert, dass Suchmaschinen mehrere Versionen derselben Seite gegeneinander ausspielen.
Was ist ein Canonical Tag?
Ein Canonical Tag ist ein <link>-Element im <head>-Bereich einer HTML-Seite. Es benennt die URL, die Google als Originalversion behandeln soll. Die Syntax sieht so aus:
<link rel="canonical" href="https://www.example.com/seite/" />
Existieren mehrere URLs mit identischem oder sehr ähnlichem Inhalt, bündelt Google die Ranking-Signale aller Varianten auf die kanonische URL. Eingehende Verlinkungen, Trust-Signale und thematische Relevanz fließen in die bevorzugte Version ein, statt sich auf mehrere URLs zu verteilen.
Drei technische Regeln gelten für jede Implementierung. Die href-Angabe muss eine absolute URL mit Protokoll und Domain enthalten. Pro Seite darf genau ein Canonical Tag existieren. Das Tag muss innerhalb des <head>-Elements stehen, da Google es außerhalb des <head> nicht erkennt.
Wann wird ein Canonical Tag eingesetzt?
Sechs Szenarien erfordern eine Canonical-Auszeichnung:
- URL-Parameter: Filter, Sortierung, Session-IDs und UTM-Tracking-Parameter erzeugen technisch eigenständige URLs mit identischem Seiteninhalt. Ein Online-Shop mit 20 Filteroptionen und 3 Sortierungen generiert aus einer einzigen Produktkategorie hunderte URL-Varianten. Das Canonical Tag zeigt auf die parameterfreie Stammseite.
- Produkte in mehreren Kategorien: Ein Produkt, das unter
/schuhe/nike-air-max/und/sale/nike-air-max/erreichbar ist, existiert für Google auf zwei URLs. Das Canonical verweist auf die primäre Kategorie. - Protokoll- und Subdomain-Varianten:
http://,https://,www.undnon-wwwergeben bis zu vier Versionen derselben Seite. Zusätzlich zum Canonical empfiehlt sich hier eine permanente Weiterleitung auf die bevorzugte Variante. - Druckversionen und PDF-Varianten: Eigenständige URLs für Druckansichten oder PDF-Exporte duplizieren den Seiteninhalt. Das Canonical zeigt auf die HTML-Originalseite. Bei PDF-Dokumenten ohne HTML-Gegenstück kommt stattdessen der HTTP-Header zum Einsatz:
Link: <https://www.example.com/doc.pdf>; rel="canonical"(die kanonische Link-Relation ist definiert in RFC 6596, der Transport über den HTTP-Link-Header in RFC 5988). - Syndizierter Content: Wird ein Artikel auf einer fremden Domain veröffentlicht, kann ein Cross-Domain Canonical auf die Originalquelle verweisen. Google entfernt die nicht-kanonische Version dann aus dem Index und überträgt die Signale auf das Original.
- Index-Seiten mit Duplikaten: URLs wie
/home,/index.htmlund/zeigen denselben Inhalt. Das Canonical auf die kürzeste, sauberste URL-Variante eliminiert diese technische Redundanz.
Wie behandelt Google das Canonical Tag?
Google behandelt das Canonical Tag als Hinweis, nicht als verbindliche Anweisung. Der Unterschied ist entscheidend: Eine robots.txt-Direktive ist eine Blockierung, die Google respektiert. Ein Canonical ist ein Signal, das Google als eines von rund 40 Kanonisierungssignalen abwägt.
Drei Signalquellen gewichtet Google stärker als das HTML-Canonical:
- 301 Redirects sind das stärkste Kanonisierungssignal. Wenn eine URL per 301 auf eine andere weiterleitet, behandelt Google die Ziel-URL als kanonisch.
- Interne Verlinkung beeinflusst die Kanonisierung indirekt. Verlinken alle internen Links auf Version A, aber das Canonical zeigt auf Version B, kann Google Version A bevorzugen.
- HTTPS-Präferenz: Google bevorzugt automatisch die HTTPS-Version gegenüber HTTP und die kürzere URL gegenüber der längeren.
In der Praxis überschreibt Google den Canonical in drei Fällen: wenn sich der Inhalt der kanonischen URL und der nicht-kanonischen URL stark unterscheidet, wenn die kanonische URL auf einen 4XX- oder 5XX-Fehler läuft, oder wenn andere Signale (Sitemap, interne Links, Redirects) eine andere URL als kanonisch nahelegen.
Was ist ein selbstreferenzierender Canonical?
Ein selbstreferenzierender Canonical zeigt auf die URL der Seite selbst. Jede Seite einer Website sollte einen solchen selbstreferenzierenden Canonical enthalten. John Mueller (Google Search Advocate) bestätigte diese Best Practice mehrfach.
Der Nutzen liegt in der Vorhersagbarkeit. Ohne Canonical wählt Google die kanonische URL eigenständig aus, basierend auf internen Links, Sitemap-Einträgen und weiteren Signalen. Das Ergebnis ist nicht immer die gewünschte URL. Ein selbstreferenzierender Canonical reduziert diese Unsicherheit, indem er ein explizites Signal für die bevorzugte Version setzt.
Bei paginierten Seiten gilt eine abweichende Regel: Jede Seite der Pagination (Seite 1, 2, 3) erhält einen Canonical auf sich selbst. Alle paginierten Seiten auf Seite 1 zu kanonisieren ist ein verbreiteter Fehler, der dazu führt, dass Google die Inhalte ab Seite 2 aus dem Suchindex entfernt. Google hat rel=“next” und rel=“prev” als Paginierungssignal 2019 offiziell als nicht mehr unterstützt erklärt.
Was ist der Unterschied zwischen Canonical Tag und 301 Redirect?
Beide Methoden lösen das Problem doppelter Inhalte, aber auf grundlegend verschiedene Weise. Die Wahl hängt davon ab, ob die ursprüngliche URL für Nutzer erreichbar bleiben soll.
| Eigenschaft | Canonical Tag | 301 Redirect |
|---|---|---|
| Ursprüngliche URL erreichbar | Ja | Nein (Weiterleitung) |
| Implementierung | HTML <head> oder HTTP-Header | Server-Konfiguration |
| Umkehrbarkeit | Sofort | Schwierig (Browser-Cache, CDN-Cache) |
| Signalstärke bei Google | Starker Hinweis | Stärkstes Signal |
| Linkstärke-Übertragung | Konsolidierung auf kanonische URL | Vollständige Weiterleitung |
| Einsatzszenario | Duplikate, die erreichbar bleiben sollen | Permanenter URL-Wechsel |
In der Praxis ergänzen sich beide Methoden. Bei einem Website-Relaunch leiten 301 Redirects die alten URLs auf die neuen weiter. Das Canonical Tag auf den neuen Seiten bestätigt zusätzlich, welche URL Google indexieren soll. Die Kombination ist die zuverlässigste Kanonisierungsstrategie.
Welche Fehler treten bei Canonical Tags am häufigsten auf?
Acht Implementierungsfehler verursachen in der Praxis die meisten Probleme:
- Mehrere Canonical Tags auf einer Seite: Enthält der
<head>zwei oder mehr<link rel="canonical">-Elemente, ignoriert Google beide. CMS-Plugins, Theme-Funktionen und manuell eingefügte Tags kollidieren häufig. - Canonical auf eine fehlerhafte URL: Ein Canonical, das auf eine 404- oder 500-Seite zeigt, ist für Google wertlos. Der Googlebot folgt dem Canonical, findet einen Fehler und verwirft das Signal.
- Canonical auf eine Redirect-Kette: Das Canonical sollte immer auf die finale URL zeigen, nicht auf eine URL, die selbst weiterleitet. Jede Zwischenstation in einer Redirect-Kette verbraucht Crawl-Kapazität und verzögert die Signalübertragung.
- Canonical kombiniert mit noindex: Beide Signale widersprechen sich. Das Canonical sagt “indexiere diese URL”, noindex sagt “entferne diese URL aus dem Index”. Google muss zwischen beiden Signalen entscheiden und das Ergebnis ist nicht vorhersagbar.
- Relative statt absolute URLs:
<link rel="canonical" href="/seite/">funktioniert technisch, erzeugt aber bei fehlerhafter Base-URL oder Cross-Domain-Szenarien Probleme. Absolute URLs mit Protokoll und Domain sind die sichere Variante. - Alle paginierten Seiten auf Seite 1 kanonisiert: Google entfernt die Inhalte ab Seite 2 aus dem Index. Jede paginierte Seite braucht einen selbstreferenzierenden Canonical.
- Canonical und Sitemap widersprechen sich: Wenn die XML-Sitemap URL A enthält, aber das Canonical auf URL B zeigt, sendet die Website widersprüchliche Signale. Google muss raten, welche URL korrekt ist.
- Canonical auf inhaltlich abweichende Seite: Google prüft, ob die kanonische URL und die verweisende URL tatsächlich denselben Inhalt zeigen. Bei starker Abweichung ignoriert Google das Canonical vollständig.
Wie funktioniert ein Cross-Domain Canonical?
Ein Cross-Domain Canonical verweist von einer Seite auf Domain A auf eine Seite auf Domain B. Google unterstützt diese domainübergreifende Kanonisierung, behandelt sie aber mit zusätzlicher Skepsis.
Der klassische Anwendungsfall ist syndizierter Content. Ein Gastartikel auf einem Branchenportal enthält ein Canonical auf den Originalartikel der eigenen Domain. Google hat allerdings seit 2023 die Empfehlung geändert: Cross-Domain Canonicals funktionieren in der Praxis nicht zuverlässig, weil die syndizierte Version trotzdem im Index verbleiben und sogar das Original überflügeln kann. Google empfiehlt Syndikationspartnern stattdessen, die syndizierte Version mit noindex auszuzeichnen. Eine Ausnahme bildet Google News, wo Cross-Domain Canonicals weiterhin das empfohlene Verfahren sind.
Cross-Domain Canonicals erfordern absolute URLs mit vollständiger Domain. Google kann das Signal ignorieren, wenn der Inhalt auf beiden Domains stark voneinander abweicht, wenn die Ziel-URL technische Probleme aufweist oder wenn andere Signale der Kanonisierung widersprechen.
Wie interagieren Canonical Tag und Hreflang?
Canonical und Hreflang-Annotationen ergänzen sich, ersetzen sich aber nicht. Das Canonical bestimmt die bevorzugte URL-Version innerhalb einer Sprache. Hreflang verknüpft Sprachversionen untereinander. Beide sind Hinweise, keine verbindlichen Anweisungen.
Google empfiehlt, dass das Canonical-Ziel immer in derselben Sprache liegt wie die verweisende Seite. Ein deutsches Canonical auf eine englische Seite erzeugt widersprüchliche Signale. Nicht-kanonische URLs mit Hreflang-Annotationen führen zu unvorhersehbarem Verhalten in internationalen Suchergebnissen: Google kann die nicht-kanonische URL trotzdem in lokalen SERPs ausspielen, wenn das Hreflang-Signal stärker wirkt als das Canonical.
Wie prüfe ich Canonical Tags auf meiner Website?
Ein systematischer Canonical-Audit deckt fehlerhafte Konfigurationen auf, bevor sie Rankings kosten. Vier Schritte bilden den Prüf-Workflow:
- Crawl durchführen: Tools wie Screaming Frog crawlen die gesamte Website und erfassen für jede URL das Canonical Tag, den HTTP-Statuscode und die Indexierbarkeit. Der Report zeigt sofort, welche Seiten kein Canonical haben, welche auf fehlerhafte URLs zeigen und wo mehrere Canonical Tags kollidieren.
- Google Search Console prüfen: Der Coverage Report unter “Seiten” listet URLs, die Google als “Duplikat: Vom Nutzer nicht als kanonisch ausgewählt” markiert hat. Diese Einträge zeigen, wo Google das gesetzte Canonical ignoriert und eine andere URL bevorzugt.
- Sitemap abgleichen: Jede URL in der Sitemap sollte einen selbstreferenzierenden Canonical haben. URLs, deren Canonical auf eine andere Seite zeigt, gehören nicht in die Sitemap.
- Stichproben im Quellcode: Bei JavaScript-lastigen Websites den gerenderten Quellcode prüfen (über die Google Search Console URL-Prüfung), nicht nur den Raw-HTML-Code. Canonical Tags, die erst nach dem JavaScript-Rendering erscheinen, erkennt Google unter Umständen nicht zuverlässig.
Die Ergebnisse aus diesen vier Schritten ergeben eine priorisierte Fix-Liste. Seiten mit hohem organischen Traffic und fehlerhaftem Canonical haben die höchste Priorität. Ein strukturiertes technisches SEO-Audit deckt diese Probleme systematisch auf und liefert die Grundlage für eine saubere Canonical-Konfiguration.
SEO nicht nur verstehen, sondern umsetzen?
Wir machen die Theorie zur Praxis. In einem kostenlosen Erstgespräch zeigen wir dir, wie diese Konzepte konkret für dein Unternehmen funktionieren.