Canonicalisierung

Wie Suchmaschinen unter doppelten URLs eine kanonische URL auswählen und Ranking-Signale auf sie bündeln — warum rel=canonical ein Hinweis, keine Regel ist und wie Sie alle Signale ausrichten.

Erstveröffentlicht: 23. Juni 2026 · Zuletzt aktualisiert: 9. Aug. 2026 · Fortgeschritten
Sprachen
1 Evidenzsignal auf dieser Seite

Canonicalisierung beschreibt, wie eine Suchmaschine unter mehreren URLs mit gleichem oder nahezu gleichem Inhalt eine repräsentative URL auswählt und Ranking-Signale (Links, PageRank, Anchor-Text) auf sie bündelt. Das Wichtigste: rel=canonical ist ein Hinweis, keine Regel — Google gruppiert Duplikate und wählt anhand einer wachsenden Zahl von Signalen (~20 laut Illyes im Jahr 2020, ~40 laut Allan Scott bis 2025). Google kann das deklarierte Canonical überschreiben. Canonical ist weder eine 301 noch eine Indexierungsanweisung wie noindex. Richten Sie alle Signale auf dieselbe URL aus und prüfen Sie die Auswahl in der Search Console. Dieser Hub führt weiter zu Canonical-Tags, doppeltem Inhalt und URL-Parametern.

TL;DR — Canonicalisierung besteht aus Gruppierung, Auswahl und Bündelung: Google erkennt Duplikate (Inhaltsprüfsummen und Fingerprints), gruppiert sie, wählt eine kanonische URL und bündelt Ranking-Signale (Links, PageRank, Anchor-Text) auf ihr. rel="canonical" ist ein starker Hinweis, keine Anweisung — Google kann ihn überschreiben und zeigt das in der GSC als „Duplicate, Google chose different canonical than user.“ Google gewichtet eine wachsende Zahl von Signalen (~20 laut Illyes im Jahr 2020, ~40 laut Googles Allan Scott bis 2025): die rel=canonical-Angabe, Weiterleitungen, Sitemap-Aufnahme, interne Links, HTTPS gegenüber HTTP und kürzere gegenüber längeren URLs — wobei manche andere überwiegen (eine Weiterleitung schlägt das HTTPS-Signal). Canonical ist keine 301-Weiterleitung und keine Indexierungsanweisung wie noindex. Lassen Sie jedes Signal auf eine URL zeigen, verwenden Sie selbstreferenzierende Canonicals und prüfen Sie die ausgewählte kanonische URL in der URL-Prüfung der Search Console.

Was Canonicalisierung tatsächlich bedeutet

Canonicalization sits between duplicate URLs and the index — deciding which one URL represents the group. Quelle: /technical-seo/how-search-works/indexing/canonicalization/

Three reachable duplicate URL variants feed a canonicalization decision. A separate bundle of signals also feeds the decision: rel=canonical, redirects, sitemap inclusion, internal links, and HTTPS. The decision selects one representative canonical URL, which may be indexed and shown in search while cluster signals consolidate onto it. The other duplicate URLs remain reachable rather than being deleted.

© Patrick Stox LLC · CC BY 4.0 ·

Googles Definition ist präzise: “Canonicalization is the process of selecting the representative –canonical– URL of a piece of content,” (Übersetzung) „Canonicalisierung ist der Prozess, die repräsentative –kanonische– URL eines Inhalts auszuwählen.“ und “a canonical URL is the URL of a page that Google chose as the most representative from a set of duplicate pages.” (Übersetzung) „Eine kanonische URL ist die URL einer Seite, die Google aus einer Gruppe doppelter Seiten als repräsentativste ausgewählt hat.“ Evidence for this claim Google groups similar pages and selects a representative canonical URL for the cluster. Scope: Google Search canonical selection for duplicate or very similar content. Confidence: high · Verified: Google Search Central: In-depth guide to how Google Search works Ich habe Ahrefs’ canonicalization guide geschrieben. Dort fasse ich es als zwei getrennte Aufgaben: “Clustering creates a cluster of duplicate pages, and canonicalization chooses which version signals consolidate to and what page will be shown in search results.” (Übersetzung) „Beim Clustering wird eine Gruppe doppelter Seiten gebildet, und bei der Canonicalisierung wird entschieden, auf welche Version die Signale gebündelt werden und welche Seite in den Suchergebnissen angezeigt wird.“

