Eine Webseite kann technisch unter mehreren URLs erreichbar sein, obwohl für Besucher praktisch derselbe Inhalt erscheint.

Zum Beispiel:

https://example.de/produkt/
https://example.de/produkt/?utm_source=newsletter
https://example.de/produkt/?farbe=rot

Oder:

http://example.de/artikel/
https://example.de/artikel/

Oder derselbe Inhalt ist als normale Webseite und zusätzlich als PDF vorhanden.

Für eine Suchmaschine entsteht dann eine Frage:

Welche dieser URLs soll als maßgebliche Version behandelt werden?

Genau hier beginnt die Canonicalisierung.

Google fasst sehr ähnliche oder doppelte Seiten zu Gruppen zusammen und wählt daraus eine repräsentative URL als Canonical beziehungsweise kanonische URL. Website-Betreiber können Google ihre bevorzugte Variante mitteilen – unter anderem mit rel="canonical", Weiterleitungen und Sitemap-Signalen. Die endgültige Auswahl bleibt jedoch bei Google. (Google for Developers)

Das führt zur wichtigsten Grundlage dieses Artikels:

Ein Canonical-Tag ist ein starkes Signal für die bevorzugte URL – aber kein absoluter Befehl.

Was bedeutet „kanonische URL“?

„Kanonisch“ klingt komplizierter, als das Konzept ist.

Angenommen, derselbe Inhalt ist über drei Adressen erreichbar:

URL A
URL B
URL C

Google erkennt:

Diese Seiten besitzen denselben oder weitgehend denselben Hauptinhalt.

Dann werden sie vereinfacht zu einer Gruppe zusammengefasst:

URL A ─┐
URL B ─┼→ gleiche Inhaltsgruppe
URL C ─┘

Aus dieser Gruppe wird eine repräsentative URL ausgewählt:

URL A ─┐
URL B ─┼→ URL A wird Canonical
URL C ─┘

Google bezeichnet diesen Vorgang als Canonicalization beziehungsweise Deduplizierung. Die kanonische URL ist dabei diejenige Adresse, die Google als repräsentativste Version eines sehr ähnlichen oder doppelten Inhalts auswählt. (Google for Developers)

Duplicate Content ist innerhalb einer Website völlig normal

Der Begriff „Duplicate Content“ klingt häufig, als wäre bereits ein schwerer SEO-Fehler entstanden.

Das ist zu dramatisch.

Doppelte oder sehr ähnliche URLs können aus vollkommen normalen technischen Gründen entstehen.

Zum Beispiel durch:

Filter,

Sortierungen,

Trackingparameter,

HTTP und HTTPS,

mobile und Desktopvarianten,

regionale Versionen,

Druckansichten,

CMS-Funktionen.

Google weist ausdrücklich darauf hin, dass ein gewisses Maß an Duplicate Content innerhalb einer Website normal ist und nicht automatisch gegen Spamrichtlinien verstößt. (Google for Developers)

Das eigentliche Problem lautet deshalb nicht:

Zwei URLs sind ähnlich – Katastrophe.

Sondern:

Welche URL soll die maßgebliche Version dieses Inhalts sein?

Warum braucht Google überhaupt eine bevorzugte URL?

Angenommen, ein Artikel ist über fünf leicht unterschiedliche URLs erreichbar.

Dann wäre es wenig sinnvoll, in den Suchergebnissen fünf nahezu identische Treffer derselben Website anzuzeigen.

Google versucht deshalb, solche Varianten zu gruppieren und eine repräsentative Seite auszuwählen. Die kanonische Seite wird anschließend normalerweise als Hauptquelle für die Bewertung des Inhalts verwendet und häufiger gecrawlt als die erkannten Duplikate. (Google for Developers)

Canonicalisierung hilft damit sowohl Suchmaschinen als auch Website-Betreibern.

Auch Messdaten werden dadurch übersichtlicher

Nehmen wir an, ein Artikel wird aufgerufen als:

/artikel/
/artikel/?utm_source=a
/artikel/?utm_source=b
/artikel/?ref=partner

Inhaltlich ist es dieselbe Seite.

Wenn Suchmaschinen sämtliche Varianten unabhängig behandeln würden, könnten auch verschiedene externe Links und Suchsignale auf zahlreiche URL-Versionen verteilt werden.

Google nennt als einen Zweck der Canonicalisierung ausdrücklich die Konsolidierung bestimmter Signale ähnlicher oder doppelter URLs auf eine bevorzugte Version. (Google for Developers)

Gleichzeitig wird auch die eigene Auswertung einfacher, wenn klar ist:

Das ist die Hauptadresse dieses Inhalts.

Wie sieht ein Canonical-Tag aus?

Für eine normale HTML-Seite kann im <head> beispielsweise stehen:

<link rel="canonical" href="https://example.de/wissen/caching/">

Damit teilt die aktuelle Seite Google sinngemäß mit:

Die bevorzugte Version dieses Inhalts befindet sich unter https://example.de/wissen/caching/.

Google unterstützt dieses rel="canonical"-Linkelement als starkes Canonicalisierungssignal. Es gehört in den <head> des HTML-Dokuments. (Google for Developers)

Das Canonical kann auf dieselbe URL zeigen

Eine Seite:

https://example.de/wissen/caching/

kann selbst enthalten:

<link rel="canonical" href="https://example.de/wissen/caching/">

Das wird als self-referencing canonical beziehungsweise selbstreferenzielles Canonical bezeichnet.

Google empfiehlt ausdrücklich, auch auf der kanonischen Seite selbst ein rel="canonical" auf ihre eigene bevorzugte URL zu setzen. (Google for Developers)

Das wirkt zunächst überflüssig.

Es kann aber helfen, die bevorzugte Adresse eindeutig zu kommunizieren.

Warum ist ein selbstreferenzielles Canonical nützlich?

Angenommen, derselbe Artikel wird über Trackingparameter aufgerufen:

https://example.de/wissen/caching/?utm_source=newsletter

Die Seite liefert in ihrem HTML trotzdem:

<link rel="canonical" href="https://example.de/wissen/caching/">

Damit ist unabhängig vom aktuellen Parameter klar:

aktuelle URL:
.../caching/?utm_source=newsletter

bevorzugte URL:
.../caching/

Dasselbe Template kann diese Logik für viele URL-Varianten automatisch bereitstellen.

Absolute URLs sind die sauberste Variante

Google empfiehlt für Canonical-Angaben absolute Pfade beziehungsweise vollständige URLs.

Also:

<link rel="canonical" href="https://example.de/wissen/caching/">

statt lediglich:

<link rel="canonical" href="/wissen/caching/">

Absolute URLs reduzieren Mehrdeutigkeiten und sind auch für Canonical-Angaben im HTTP-Header erforderlich. (Google for Developers)

Für ein CMS ist das normalerweise kein zusätzlicher Aufwand.

WordPress beziehungsweise ein SEO-System kann die vollständige URL automatisch erzeugen.

Ein Canonical ist ein Signal und kein Befehl

Das ist der wichtigste Unterschied zu noindex.

Wenn eine Seite enthält:

<meta name="robots" content="noindex">

lautet die Indexierungsanweisung:

Diese Seite soll nicht im Suchindex erscheinen.

Bei:

<link rel="canonical" href="https://example.de/ziel/">

lautet die Aussage dagegen:

Ich halte diese URL für die bevorzugte Version dieses Inhalts.

Google berücksichtigt diesen Hinweis gemeinsam mit anderen Signalen und kann letztlich trotzdem eine andere kanonische URL auswählen. (Google for Developers)

Deshalb spricht Google bei Canonicalisierung bewusst von Signalen.

Warum ignoriert Google manchmal mein Canonical?

Angenommen, Seite A sagt:

Canonical → Seite B

Google hält Seite A aber für wesentlich vollständiger oder betrachtet die beiden Inhalte gar nicht als echte Duplikate.

Dann kann Google zu einer anderen Entscheidung gelangen.

Auch widersprüchliche technische Signale können die Auswahl beeinflussen.

Google nennt unter anderem Weiterleitungen, Canonical-Elemente, Sitemaps und HTTP/HTTPS als Faktoren bei der Canonicalisierung. (Google for Developers)

Der Canonical-Tag besitzt also Gewicht.

Er hat aber kein Vetorecht gegen sämtliche anderen Informationen.

Welche Canonicalisierungssignale gibt es?

Google nennt derzeit mehrere zentrale Möglichkeiten, eine bevorzugte URL zu signalisieren.

Besonders stark sind:

Weiterleitungen

und:

rel="canonical"

Die Aufnahme einer URL in eine Sitemap ist dagegen ein schwächeres Canonical-Signal. Mehrere miteinander übereinstimmende Signale können sich gegenseitig verstärken. (Google for Developers)

Vereinfacht:

301-Weiterleitung
        ↓
rel="canonical"
        ↓
Sitemap

Das bedeutet nicht, dass eine Website zwangsläufig alle drei Methoden gleichzeitig für jede Seite benötigt.

Es bedeutet:

Wenn mehrere Signale existieren, sollten sie möglichst dieselbe Geschichte erzählen.

Konsistenz ist wichtiger als die Menge der Signale

Angenommen, wir haben drei URLs:

A
B
C

Nun konfigurieren wir:

A Canonical → B
Sitemap enthält C
interne Links → A
B leitet → C

Google kann dieses Durcheinander möglicherweise trotzdem auflösen.

Aber warum sollte man es unnötig kompliziert machen?

Eine saubere Konfiguration wäre eher:

bevorzugte URL: C

Canonical → C
Sitemap → C
interne Links → C
alte URL → C

Google empfiehlt ausdrücklich, keine unterschiedlichen kanonischen URLs über verschiedene Canonicalisierungsmethoden anzugeben. (Google for Developers)

Technische SEO ist häufig weniger die Kunst, möglichst viele Tags zu setzen, sondern Widersprüche zu vermeiden.

Interne Links sollten zur kanonischen URL führen

Wenn wir selbst die vollständige Kontrolle über unsere internen Links besitzen, sollten diese direkt auf die bevorzugte URL zeigen.

Google empfiehlt ausdrücklich, innerhalb der eigenen Website auf die kanonische URL statt auf eine Duplikatvariante zu verlinken. (Google for Developers)

Angenommen:

Canonical:

https://example.de/wissen/caching/

Unsere internen Links sollten nicht dauerhaft lauten:

http://example.de/wissen/caching/

oder:

https://example.de/wissen/caching/?version=1

wenn diese Varianten lediglich technische Nebenwege darstellen.

Interne Links sind ein eigenes Canonicalisierungssignal

Google nennt konsistente interne Verlinkung zwar nicht in derselben formalen Stärke-Reihenfolge wie Redirect, Canonical und Sitemap, empfiehlt sie aber ausdrücklich zur Unterstützung der bevorzugten URL. (Google for Developers)

Das ergibt auch logisch Sinn.

Wenn tausend interne Links zu URL A führen, während A selbst sagt:

Eigentlich ist B die wichtigere Adresse.

ist die Website nicht besonders klar organisiert.

Die einfachste Lösung lautet:

Direkt B verlinken.

Die Sitemap sollte ebenfalls nur die bevorzugte Variante enthalten

Unsere XML-Sitemap sollte diejenigen URLs enthalten, die wir selbst als kanonisch betrachten.

Google bezeichnet Sitemap-Einträge ausdrücklich als schwächeres Canonical-Signal. (Google for Developers)

Daraus ergibt sich ein sinnvolles Modell:

Canonical:
https://example.de/artikel/

Sitemap:
https://example.de/artikel/

interne Links:
https://example.de/artikel/

Alle drei Ebenen stimmen überein.

Das ist wesentlich sauberer als eine Sitemap voller Weiterleitungs- und Parameter-URLs.

HTTP und HTTPS sind ein klassischer Canonical-Fall

Historisch kann eine Seite sowohl unter:

http://example.de/artikel/

als auch:

https://example.de/artikel/

existieren.

Google bevorzugt bei ansonsten vergleichbaren Seiten grundsätzlich die HTTPS-Version, sofern keine widersprüchlichen oder technischen Probleme bestehen. Google nennt unter anderem ungültige Zertifikate, HTTPS-zu-HTTP-Weiterleitungen oder ein Canonical zurück auf HTTP als mögliche Gründe für eine andere Auswahl. (Google for Developers)

Für eine moderne Website sollte die Lösung allerdings ohnehin klar sein:

HTTP
↓
301
HTTPS

und Canonicals, interne Links und Sitemap zeigen ebenfalls auf HTTPS.

Mehr über die technische Grundlage findest du unter SSL und HTTPS verständlich erklärt.

www und non-www sollten ebenfalls eindeutig sein

Eine Website kann technisch unter:

https://example.de/

und:

https://www.example.de/

laufen.

Man sollte eine Hauptvariante auswählen.

Beispielsweise:

https://example.de/

Dann werden:

Canonicals,

interne Links,

Sitemap

und Weiterleitungen

darauf ausgerichtet.

Wenn beide Varianten denselben Inhalt bereitstellen und keine klare Konsistenz besteht, muss Google stärker selbst entscheiden, welche Version kanonisch sein soll.

Parameter sind einer der häufigsten Anwendungsfälle

Trackingparameter verändern häufig nicht den Seiteninhalt.

Zum Beispiel:

/artikel/?utm_source=newsletter
/artikel/?utm_source=facebook
/artikel/?utm_campaign=sommer

Inhaltlich bleibt es:

/artikel/

Dann kann jede Parameterseite dasselbe Canonical liefern:

<link rel="canonical" href="https://example.de/artikel/">

Damit wird die stabile Hauptadresse signalisiert.

Das ist ein sehr natürlicher Canonical-Einsatz.

Nicht jeder Parameter erzeugt aber ein Duplikat

Angenommen:

/shop/?farbe=rot

zeigt ausschließlich rote Produkte.

Und:

/shop/?farbe=blau

zeigt ausschließlich blaue Produkte.

Nun sind die Hauptinhalte möglicherweise deutlich verschieden.

Beide pauschal auf:

/shop/

zu kanonisieren, könnte deshalb sachlich falsch sein.

Canonicalisierung ist für duplizierte oder sehr ähnliche Inhalte gedacht. Google gruppiert Seiten danach, ob ihr Hauptinhalt gleich oder sehr ähnlich ist. (Google for Developers)

Die Existenz eines Fragezeichens in einer URL ist kein ausreichender Grund für einen Canonical.

Filterseiten brauchen deshalb eine Strategie

Bei Shops kann es zahlreiche Kombinationen geben:

/schuhe/
/schuhe/?farbe=rot
/schuhe/?groesse=42
/schuhe/?farbe=rot&groesse=42

Manche Filterseiten können einen echten eigenständigen Suchzweck besitzen.

Andere sind lediglich technische Variationen.

Die Lösung kann deshalb je nach Seitentyp unterschiedlich ausfallen:

indexierbar mit eigenem Canonical,

Canonical auf eine Hauptseite,

noindex,

Crawlsteuerung,

gar keine öffentlich verlinkte URL.

Ein pauschaler Canonical für sämtliche Filter kann genauso falsch sein wie die Indexierung sämtlicher Filterkombinationen.

Canonical ist nicht für völlig unterschiedliche Seiten gedacht

Angenommen, eine Website besitzt:

/wordpress/

und:

/webhosting/.

Nun bekommt die Webhosting-Seite ein Canonical auf WordPress, weil die WordPress-Seite stärker rankt.

Das ist kein sinnvoller Einsatz.

Die Inhalte behandeln unterschiedliche Themen.

Google erwartet rel="canonical" grundsätzlich bei doppelten oder sehr ähnlichen Seiten. (Google for Developers)

Canonical ist kein Werkzeug, um vermeintliche SEO-Stärke beliebig zwischen unabhängigen Artikeln zu übertragen.

Ein Canonical sollte auf einen tatsächlich passenden Inhalt zeigen

Angenommen, fünf veraltete Artikel werden einfach alle auf die Startseite kanonisiert.

Das löst nicht automatisch deren Probleme.

Wenn die Hauptinhalte völlig unterschiedlich sind, kann Google diese Signale ignorieren.

Dasselbe gilt für beliebige Canonicals auf Kategorien oder besonders starke Seiten.

Das Canonical-Ziel sollte die tatsächlich repräsentative Version desselben oder sehr ähnlichen Inhalts sein.

Canonical und 301 sind nicht dasselbe

Angenommen, es existieren zwei URLs:

/alter-artikel/
/neuer-artikel/

Die alte Seite soll überhaupt nicht mehr separat erreichbar sein.

Dann ist eine permanente Weiterleitung häufig die logischere Lösung:

/alter-artikel/
↓
301
/neuer-artikel/

Google betrachtet Weiterleitungen als starkes Canonicalisierungssignal. (Google for Developers)

Bei einem Canonical dagegen bleibt die alte URL für Besucher weiterhin erreichbar:

/alter-artikel/
↓
200 OK
↓
Canonical → /neuer-artikel/

Das ist ein wesentlicher Unterschied.

Canonical bedeutet: Beide URLs dürfen weiterhin existieren

Das macht Canonical besonders nützlich bei Varianten, die technisch oder für Nutzer weiterhin benötigt werden.

Zum Beispiel:

Trackingvarianten,

bestimmte Filter,

Druckansichten,

andere Dateiformate.

Die Duplikat-URL bleibt erreichbar.

Die Website sagt lediglich:

Für Suchmaschinen ist diese andere URL die bevorzugte Version.

Wenn eine alte Adresse dagegen vollständig aufgegeben wird, ist eine Weiterleitung meist klarer.

noindex und Canonical sind ebenfalls nicht dasselbe

Im vorherigen Artikel noindex verstehen haben wir gelernt:

noindex
→ diese Seite nicht in den Index

Canonical bedeutet:

canonical
→ diese URL als bevorzugte Version einer Gruppe betrachten

Google empfiehlt ausdrücklich, noindex nicht als Mittel zur Auswahl einer kanonischen URL innerhalb derselben Website zu verwenden. Dafür ist rel="canonical" das passendere Werkzeug. (Google for Developers)

Dieser Unterschied ist fundamental.

noindex verwirft die Seite als Suchergebnis

Canonical dagegen versucht, ihre Beziehung zu einer anderen URL zu beschreiben.

Das kann auch Auswirkungen auf die Konsolidierung bestimmter Signale der Varianten haben. Google nennt genau diese Zusammenführung als einen Zweck der Canonicalisierung. (Google for Developers)

Wenn das Problem also lautet:

Diese zwei URLs sind im Grunde derselbe Inhalt.

dann denken wir zuerst an Canonical beziehungsweise Redirect.

Wenn das Problem lautet:

Diese Seite soll unabhängig davon überhaupt kein Suchergebnis sein.

dann denken wir an noindex.

robots.txt ist noch einmal etwas völlig anderes

Unsere vier Werkzeuge lassen sich inzwischen so unterscheiden:

robots.txt
→ darf der Crawler die URL abrufen?

noindex
→ soll die URL im Suchindex erscheinen?

canonical
→ welche URL ist die bevorzugte Version?

301
→ unter welcher neuen URL befindet sich der Inhalt dauerhaft?

Diese vier Fragen ähneln sich nur auf den ersten Blick.

Technisch beantworten sie völlig unterschiedliche Dinge.

Genau deshalb entstehen so viele SEO-Probleme, wenn die Werkzeuge wahllos kombiniert werden.

Eine robots.txt-Sperre ist keine Canonicalisierung

Google rät ausdrücklich davon ab, robots.txt zur Canonicalisierung zu verwenden. Eine blockierte URL kann Google weiterhin bekannt sein, während Google ihren Inhalt und gegebenenfalls darauf vorhandene Canonical-Signale nicht abrufen kann. (Google for Developers)

Wenn zwei Duplikate existieren, lautet die Lösung deshalb nicht automatisch:

Duplicate A
→ robots.txt blockieren

Sondern:

Welche URL soll tatsächlich die bevorzugte sein?

Und welches Canonicalisierungsverfahren passt dazu?

Self-Canonical gehört auf normale indexierbare Seiten

Bei einer eindeutigen Artikel-URL kann beispielsweise stehen:

<link rel="canonical" href="https://example.de/wissen/canonical-tag/">

Damit sagt die Seite:

Ich selbst bin meine bevorzugte Version.

Google empfiehlt solche selbstreferenziellen Canonicals ausdrücklich. (Google for Developers)

Für WordPress wird das normalerweise automatisiert erzeugt.

Ein Redakteur sollte nicht jeden Artikel von Hand im HTML bearbeiten müssen.

WordPress erzeugt Canonicals bereits im Core

WordPress besitzt selbst eine Canonical-Funktion für bestimmte Singular-Seiten. Zusätzlich übernehmen verbreitete SEO-Plugins häufig weitergehende Canonical-Steuerung für Beiträge, Archive und Sonderfälle.

Für den Betreiber ist jedoch weniger wichtig, welches Modul den Tag erzeugt.

Entscheidend ist:

Welches Canonical wird im ausgelieferten HTML tatsächlich ausgegeben?

Bei technischen Problemen sollte deshalb immer der öffentliche Quelltext kontrolliert werden.

Zwei SEO-Plugins können Canonical-Konflikte erzeugen

Angenommen, Plugin A schreibt:

<link rel="canonical" href="https://example.de/a/">

Plugin B schreibt zusätzlich:

<link rel="canonical" href="https://example.de/b/">

Nun besitzt dieselbe Seite widersprüchliche Canonical-Angaben.

Genau solche Konfigurationen sollten vermieden werden.

Google rät generell davon ab, dieselbe Seite über unterschiedliche Canonicalisierungsmethoden auf verschiedene Ziel-URLs zeigen zu lassen. (Google for Developers)