Drei Dinge geschehen also in dieser Reihenfolge:

  1. Duplikate erkennen und gruppieren — doppelte und nahezu doppelte URLs.
  2. Eine auswählen — eine URL wird zur kanonischen.
  3. Ranking-Signale bündeln — auf der ausgewählten URL.

Wenn diese drei Schritte klar sind, verschwindet der größte Teil der Verwirrung um Canonicalisierung.

Warum das wichtig ist

Google sagt offen, dass Duplikate hauptsächlich ein Problem für Nutzerfreundlichkeit und Berichte sind, kein moralisches Versagen: “having the same content accessible through many different URLs can be a bad user experience… and it may make it harder for you to track how your content performs in search results.” (Übersetzung) „Derselbe Inhalt, der über viele verschiedene URLs erreichbar ist, kann eine schlechte Nutzererfahrung sein … und es kann für Sie schwieriger werden, nachzuverfolgen, wie Ihre Inhalte in den Suchergebnissen abschneiden.“ Die meisten Duplikate sind nicht bösartig, sondern gewöhnliche technische Nebenwirkungen (Parameter, facettierte Navigation, Protokoll-/Host-Varianten, Sitzungs-IDs).

Der eigentliche Nutzen zeigt sich auf vier Ebenen. Bei jeder lohnt Präzision, statt „Canonicalisierung hilft SEO“ als einen vagen Vorteil zu behandeln:

  • Zugehörigkeit zur Gruppe. Doppelte URLs werden zu einer Gruppe zusammengefasst; die kanonische URL ist die festgelegte Repräsentantin dieser Gruppe.
  • Relative Crawl-Häufigkeit. Google sagt, dass die kanonische Seite am regelmäßigsten gecrawlt wird und Duplikate seltener — ein relativer Effekt, der redundantes Crawling reduziert. Das verspricht nicht, dass eine Canonicalisierung sofort an anderer Stelle Budget freigibt oder die Indexierung unabhängiger Seiten beschleunigt.
  • Bewertung von Inhalt und Qualität. Google verwendet die kanonische URL normalerweise als Hauptquelle für die Bewertung von Qualität und Relevanz.
  • Auslieferung. Suchergebnisse verlinken gewöhnlich auf die kanonische URL — aber nicht immer. Google kann ein Duplikat ausliefern, wenn es für den Nutzer besser geeignet ist, etwa eine gerätespezifische Version.

Googles Dokumentation beschreibt die Signalseite klar: Das Festlegen einer kanonischen URL “helps search engines to be able to consolidate the signals they have for the individual URLs (such as links to them) into a single, preferred URL.” (Übersetzung) „hilft Suchmaschinen, die Signale für die einzelnen URLs (z. B. Links auf diese URLs) in einer einzigen bevorzugten URL zu bündeln.“ Das gilt nur, wenn das Ziel tatsächlich kanonisch wird — es garantiert nicht, dass jedes deklarierte Canonical automatisch den gesamten PageRank, Anchor-Text oder Ranking-Wert eines Duplikats übernimmt. Widersprechen sich Ihre Signale und wählt Google etwas anderes, wird nichts so gebündelt, wie Sie es beabsichtigt haben.