Mehr SEO-Plugins bedeuten also nicht mehr Kontrolle.

Oft bedeuten sie nur mehr mögliche Konflikte.

Ein Canonical kann auch per HTTP-Header gesetzt werden

Für HTML wird meist das <link>-Element verwendet.

Es existiert jedoch zusätzlich eine HTTP-Variante:

Link: <https://example.de/dokument/>; rel="canonical"

Google unterstützt den rel="canonical"-HTTP-Header und empfiehlt, sich nach Möglichkeit für eine der beiden Methoden zu entscheiden, weil die gleichzeitige Nutzung von HTML und HTTP-Header fehleranfälliger sein kann. (Google for Developers)

Der HTTP-Header wird besonders interessant bei Nicht-HTML-Dateien.

Auch PDFs können ein Canonical besitzen

Eine PDF besitzt keinen HTML-<head>.

Trotzdem kann sie inhaltlich eine zweite Version einer HTML-Seite sein.

Dann kann der Server beispielsweise antworten:

HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <https://example.de/ratgeber/>; rel="canonical"

Google unterstützt rel="canonical" im HTTP-Header ausdrücklich auch für Nicht-HTML-Dokumente wie PDFs. (Google for Developers)

Das ist ein wichtiger Unterschied zum normalen HTML-Canonical.

PDF noindex und PDF Canonical beantworten unterschiedliche Fragen

Eine PDF kann per:

X-Robots-Tag: noindex

vollständig von der Indexierung ausgeschlossen werden.

Oder per:

Link: <https://example.de/artikel/>; rel="canonical"

als Variante einer HTML-Version eingeordnet werden.

Das sind unterschiedliche Strategien.

noindex sagt:

PDF nicht als Suchergebnis.

Canonical sagt:

HTML-Seite ist die repräsentative Fassung dieses Inhalts.

Welche Variante sinnvoller ist, hängt vom konkreten Dokument ab.

Ein Canonical auf eine andere Domain ist technisch möglich

Google unterstützt Canonicals auch domainübergreifend.

Eine Seite auf Domain A kann damit eine Seite auf Domain B als kanonische Version signalisieren. (Google for Developers)

Das sollte jedoch bewusst eingesetzt werden.

Ein Cross-Domain-Canonical bedeutet sinngemäß:

Der Inhalt dort ist die repräsentative Version dieses Inhalts.

Damit kann die eigene URL unter Umständen nicht als reguläres Suchergebnis gewählt werden.

Es ist also keine unverbindliche Quellenangabe.

Syndizierte Artikel sind komplexer als „einfach Canonical setzen“

Wer denselben Artikel an mehrere Publisher weitergibt, denkt häufig:

Die Partner setzen einfach Canonical auf mich und alles ist erledigt.

Google weist in seiner aktuellen Troubleshooting-Dokumentation darauf hin, dass rel="canonical" für syndizierte Inhalte nicht die empfohlene Methode ist, wenn man Duplikation durch Syndikationspartner vermeiden möchte; dort empfiehlt Google eher, die Partnerkopien von der Indexierung auszuschließen. (Google for Developers)

Das zeigt erneut:

Canonicalisierung hängt vom tatsächlichen Anwendungsfall ab.

Nicht jede Contentkopie ist technisch identisch zu einer Parameter- oder Druckversion innerhalb derselben Website.

Canonical-Ketten sollte man vermeiden

Angenommen:

A Canonical → B
B Canonical → C
C Canonical → C

Google kann solche Situationen möglicherweise verarbeiten.

Sauberer ist jedoch:

A → C
B → C
C → C

Canonical-Signale sollten möglichst direkt auf das endgültige gewünschte Ziel zeigen.

Dasselbe Prinzip kennen wir bereits von Weiterleitungsketten.

Jede zusätzliche Zwischenstufe erzeugt unnötige Komplexität.

Das Canonical-Ziel sollte erreichbar sein

Ein Canonical auf:

/seite-alt/

hilft wenig, wenn diese URL:

404 liefert,

gelöscht wurde

oder auf völlig andere Inhalte verweist.

Das Ziel sollte eine funktionierende, hochwertige und inhaltlich passende URL sein.

Googles Canonical-Dokumentation empfiehlt entsprechend, existierende sinnvolle Ziel-URLs zu verwenden. (Google for Developers)

Ein Canonical ist kein Verweis ins Archiv längst verschwundener Seiten.

Canonical auf eine Weiterleitung ist unnötig kompliziert

Technisch kann ein Canonical-Ziel selbst weiterleiten.

Beispielsweise:

A Canonical → B
B 301 → C

Google kann den Redirect weiterverarbeiten.

Aber wiederum wäre direkter besser:

A Canonical → C

Die Website kennt schließlich bereits das endgültige Ziel.

Interne Signale sollten nicht absichtlich über Umwege geführt werden.

Canonical und Pagination brauchen besondere Vorsicht

Angenommen, eine Kategorie besitzt:

/kategorie/
/kategorie/page/2/
/kategorie/page/3/

Seite zwei und drei enthalten jeweils andere Artikel.

Sie sind deshalb keine Duplikate der ersten Seite.

Ein Canonical von jeder paginierten Seite pauschal auf Seite eins kann dazu führen, dass die zusätzlichen Inhalte nicht als eigenständige Bestandteile der Serie verstanden werden.

Google warnte bereits früh ausdrücklich vor dieser fehlerhaften Canonicalisierung von Pagination, weil die einzelnen Seiten unterschiedliche Inhalte enthalten. (Google for Developers)

Die richtige Lösung hängt von der konkreten Navigation ab, aber:

Unterschiedlicher Hauptinhalt ist kein Duplicate Content nur weil das Template gleich aussieht.

Kategorien sollten nicht auf ihren wichtigsten Artikel kanonisieren

Angenommen:

/wissen/performance/

ist eine Themenübersicht.

Darin befindet sich der Artikel:

/wissen/wordpress-performance/

Nun könnte man denken:

Der Artikel ist wichtiger. Also Canonical der Kategorie auf den Artikel.

Das wäre konzeptionell falsch, wenn beide Seiten unterschiedliche Aufgaben besitzen.

Die Kategorie ist eine Übersicht.

Der Artikel ist ein Ratgeber.

Ein Canonical sagt nicht:

Diese andere Seite ist wichtiger.

Sondern:

Diese andere URL repräsentiert im Wesentlichen denselben Inhalt.

Das sind völlig unterschiedliche Aussagen.

Canonical ist kein Mittel gegen Keyword-Kannibalisierung

Wenn zwei Artikel für dieselbe Suchanfrage konkurrieren, sollte zuerst geprüft werden:

Beantworten sie dieselbe Suchintention?

Sind sie tatsächlich redundant?

Sollten sie zusammengeführt werden?

Sind sie ausreichend unterschiedlich?

Ein Canonical ist nur dann passend, wenn die Seiten im Wesentlichen Duplikate oder Varianten sind.

Zwei eigenständige Artikel mit unterschiedlichem Inhalt künstlich zu kanonisieren löst keine redaktionelle Überschneidung.

Es versteckt sie höchstens hinter einem technischen Signal.

Content-Konsolidierung kann dagegen Canonical oder Redirect benötigen

Angenommen, über Jahre entstanden drei Artikel:

/wordpress-schneller/
/wordpress-speed/
/wordpress-performance-tipps/

Sie behandeln fast exakt dasselbe Thema.

Nun wird ein neuer umfassender Artikel erstellt:

/wordpress-performance/

Wenn die alten Seiten vollständig ersetzt werden, sind permanente Weiterleitungen wahrscheinlich die klarere Lösung.

Wenn einzelne Varianten aus technischen Gründen weiterhin erreichbar bleiben müssen, könnte Canonicalisierung relevant sein.

Die Entscheidung folgt also dem gewünschten URL-Verhalten.

Canonical und hreflang müssen zusammenpassen

Bei mehrsprachigen oder regionalen Seiten können hreflang und Canonical gleichzeitig relevant werden.

Google empfiehlt dabei, die kanonische Seite möglichst innerhalb derselben Sprache zu wählen. Google bevorzugt bei Canonicalisierung außerdem URLs, die korrekt in entsprechende hreflang-Cluster eingebunden sind. (Google for Developers)

Ein Beispiel:

/de/ratgeber/
/en/guide/

sind keine Duplikate im klassischen Sinn, wenn ihr Hauptinhalt tatsächlich übersetzt wurde.

Sie sollten normalerweise nicht alle auf dieselbe Sprachversion kanonisiert werden.

Nur Header und Footer übersetzen reicht dagegen nicht

Google weist darauf hin, dass unterschiedliche Sprachversionen weiterhin als Duplikate betrachtet werden können, wenn lediglich Navigation und unwichtige Elemente übersetzt wurden, während der eigentliche Hauptinhalt identisch bleibt. (Google for Developers)

Das ist besonders für automatisierte Mehrsprachenprojekte interessant.

Eine URL wird nicht allein dadurch zu einem eigenständigen Sprachinhalt, dass im Menü eine andere Sprache steht.

JavaScript sollte das Canonical nicht unnötig verändern

Bei clientseitig gerenderten Websites kann JavaScript Canonical-Elemente beeinflussen.

Google empfiehlt, die Canonical-Information möglichst bereits eindeutig im HTML-Quellcode bereitzustellen und sie nicht nachträglich durch JavaScript auf eine andere URL umzuschreiben. Wenn das Canonical nur per JavaScript gesetzt werden kann, sollte vermieden werden, zunächst ein widersprüchliches Canonical im HTML zu senden. (Google for Developers)

Für normale WordPress-Seiten ist dieses Problem selten.

Bei komplexen JavaScript-Anwendungen wird es relevanter.

Ein Canonical gehört in den head

Für HTML-Seiten sollte:

<link rel="canonical" href="...">

im <head> stehen.

Eine Canonical-Angabe im HTML-Body wird von Google nicht als gültige Canonical-Anweisung verarbeitet. (Google for Developers)

Bei normalen CMS-Templates passiert das automatisch.

Wer jedoch individuell HTML generiert, sollte darauf achten.

Mehrere unterschiedliche Canonicals sind ein Warnsignal

Wenn dieselbe Seite mehrfach unterschiedliche Canonical-Ziele enthält, entsteht ein klarer Konfigurationskonflikt.

Das kann beispielsweise entstehen durch:

Theme,

SEO-Plugin,

Shop-Plugin,

Custom Code.

Die Lösung lautet nicht, zu hoffen, Google werde schon das richtige auswählen.

Es sollte nur eine eindeutige bevorzugte URL kommuniziert werden.

Google empfiehlt ausdrücklich eine klare, konsistente Canonicalisierung und warnt vor widersprüchlichen Angaben. (Google for Developers)

Wie prüfe ich das Canonical einer Seite?

Die einfachste Prüfung beginnt im Seitenquelltext.

Suche nach:

canonical

Du solltest beispielsweise finden:

<link rel="canonical" href="https://example.de/wissen/caching/">

Dann kontrollierst du:

Ist die URL korrekt?

HTTPS?

richtige Domainvariante?

richtiger Pfad?

Keine unerwarteten Parameter?

Funktioniert das Ziel?

Besitzt die Seite nur eine relevante Canonical-Angabe?

Schon diese einfache Prüfung entdeckt viele Konfigurationsfehler.

Bei HTTP-Canonicals müssen die Response-Header geprüft werden

Wenn das Canonical per HTTP-Header gesetzt wird, ist es im HTML-Quelltext nicht sichtbar.

Dann muss die Serverantwort untersucht werden.

Beispielsweise:

Link: <https://example.de/artikel/>; rel="canonical"

Das ist besonders bei PDFs wichtig.

Browser-Entwicklerwerkzeuge oder entsprechende HTTP-Werkzeuge können diese Header anzeigen.

Die Search Console zeigt Googles Auswahl

Die Google Search Console besitzt in der URL-Prüfung Informationen zur Canonicalisierung.

Dabei kann unterschieden werden zwischen:

vom Nutzer angegebenem Canonical

und:

von Google ausgewähltem Canonical.

Google empfiehlt die URL-Prüfung ausdrücklich, wenn man kontrollieren möchte, welche URL Google tatsächlich als kanonisch betrachtet. (Google for Developers)

Das ist ausgesprochen wichtig.

Denn das HTML zeigt nur:

Was wünsche ich mir?

Search Console kann zeigen:

Was hat Google daraus gemacht?

Google-selected Canonical kann von deiner Angabe abweichen

Beispielsweise:

User-declared canonical:
/produkt-a/

Google-selected canonical:
/produkt-b/

Dann besteht kein technischer Fehler allein aufgrund dieser Abweichung.

Aber sie ist ein Anlass zur Untersuchung.

Google empfiehlt zunächst sogar die Frage, ob die von Google ausgewählte URL für Suchnutzer möglicherweise tatsächlich sinnvoller ist als die eigene Präferenz. (Google for Developers)

Wenn nicht, sollten die übrigen Signale geprüft werden.

Was prüfe ich bei einem falschen Google-Canonical?

Ein sinnvoller Diagnoseweg lautet:

Sind beide Seiten tatsächlich ähnlich?
↓
Welches Canonical geben sie aus?
↓
Gibt es Redirects?
↓
Welche URL steht in der Sitemap?
↓
Welche URL wird intern verlinkt?
↓
Welche URL verwendet HTTPS korrekt?
↓
Gibt es technische Fehler?
↓
Sind die Inhalte unterschiedlich genug?

Google nennt inkorrekte Canonical-Elemente, Serverfehlkonfigurationen, Regionalvarianten und sogar kompromittierte Websites als mögliche Ursachen unerwarteter Canonical-Auswahl. (Google for Developers)

Damit wird klar:

Canonical-Probleme können redaktionell oder technisch entstehen.

Ein unerwartetes externes Canonical kann ein Sicherheitsproblem sein

Ein besonders auffälliger Fall:

Deine Website enthält plötzlich:

<link rel="canonical" href="https://fremde-spam-domain.example/...">

obwohl du das nie konfiguriert hast.

Google weist darauf hin, dass kompromittierte Websites durch Angreifer mit fremden Canonical-Tags oder Redirects manipuliert werden können. (Google for Developers)

Ein solches Signal sollte deshalb nicht einfach als SEO-Plugin-Fehler abgetan werden.

Es kann ein Hinweis auf einen Hack sein.

Serverfehlkonfiguration kann Domains miteinander vermischen

Ein Webserver kann falsch konfiguriert sein und beispielsweise denselben Inhalt für mehrere Domains ausliefern.