Ein gewisses Maß an Duplizierung ist außerdem normal und für sich genommen kein Verstoß gegen die Spam-Richtlinien. Die praktischen Gründe für Canonicalisierung sind Klarheit für Nutzer, sauberere Berichte, eine konsistente Search-URL, die Bündelung von Signalen und weniger doppeltes Crawling — nicht die Angst vor einer Strafe. Unkontrollierte Duplizierung sollte trotzdem an der Quelle behoben werden: Das ist eher eine Frage von crawl budget und facettierter Navigation als von Canonicalisierung, hängt aber mit ihr zusammen.

Wie Google eine kanonische URL auswählt

Canonicalization is three jobs, not one: cluster, select, consolidate. Quelle: /technical-seo/how-search-works/indexing/canonicalization/

Step one fingerprints duplicate URLs and groups them into a cluster. Step two selects one URL as canonical while the others remain reachable alternates. Step three consolidates links, PageRank, and anchor text from the cluster onto the selected canonical.

© Patrick Stox LLC · CC BY 4.0 ·

Das ist der Teil, den die meisten Ratgeber übergehen — deshalb lohnt es sich, ihn sauber zu erklären.

Schritt 1 — Duplikate erkennen

Google erstellt Fingerprints von Seiteninhalten, um Duplikate zu finden. Gary Illyes beschrieb den Mechanismus in Search Off the Record: “A checksum is basically a hash of the content. Basically a fingerprint.” (Übersetzung) „Eine Prüfsumme ist im Grunde ein Hash des Inhalts. Im Grunde ein Fingerabdruck.“ Seiten mit gleichen oder nahezu gleichen Fingerprints (Boilerplate wie Navigation und Footer wird weitgehend abgewertet) kommen als Duplikate infrage.

Googles aktuelle Dokumentation beschreibt dieselbe Idee einfacher, ohne die Prüfsummen-Mechanik: Beim Indexieren vergleicht Google den Hauptinhalt jeder Seite und gruppiert Seiten, die gleich oder sehr ähnlich sind. Google veröffentlicht weder genau, wie das Fingerprinting funktioniert, noch wie stark Boilerplate abgewertet wird. Behandeln Sie Illyes’ Prüfsummen-Erklärung daher als richtungsweisende Einordnung aus einem Gespräch von 2020, nicht als dokumentierten Algorithmus.

Schritt 2 — Gruppieren

Die doppelten URLs werden zu einer Gruppe zusammengefasst. Jede URL in der Gruppe kann kanonisch werden; genau eine gewinnt.

Schritt 3 — Auswahl aus der Gruppe

Jetzt wählt Google. Dafür werden mehrere Signale verwendet, und die veröffentlichte Zahl ist mit der Zeit gewachsen. 2020 sagte Illyes: “we employ, I think, over twenty signals, we use over twenty signals, to decide which page to pick as canonical.” (Übersetzung) „Wir verwenden, glaube ich, mehr als zwanzig Signale; wir nutzen mehr als zwanzig Signale, um zu entscheiden, welche Seite als kanonisch ausgewählt wird.“ 2025 war die Zahl, über die Google spricht, höher: Wie ich in meinem canonicalization guide notiert habe: “According to Google’s Allan Scott, there are ~40 different canonical selection signals.” (Übersetzung) „Laut Googles Allan Scott gibt es etwa 40 verschiedene Signale für die Auswahl der kanonischen Seite.“ Verstehen Sie das als öffentliche Aussage über mehr Signale im Lauf der Zeit — 20+ im Jahr 2020, ~40 bis 2025 — nicht als Widerspruch.