Dann sieht Google plötzlich sehr ähnliche Seiten auf verschiedenen Hosts.

Google nennt solche Serverfehlkonfigurationen ausdrücklich als mögliche Ursache unerwarteter Canonical-Auswahl. (Google for Developers)

Das kann besonders bei:

VPS,

Reverse Proxies,

Multisite-Systemen,

temporären Domains

oder falsch eingerichteten Virtual Hosts

auftreten.

Canonicalisierung beginnt also manchmal tief in der Serverarchitektur.

Staging-Domains können unbeabsichtigt Canonical-Probleme erzeugen

Ein Relaunch wird unter:

staging.example.net

entwickelt.

Die Testversion ist öffentlich crawlbar.

Später läuft derselbe Inhalt unter:

www.example.de

Nun existieren zwei nahezu identische Websites.

Wenn Canonicals oder Zugriffsschutz falsch konfiguriert sind, muss Google möglicherweise zwischen Produktions- und Stagingversion unterscheiden.

Die bessere Lösung ist meist:

Staging überhaupt nicht öffentlich indexierbar machen und gegebenenfalls zusätzlich authentifizieren.

Canonical sollte nicht als Sicherheitsnetz für eine offen herumliegende vollständige Testkopie missbraucht werden.

Vorschau- und Entwicklungsdomains sollten überprüft werden

Hostingplattformen stellen teilweise temporäre Domains bereit.

Zum Beispiel:

projekt.hosting-anbieter.example

Wenn dort dieselbe produktive Website öffentlich erreichbar bleibt, entsteht eine zusätzliche URL-Variante.

Idealerweise sollte die Architektur verhindern, dass solche Domains als reguläre öffentliche Contentkopien auftreten.

Canonical kann zwar Signale geben.

Sauberer ist häufig, unnötige öffentliche Duplikate gar nicht erst dauerhaft entstehen zu lassen.

Canonical ist kein Ersatz für Serverkonfiguration

Das ist ein wiederkehrendes Muster unserer technischen SEO-Reihe.

Ein falscher Host liefert dieselbe Website?

Dann sollte der Host korrekt konfiguriert werden.

Eine alte Domain soll nicht mehr verwendet werden?

Dann brauchen wir Weiterleitungen.

Eine Seite soll nicht indexiert werden?

Dann noindex.

Eine technische Nebenvariante soll weiterhin existieren, entspricht aber demselben Inhalt?

Dann Canonical.

Je näher das Werkzeug am eigentlichen Problem liegt, desto klarer wird die Architektur.

Canonical darf auf sich selbst zeigen, auch wenn keine Duplikate bekannt sind

Man muss nicht erst warten, bis Google eine Parameter-URL entdeckt.

Ein selbstreferenzielles Canonical auf normalen indexierbaren Seiten ist eine robuste Standardkonfiguration.

Dadurch steht die bevorzugte URL bereits fest.

Wenn später technische Varianten entstehen, kann dasselbe Template weiterhin das korrekte Ziel ausgeben.

Google empfiehlt selbstreferenzielle Canonicals ausdrücklich. (Google for Developers)

Canonical sollte nicht bei jedem Seitenaufruf wechseln

Angenommen, dieselbe Seite liefert zufällig:

Montag:

Canonical → A

Dienstag:

Canonical → B

abhängig von Session, Cookie oder Serverzustand.

Das wäre eine schlechte technische Grundlage.

Eine kanonische URL sollte die stabile bevorzugte Identität eines Inhalts darstellen.

Personalisierung darf nicht dazu führen, dass Suchmaschinen bei jedem Crawl eine andere Hauptadresse genannt bekommen.

Canonical und Cache müssen ebenfalls zusammenpassen

Eine Seite wurde von:

/alt/

auf:

/neu/

umgestellt.

WordPress gibt inzwischen das neue Canonical aus.

Ein CDN liefert aber weiterhin gecachtes HTML mit dem alten Tag.

Dann sieht Googlebot möglicherweise weiterhin:

<link rel="canonical" href=".../alt/">

Der korrekte Zustand muss deshalb auf der tatsächlich ausgelieferten öffentlichen Seite geprüft werden.

Wie immer gilt:

Nicht die Einstellung im Backend ist die Wahrheit. Die HTTP-Antwort ist es.

Canonicalisierung braucht nach Änderungen Zeit

Selbst nachdem ein Fehler behoben wurde, ändert Google die Clusterbildung nicht unbedingt unmittelbar.

Google weist in seiner aktuellen Troubleshooting-Dokumentation darauf hin, dass eine Neubewertung nach Inhaltsänderungen Zeit benötigt und Seiten unter Umständen bis zu etwa zwei Wochen in einem bisherigen Duplicate-Cluster verbleiben können. (Google for Developers)

Bei wichtigen URLs kann anschließend eine erneute Indexierung über Search Console angefragt werden.

Das ist dennoch keine Echtzeit-Umschaltung.

Nicht täglich Canonicals ändern, weil Google anders gewählt hat

Wenn Google heute eine andere URL auswählt, sollte man nicht hektisch Canonical A → B → A umstellen.

Zuerst wird die Ursache untersucht.

Sind die Inhalte wirklich identisch?

Ist die eigene gewünschte URL tatsächlich die sinnvollere?

Sind die technischen Signale eindeutig?

Stabile Architektur ist wichtiger als tägliches Reagieren auf einzelne Zustände.

Canonicalisierung sollte langfristig nachvollziehbar sein.

Wie sieht ein sauberer WordPress-Artikel aus?

Für einen normalen Casiopeya-Artikel könnte die technische Situation beispielsweise lauten:

URL:
https://casiopeya.de/wissen/caching/

Status:
200 OK

Canonical:
Was ist Caching? Website-Cache einfach verständlich erklärt


Sitemap:
Was ist Caching? Website-Cache einfach verständlich erklärt


interne Links:
Was ist Caching? Website-Cache einfach verständlich erklärt


robots:
indexierbar

Damit erzählen alle Systeme dieselbe Geschichte:

Diese URL ist der eigenständige Hauptinhalt.

Das ist die ideale Ausgangslage.

Eine Trackingvariante desselben Artikels sieht anders aus

Besucher kommt über:

https://casiopeya.de/wissen/caching/?utm_source=newsletter

Die Seite funktioniert.

Der Inhalt ist identisch.

Das Canonical lautet trotzdem:

https://casiopeya.de/wissen/caching/

Damit bleibt die Trackingfunktion bestehen, ohne eine neue bevorzugte Such-URL zu erzeugen.

Genau für solche Situationen ist Canonicalisierung hervorragend geeignet.

Wann brauche ich wahrscheinlich kein besonderes Canonical-Konzept?

Bei einer kleinen Website mit:

eindeutigen URLs,

HTTPS,

einer einzigen Domainvariante,

keinen Filterparametern,

keinen Druckversionen,

sauberen Weiterleitungen

reicht häufig ein automatisch erzeugtes selbstreferenzielles Canonical pro Seite.

Das Thema wird erst kompliziert, wenn die URL-Architektur kompliziert wird.

Canonicalisierung sollte nicht aus Spaß komplexer gemacht werden.

Große Shops brauchen deutlich mehr Planung

Bei Shops entstehen möglicherweise Millionen potenzieller Kombinationen aus:

Filter,

Sortierungen,

Farben,

Größen,

Verfügbarkeit,

Trackingparametern.

Dann muss für einzelne URL-Typen bewusst entschieden werden:

Soll diese Variante indexiert werden?

Ist sie ein echtes Duplikat?

Besitzt sie eigenständigen Suchwert?

Welches Canonical braucht sie?

Soll sie überhaupt crawlbar sein?

Die Canonical-Strategie wird damit Teil der gesamten Informations- und URL-Architektur.

Canonicalisierung kann Crawling effizienter machen

Google nennt als einen möglichen Nutzen der Canonicalisierung auch, Crawlingzeit nicht unnötig auf zahlreiche Duplikatvarianten zu verteilen. Die kanonische URL wird typischerweise häufiger gecrawlt als erkannte Duplikate. (Google for Developers)

Bei einer kleinen Website ist dieser Effekt kaum ein Grund für komplizierte Optimierungen.

Bei sehr großen Plattformen kann er dagegen relevant werden.

Wieder gilt:

Skalierung entscheidet über die Bedeutung eines technischen Problems.

Canonicalisierung kann externe Signale konsolidieren

Angenommen, fünf externe Websites verlinken auf unterschiedliche Parameter- oder URL-Varianten desselben Inhalts.

Google kann Canonicalisierung verwenden, um bestimmte Signale dieser Varianten der repräsentativen URL zuzuordnen. Google nennt genau diese Konsolidierung von Signalen als einen zentralen Vorteil der Canonicalisierung. (Google for Developers)

Das ist einer der Gründe, warum ein Canonical besser geeignet ist als einfaches noindex, wenn mehrere URLs tatsächlich Varianten desselben Inhalts darstellen.

Trotzdem ist Canonical kein magischer „Linkjuice-Transfer“

Es wäre falsch zu daraus zu folgern:

Ich setze Canonical von jeder schwachen Seite auf meine wichtigste Seite und übertrage dadurch alle Signale.

Google bildet Canonical-Gruppen auf Grundlage sehr ähnlicher beziehungsweise doppelter Inhalte. (Google for Developers)

Völlig unterschiedliche Inhalte werden nicht allein durch ein HTML-Tag plötzlich zu einer legitimen Duplicate-Gruppe.

Das technische Signal muss zur Realität der Inhalte passen.

Wann Canonical besonders sinnvoll ist

Ein Canonical ist besonders naheliegend, wenn mehrere URLs weiterhin erreichbar bleiben müssen oder dürfen, aber im Wesentlichen denselben Inhalt darstellen.

Dazu können gehören:

Trackingparameter,

bestimmte Sortiervarianten,

Druckversionen,

Dateiformatvarianten,

technisch bedingte URL-Duplikate.

Wenn eine alte URL dagegen vollständig aufgegeben wird, ist meist die Weiterleitung das klarere Instrument.

Wenn die Seite überhaupt kein Suchergebnis sein soll, ist noindex passender.

Wenn der Crawler einen Bereich nicht abrufen soll, ist robots.txt das entsprechende Werkzeug.

Vier ähnliche Probleme, vier verschiedene Lösungen

Damit können wir unsere technische SEO-Grundlage jetzt sehr klar zusammenfassen.

PROBLEM:
Crawler soll URL nicht abrufen
↓
robots.txt

PROBLEM:
Seite soll erreichbar bleiben, aber nicht in den Index
↓
noindex

PROBLEM:
Mehrere erreichbare URLs zeigen denselben Inhalt
↓
Canonical

PROBLEM:
Alte URL wurde dauerhaft durch eine neue ersetzt
↓
301-Weiterleitung

Alle vier können sich in komplexen Fällen ergänzen.

Aber sie sind nicht austauschbar.

Eine Entscheidungsmatrix für die Praxis

Angenommen, du hast zwei URLs und überlegst, was zu tun ist.

Sind beide Inhalte unabhängig und sinnvoll?

Dann braucht jede normalerweise ihr eigenes Canonical.

Sind die Inhalte im Wesentlichen identisch und beide URLs müssen bestehen bleiben?

Dann ist Canonicalisierung interessant.

Ist eine URL vollständig überflüssig und soll dauerhaft verschwinden?

Dann ist häufig eine permanente Weiterleitung sinnvoller.

Soll die Seite weiterhin für Menschen existieren, aber gar nicht über Suchmaschinen gefunden werden?

Dann ist noindex naheliegend.

Soll ein Crawler den Bereich gar nicht abrufen?

Dann betrachten wir robots.txt – allerdings nur, wenn Crawling tatsächlich das Problem ist.

So wird aus technischen SEO-Tags eine nachvollziehbare Entscheidung.

Typische Canonical-Fehler bei WordPress

Bei normalen WordPress-Websites würde ich besonders auf folgende Situationen achten:

Nach Domainumzügen zeigen Canonicals noch auf die alte Domain.

Eine Staging-URL steht weiterhin im Canonical.

HTTPS-Seiten verweisen auf HTTP.

Ein SEO-Plugin und das Theme erzeugen unterschiedliche Canonicals.

Parameterseiten kanonisieren falsch.

Archive zeigen auf einen einzelnen Beitrag.

Canonicals zeigen auf 404-Seiten.

Mehrsprachige Seiten kanonisieren sämtlich auf die deutsche Version.

Solche Fehler entstehen selten, weil jemand Canonicalisierung nicht verstanden hat.

Sie entstehen häufig durch Migration, Plugins und gewachsene technische Altlasten.

Nach einem Domainumzug gehören Canonicals auf die neue Domain

Angenommen:

alte-domain.de
↓
neue-domain.de

Nach dem Umzug sollten die Seiten auf der neuen Domain selbstverständlich nicht weiterhin enthalten:

<link rel="canonical" href="https://alte-domain.de/...">

Das würde der eigentlichen Migration widersprechen.

Die neue Website sollte sich selbst als kanonische Version nennen.

Alte URLs erhalten passende Weiterleitungen.

Sitemap und interne Links verwenden ebenfalls die neue Domain.

Damit kommunizieren sämtliche Ebenen denselben Umzug.

Search Console ist nach Migrationen besonders hilfreich

Über die URL-Prüfung lässt sich feststellen, welche Canonical-URL Google für bestimmte Seiten gewählt hat. (Google for Developers)

Wenn Wochen nach dem Domainwechsel weiterhin systematisch alte URLs als Canonical erscheinen, lohnt eine technische Untersuchung.

Dann könnte beispielsweise noch irgendwo die alte Domain in:

Canonicals,

Sitemaps,

internen Links

oder Weiterleitungen

auftauchen.

Canonical-Probleme sind häufig ein hervorragender Indikator für inkonsistente Migrationen.

Canonicals sollten vor Veröffentlichung automatisiert geprüft werden können

Bei größeren Websitebeständen lässt sich diese Kontrolle automatisieren.

Ein Crawler kann beispielsweise erfassen:

URL,

Statuscode,

Canonical-Ziel,

Indexierungsstatus,

interne Links.

Dann können Regeln auffällige Fälle finden:

Canonical zeigt auf 404

oder:

HTTPS-Seite canonicalisiert auf HTTP

oder:

Canonical zeigt auf fremde Domain

oder:

zwei verschiedene Canonical-Tags

Bei vielen Websites ist eine solche systematische Prüfung erheblich zuverlässiger als manuelles Stichprobensuchen.