Googles eigene Dokumentation nennt ausdrücklich einige Faktoren: “There are a handful of factors that play a role in canonicalization: whether the page is served over HTTP or HTTPS, redirects, presence of the URL in a sitemap, and rel="canonical" link annotations.” (Übersetzung) „Es gibt eine Handvoll Faktoren, die bei der Canonicalisierung eine Rolle spielen: ob die Seite über HTTP oder HTTPS ausgeliefert wird, Weiterleitungen, das Vorhandensein der URL in einer Sitemap und Link-Annotationen für rel=canonical.“ (Übersetzung) „Es gibt eine Handvoll Faktoren, die bei der Canonicalisierung eine Rolle spielen: ob die Seite über HTTP oder HTTPS ausgeliefert wird, Weiterleitungen, das Vorhandensein der URL in einer Sitemap und Link-Annotationen für rel=canonical.“ Meine ausführlichere Liste ergänzt die häufig genannten Faktoren: Duplikate, Canonical-Link-Elemente, Sitemap-URLs, interne und externe Links, Weiterleitungen, hreflang, x-default hreflang, PageRank, HTTPS-Seiten gegenüber HTTP und kürzere URLs gegenüber längeren.

Welche Signale überwiegen andere?

Sie sind nicht gleich stark. Illyes sagte ausdrücklich, eine “301 redirect, or any sort of redirect actually, should be much higher weight… than whether the page is on an http URL or https.” (Übersetzung) „Eine 301-Weiterleitung oder jede Art von Weiterleitung sollte tatsächlich deutlich stärker gewichtet werden als die Frage, ob die Seite über eine HTTP- oder HTTPS-URL erreichbar ist.“ Den Canonical-Tag nannte er selbst ein “quite a strong signal” (Übersetzung) „ein ziemlich starkes Signal“ — stark, aber überstimmbar. Wie ich es in meinem canonicalization guide formuliere: Der Canonical-Tag “is sometimes referred to as a hint because it’s just one canonicalization signal, but it is considered a strong signal. Google ignores it if other signals are stronger.” (Übersetzung) „wird manchmal als Hinweis bezeichnet, weil es nur ein Canonicalisierungs-Signal ist, gilt aber als starkes Signal. Google ignoriert es, wenn andere Signale stärker sind.“

Warum es ein Hinweis und keine Anweisung ist

Das ist der sachliche Kern des gesamten Themas. Google sagt: “You can indicate your preference to Google using these techniques, but Google may choose a different page as canonical than you do, for various reasons. That is, indicating a canonical preference is a hint, not a rule.” (Übersetzung) „Sie können Google mit diesen Techniken Ihre Präferenz mitteilen, aber Google kann aus verschiedenen Gründen eine andere Seite als kanonisch auswählen. Das heißt: Eine Canonical-Präferenz ist ein Hinweis, keine Regel.“ Evidence for this claim Canonical declarations express a preference; Google can select a different canonical based on its signals. Scope: Google Search canonicalization; redirects and rel=canonical are strong signals while sitemap inclusion is weaker. Confidence: high · Verified: Google Search Central: How to specify a canonical URL Verliert Ihr deklarierter Canonical, sehen Sie in der Search Console “Duplicate, Google chose different canonical than user” (Übersetzung) „Duplikat: Google hat ein anderes Canonical als der Nutzer ausgewählt“ — das bedeutet, wie ich es beschreibe, “means that Google chose a different URL to index than the one the user selected.” (Übersetzung) „Das bedeutet, dass Google eine andere URL indexiert hat als die vom Nutzer ausgewählte.“ Die Lösung ist fast nie “add a stronger tag” (Übersetzung) „einen stärkeren Tag hinzufügen“, sondern die widersprüchlichen Signale auszurichten.

Wege, eine kanonische URL anzugeben