Nicht jede Canonical-Abweichung muss automatisch repariert werden

Wenn Google eine andere kanonische URL auswählt als gewünscht, lohnt zuerst die Frage:

Ist Googles Auswahl vielleicht logisch?

Google empfiehlt ausdrücklich, genau das bei der Fehleranalyse zu prüfen. (Google for Developers)

Vielleicht sind zwei Seiten tatsächlich so ähnlich, dass der eigene Plan unnötig kompliziert ist.

Vielleicht ist die angeblich bevorzugte Seite schlechter oder unvollständig.

SEO-Diagnose besteht nicht darin, Google unbedingt zur eigenen ursprünglichen Entscheidung zu zwingen.

Sie beginnt mit dem Verständnis der Abweichung.

Was du dir über Canonical-Tags merken solltest

Eine kanonische URL ist die repräsentative URL, die Google aus einer Gruppe doppelter oder sehr ähnlicher Seiten auswählt. Der Prozess wird als Canonicalisierung beziehungsweise Deduplizierung bezeichnet. (Google for Developers)

Mit:

<link rel="canonical" href="https://example.de/bevorzugte-url/">

kann eine Website Google ihre bevorzugte Version mitteilen.

rel="canonical" ist ein starkes Signal, aber kein absoluter Befehl. Google kann aufgrund anderer Signale eine andere URL auswählen. (Google for Developers)

Google betrachtet aktuell insbesondere permanente Weiterleitungen und rel="canonical" als starke Canonicalisierungssignale; Sitemap-Einträge sind schwächer. Mehrere übereinstimmende Signale können gemeinsam helfen. (Google for Developers)

Interne Links sollten direkt zur bevorzugten kanonischen URL führen.

Die Sitemap sollte ebenfalls die bevorzugte URL enthalten.

Indexierbare Hauptseiten können ein selbstreferenzielles Canonical besitzen.

HTML-Canonicals gehören in den <head>.

Für Nicht-HTML-Dateien wie PDFs kann ein Canonical zusätzlich über einen HTTP-Link-Header angegeben werden. (Google for Developers)

Vor allem aber müssen vier technische Werkzeuge auseinandergehalten werden:

robots.txt
→ Crawling

noindex
→ Indexierung

canonical
→ bevorzugte URL unter mehreren Varianten

301
→ dauerhafter Umzug einer URL

Wer diese Unterscheidung verstanden hat, kann einen großen Teil typischer technischer SEO-Probleme bereits richtig einordnen.

Was bedeutet „kanonische URL“?

Duplicate Content ist innerhalb einer Website völlig normal

Warum braucht Google überhaupt eine bevorzugte URL?

Auch Messdaten werden dadurch übersichtlicher

Wie sieht ein Canonical-Tag aus?

Das Canonical kann auf dieselbe URL zeigen

Warum ist ein selbstreferenzielles Canonical nützlich?

Absolute URLs sind die sauberste Variante

Ein Canonical ist ein Signal und kein Befehl

Warum ignoriert Google manchmal mein Canonical?

Welche Canonicalisierungssignale gibt es?

Konsistenz ist wichtiger als die Menge der Signale

Interne Links sollten zur kanonischen URL führen

Interne Links sind ein eigenes Canonicalisierungssignal

Die Sitemap sollte ebenfalls nur die bevorzugte Variante enthalten

HTTP und HTTPS sind ein klassischer Canonical-Fall

www und non-www sollten ebenfalls eindeutig sein

Parameter sind einer der häufigsten Anwendungsfälle

Nicht jeder Parameter erzeugt aber ein Duplikat

Filterseiten brauchen deshalb eine Strategie

Canonical ist nicht für völlig unterschiedliche Seiten gedacht

Ein Canonical sollte auf einen tatsächlich passenden Inhalt zeigen

Canonical und 301 sind nicht dasselbe

Canonical bedeutet: Beide URLs dürfen weiterhin existieren

noindex und Canonical sind ebenfalls nicht dasselbe

noindex verwirft die Seite als Suchergebnis

robots.txt ist noch einmal etwas völlig anderes

Eine robots.txt-Sperre ist keine Canonicalisierung

Self-Canonical gehört auf normale indexierbare Seiten

WordPress erzeugt Canonicals bereits im Core

Zwei SEO-Plugins können Canonical-Konflikte erzeugen

Ein Canonical kann auch per HTTP-Header gesetzt werden

Auch PDFs können ein Canonical besitzen

PDF noindex und PDF Canonical beantworten unterschiedliche Fragen

Ein Canonical auf eine andere Domain ist technisch möglich

Syndizierte Artikel sind komplexer als „einfach Canonical setzen“

Canonical-Ketten sollte man vermeiden

Das Canonical-Ziel sollte erreichbar sein

Canonical auf eine Weiterleitung ist unnötig kompliziert

Canonical und Pagination brauchen besondere Vorsicht

Kategorien sollten nicht auf ihren wichtigsten Artikel kanonisieren

Ähnliche Themen sind nicht automatisch Duplicate Content

Canonical ist kein Mittel gegen Keyword-Kannibalisierung

Content-Konsolidierung kann dagegen Canonical oder Redirect benötigen

Canonical und hreflang müssen zusammenpassen

Nur Header und Footer übersetzen reicht dagegen nicht

JavaScript sollte das Canonical nicht unnötig verändern

Ein Canonical gehört in den head

Mehrere unterschiedliche Canonicals sind ein Warnsignal

Wie prüfe ich das Canonical einer Seite?

Bei HTTP-Canonicals müssen die Response-Header geprüft werden

Die Search Console zeigt Googles Auswahl

Google-selected Canonical kann von deiner Angabe abweichen

Was prüfe ich bei einem falschen Google-Canonical?

Ein unerwartetes externes Canonical kann ein Sicherheitsproblem sein

Serverfehlkonfiguration kann Domains miteinander vermischen

Staging-Domains können unbeabsichtigt Canonical-Probleme erzeugen

Vorschau- und Entwicklungsdomains sollten überprüft werden

Canonical ist kein Ersatz für Serverkonfiguration

Canonical darf auf sich selbst zeigen, auch wenn keine Duplikate bekannt sind

Canonical sollte nicht bei jedem Seitenaufruf wechseln

Canonical und Cache müssen ebenfalls zusammenpassen

Canonicalisierung braucht nach Änderungen Zeit

Nicht täglich Canonicals ändern, weil Google anders gewählt hat

Wie sieht ein sauberer WordPress-Artikel aus?

Eine Trackingvariante desselben Artikels sieht anders aus

Wann brauche ich wahrscheinlich kein besonderes Canonical-Konzept?

Große Shops brauchen deutlich mehr Planung

Canonicalisierung kann Crawling effizienter machen

Canonicalisierung kann externe Signale konsolidieren

Trotzdem ist Canonical kein magischer „Linkjuice-Transfer“

Wann Canonical besonders sinnvoll ist

Vier ähnliche Probleme, vier verschiedene Lösungen

Eine Entscheidungsmatrix für die Praxis

Typische Canonical-Fehler bei WordPress

Nach einem Domainumzug gehören Canonicals auf die neue Domain

Search Console ist nach Migrationen besonders hilfreich

Canonicals sollten vor Veröffentlichung automatisiert geprüft werden können

Nicht jede Canonical-Abweichung muss automatisch repariert werden

Was du dir über Canonical-Tags merken solltest