Google stellt voran: “none of them are required; your site will likely do just fine without specifying a canonical preference,” (Übersetzung) „Keine dieser Methoden ist erforderlich; Ihre Website wird wahrscheinlich auch ohne Angabe einer Canonical-Präferenz gut funktionieren.“ in der Praxis sollten Sie aber bewusst entscheiden. Googles aktuelle Dokumentation weist außerdem darauf hin, dass sich diese Methoden verstärken können — mehrere starke, übereinstimmende Signale erhöhen die Wahrscheinlichkeit der gewünschten Auswahl, aber keine einzelne Methode garantiert sie. Die wichtigsten Methoden sind:

  • rel="canonical"-Link-Element — die Zeile im <head>. Die häufigste Methode; Google nennt sie “a strong signal that the specified URL should become canonical.” (Übersetzung) „ein starkes Signal dafür, dass die angegebene URL kanonisch werden sollte.“ Sie muss im <head> stehen — ein nicht geschlossener Tag oder JavaScript, das die Angabe in den <body> verschiebt, führt dazu, dass Google sie ignoriert. Pro Seite nur eine deklarieren; bei mehr als einer ignoriert Google alle.
  • HTTP-Header rel="canonical" — für Nicht-HTML-Dateien wie PDFs, die keinen <head> für einen Tag haben; setzen Sie das Canonical im HTTP-Antwort-Header.
  • Weiterleitungen“a strong signal that the target of the redirect should become canonical.” (Übersetzung) „ein starkes Signal dafür, dass das Ziel der Weiterleitung kanonisch werden sollte.“ Verwenden Sie eine 301, wenn Sie Inhalt tatsächlich verschieben.
  • Sitemap-Aufnahme“a weak signal that helps the URLs that are included in a sitemap become canonical.” (Übersetzung) „ein schwaches Signal, das den in einer Sitemap enthaltenen URLs hilft, kanonisch zu werden.“ Nehmen Sie nur kanonische URLs in die Sitemap auf.
  • Interne Links — verlinken Sie konsistent auf die gewünschte Version. Uneinheitliche interne Verlinkung ist ein häufiger Grund für widersprüchliche Signale.

Selbstreferenzierende und Cross-Domain-Canonicals

Ein selbstreferenzierendes Canonical — eine indexierbare Seite, deren Canonical auf sie selbst zeigt — ist auf jeder Seite, die Sie indexieren lassen möchten, Best Practice. Es macht Ihre Präferenz auch bei anderen mehrdeutigen Signalen eindeutig und neutralisiert parametrische Kopien, die sonst wie Duplikate aussehen würden.

Cross-Domain-Canonicals werden unterstützt: Sie können das Canonical einer Seite auf eine URL einer anderen Domain zeigen lassen, die Sie kontrollieren, um Inhalte zu bündeln (häufig bei Syndizierung). Das zu beachtende Fehlerszenario ist Hijacking — wie ich in meinem canonicalization guide warne: “In some really bad scenarios, a page on the wrong domain may be shown. This is referred to as hijacking.” (Übersetzung) „In einigen wirklich problematischen Szenarien kann eine Seite auf der falschen Domain angezeigt werden. Das wird als Hijacking bezeichnet.“ Das ist selten, aber genau deshalb verdienen Cross-Domain-Canonicals besondere Sorgfalt.

Sonderfälle: Was gilt tatsächlich als Duplikat?

Fünf Situationen werden häufiger als andere fälschlich als „Duplikat“ behandelt. Das Muster ist immer gleich: Entscheiden Sie nicht nach einem URL-Merkmal (einem ?, einer Seitenzahl, einem Sprachordner oder einem Script-Tag), sondern nach dem tatsächlich gerenderten Hauptinhalt.

SituationAls Duplikat behandeln?Warum
Tracking- oder Sitzungsparameter (?utm_source=, ?sessionid=)Meist jaDerselbe Hauptinhalt — die Bereinigung auf die saubere URL ist normalerweise sicher.
Filter-, Sortier- oder Facettenparameter (?color=red, ?sort=price)Nicht automatischSie können sich in Inhalt oder Suchabsicht wesentlich von der Basis-Seite unterscheiden — prüfen Sie den gerenderten Inhalt, bevor Sie die Seite weg-canonicalisieren.
Paginierte Seiten (/page/2/)NeinGoogle behandelt jede Seite einer Reihe als eigenständig mit eigenem Hauptinhalt — geben Sie jeder eine eindeutige URL und ein selbstreferenzierendes Canonical, niemals ein Canonical auf Seite 1.
Vollständig übersetzte SeitenNeinAnderssprachiger Inhalt ist trotz gleicher Vorlage kein Duplikat des Originals — verknüpfen Sie ihn mit hreflang, nicht mit Canonical.
Regionale Varianten in derselben Sprache (z. B. nahezu identische en-US- und en-GB-Seiten)ManchmalSie können wie gewöhnliche Duplikate gruppiert werden. Halten Sie die Canonical-Präferenz in derselben Sprache und nutzen Sie dazu reziprokes hreflang, damit die passende regionale URL weiterhin ausgespielt werden kann.

Zwei Implementierungsdetails verursachen so häufig stille Fehler, dass sie einen eigenen Hinweis verdienen:

  • JavaScript-gerenderte Canonicals. Googles Empfehlung lautet, eine eindeutige Quelle für den Wert zu wählen: Setzen Sie ihn in das initiale HTML und überschreiben Sie ihn nicht mit JavaScript — oder lassen Sie ihn, falls das nicht möglich ist, aus dem HTML weg und setzen Sie ihn ausschließlich per JavaScript. Ein Canonical im Quelltext, das anschließend per Script geändert wird, ist der eigentliche Fehler: Google erhält von einer Seite zwei widersprüchliche Signale.
  • Nicht-HTML-Dateien. Der HTTP-Header rel="canonical" (für PDFs, Word-Dokumente und Ähnliches) wird speziell für Googles Web-Suchergebnisse unterstützt — er ist kein universelles Signal für jede Google-Oberfläche. Verwenden Sie eine absolute URL und lassen Sie die Metadaten der Datei kein widersprüchliches Canonical deklarieren.

So prüfen Sie, welche kanonische URL Google ausgewählt hat

Nehmen Sie nicht an, dass Ihr HTML die maßgebliche Quelle ist — maßgeblich ist Googles Auswahl. Wie ich sage: “Your main source of truth for what Google chose as the canonical will be the URL Inspection tool in Google Search Console. Enter the URL, and it will show what the declared canonical is and what Google chose as the canonical.” (Übersetzung) „Ihre wichtigste Quelle dafür, welche Canonical-URL Google ausgewählt hat, ist das URL-Prüfungstool in der Google Search Console. Geben Sie die URL ein; dort sehen Sie, welches Canonical Sie deklariert haben und welches Google ausgewählt hat.“ Stimmen die beiden nicht überein, ist das Ihr Signal, alle Vorgaben aufeinander abzustimmen.

Einige Grenzen sollten Sie kennen, bevor Sie dieses Feld als unumstößliche Wahrheit behandeln:

  • Es zeigt den indexierten Zustand, keine Live-Prüfung. Das von Google ausgewählte Canonical in der URL-Prüfung stammt aus dem, was Google bereits indexiert hat. Der Live-Test desselben Tools kann aktuelle Signale zeigen, aber nicht vorhersagen, was Google auswählen wird — behandeln Sie das indexierte Feld als historisch, nicht als Echtzeitwert.
  • Die Sichtbarkeit ist auf Ihre Properties begrenzt. Sie sehen Canonical-Informationen nur für URLs innerhalb von Search-Console-Properties, auf die Sie Zugriff haben, nicht für beliebige Seiten Dritter.
  • Ein Audit-Tool beobachtet Eingaben, nicht Googles Entscheidung. Ein Tool wie der oben genannte Canonicalization Checker zeigt die von Ihnen gesendeten HTML-, Header- und Weiterleitungssignale. Es kann nicht sagen, was Google tatsächlich ausgewählt hat; das kann nur die URL-Prüfung.
  • Keine Garantie für Aufnahme, Zeitplan oder Ranking. Dass Ihre gewünschte URL als Canonical ausgewählt wurde, garantiert weder die Indexierung noch einen festen Zeitpunkt noch Traffic oder Rankings — Canonicalisierung entscheidet über die Repräsentation, nicht über diese Ergebnisse.

Häufige Fehler bei der Canonicalisierung

Die wiederkehrenden Fehler, mehrere davon aus meiner eigenen Liste typischer Fehler:

  • Ein Produktions-Canonical als Schutz für eine Staging-Website. Eine Staging-Seite unter https://staging.example.com/pricing/ kann ihr Canonical auf https://example.com/pricing/ setzen und trotzdem gecrawlt, gruppiert oder sogar angezeigt werden, während Google die Signale abgleicht. Das Canonical sagt, welches Duplikat Sie bevorzugen; es macht die Staging-URL nicht privat und weist Google nicht an, sie zu entfernen. Ist der Staging-Host in die Suche gelangt, halten Sie ihn mit noindex crawlbar, bis Google die Anweisung verarbeitet, oder leiten Sie ihn weiter, wenn es einen dauerhaften Ersatz in der Produktion gibt. Für eine Umgebung, die niemals öffentlich sein soll, ist Authentifizierung erforderlich.
  • Auf eine Nicht-Duplikat-URL canonicalisieren. Das Canonical einer Seite auf eine unabhängige Seite zu zeigen, teilt Google mit, dass beide denselben Inhalt haben; Google kann das „Duplikat“ aus den Ergebnissen entfernen. Canonicals sind für echte Duplikate gedacht.
  • Canonical + noindex auf derselben URL. Widersprüchliche Anweisungen. John Muellers Hinweis zur Kombination widersprüchlicher Signale lautet: “I’d just pick one (noindex or followed links). Links on a noindexed page can be picked up, but it’s not guaranteed.” (Übersetzung) „Ich würde einfach eines wählen (noindex oder gefolgte Links). Links auf einer noindexierten Seite können aufgegriffen werden, aber das ist nicht garantiert.“ Entscheiden Sie sich für eine Option.
  • Die canonicalisierte URL in robots.txt blockieren. Google sagt: “Don’t use the robots.txt file for canonicalization purposes. Google may still index URLs that are disallowed in robots.txt without their content.” (Übersetzung) „Verwenden Sie die robots.txt nicht für Canonicalisierungszwecke. Google kann URLs, die in der robots.txt nicht erlaubt sind, trotzdem ohne ihren Inhalt indexieren.“ Eine blockierte Seite kann nicht einmal gelesen werden, um ihren Canonical-Tag zu sehen.
  • Für die canonicalisierte URL einen 4XX-Status zurückgeben — wenn das Duplikat fehlschlägt, bricht die Bündelung zusammen.
  • Alle paginierten Seiten auf Seite 1 canonicalisieren. Jede Seite einer Reihe enthält eigenständigen Inhalt; fassen Sie die Reihe nicht auf der Startseite zusammen.
  • Canonical-Ketten oder widersprüchliche Weiterleitungen — ein Canonical, das auf eine URL zeigt, die anschließend weiterleitet, zwingt Google, einen Widerspruch aufzulösen. Zeigen Sie das Canonical direkt auf das endgültige Ziel.
  • Mehrere Canonicals oder ein Canonical im <body> — die Platzierung im Body wird nicht akzeptiert; mehrere Angaben sind ein Konflikt ohne verlässliche First-/Last-Regel.

Mythen, widerlegt

  • “A canonical tag guarantees which URL ranks/indexes.” (Übersetzung) „Ein Canonical-Tag garantiert, welche URL rankt oder indexiert wird.“ Nein — es ist ein Hinweis; Google kann eine andere auswählen (genau das meldet der GSC-Status “Duplicate, Google chose different canonical than user” (Übersetzung) „Duplikat: Google hat ein anderes Canonical als der Nutzer ausgewählt“).
  • “rel=canonical is the same as a 301 redirect.” (Übersetzung) „rel=canonical ist dasselbe wie eine 301-Weiterleitung.“ Nein. Eine 301 ist die Anweisung zum Verschieben einer Seite; ein Canonical ist ein Hinweis zur Bündelung, und beide URLs bleiben erreichbar. Bings langjährige Position ist, dass beim Verschieben von Inhalten eine 301 statt eines Canonicals verwendet werden sollte, weil die Weiterleitung die eindeutige Anweisung ist. Beim Ausmustern einer URL richten Sie eine Weiterleitung ein.
  • “A canonical blocks or passes indexing like noindex.” (Übersetzung) „Ein Canonical blockiert oder erlaubt die Indexierung wie noindex.“ Nein — Canonical ist überhaupt keine Indexierungsanweisung. Die Kombination mit noindex sendet widersprüchliche Signale; verwenden Sie nur eine Option.
  • “More canonical tags = a stronger signal.” (Übersetzung) „Mehr Canonical-Tags ergeben ein stärkeres Signal.“ Das Gegenteil: Deklarieren Sie mehr als einen, ignoriert Google alle.

Bing und andere Suchmaschinen

Bing verwendet dieselben Grundbausteine. In Bings Darstellung vom Dezember 2025 heißt es: “Duplicate content doesn’t trigger search penalties on its own, but it does reduce visibility by diluting authority, confusing intent, and slowing how updates reach both search engines and AI-powered discovery systems,” (Übersetzung) „Doppelte Inhalte lösen für sich genommen keine Suchstrafen aus, verringern aber die Sichtbarkeit, weil sie Autorität verwässern, die Suchintention verwirren und die Aktualisierung sowohl für Suchmaschinen als auch für KI-gestützte Entdeckungssysteme verlangsamen.“ und: “Canonical tags, redirects, hreflang, noindex, and IndexNow all support this clarity, but the foundation is a streamlined site that avoids unnecessary duplication.” (Übersetzung) „Canonical-Tags, Weiterleitungen, hreflang, noindex und IndexNow unterstützen diese Klarheit, aber die Grundlage ist eine schlanke Website, die unnötige Duplikate vermeidet.“ Bing bietet außerdem in den Bing Webmaster Tools die Funktion URL Normalization, mit der sich Parameter-Varianten ohne Codeänderung zusammenfassen lassen — praktisch, wenn die Duplikate durch URL-Parameter entstehen.

Wie es weitergeht

Diese Seite ist der konzeptionelle Knotenpunkt für Canonicalisierung und das übergeordnete Thema. Sie gehört zur umfassenderen Phase Indexierung beim Verständnis der Suche (Canonicalisierung entscheidet, welche URL aus einer Duplikatgruppe tatsächlich indexiert wird). Die drei vertiefenden Seiten gehen jeweils einen Teil weiter:

  • Canonical-Tags (rel=canonical) — der Tag selbst: exakte Syntax, Implementierung in <head> gegenüber HTTP-Header, selbstreferenzierende Muster und alle Fälle, in denen er ignoriert wird.
  • Doppelter Inhalt — was tatsächlich als Duplikat gilt, warum es keine Strafe ist und wie Sie Duplikate an der Quelle verhindern, statt sie mit Tags zu kaschieren.
  • URL-Parameter — der größte Erzeuger von Duplikaten: Tracking-, Sortier-, Filter- und Sitzungsparameter und wie Sie verhindern, dass sie eine Seite über endlose Varianten aufsplitten.

Canonicalisierung berührt auch die Nachbarthemen in diesem Cluster: Duplikate und ausufernde Parameter verschwenden genau das crawl budget, facettierte Navigation ist eine wichtige Quelle nahezu doppelter URLs, und Spider Traps können unendliche URL-Räume erzeugen, in denen die Duplizierung explodiert. Für die gesamte Pipeline — Entdeckung, Crawling, Rendering, Indexierung und Auslieferung — siehe den How Search Works cluster.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.