Inhaltsverzeichnis
- Warum sollte jede Seite über ein Canonical verfügen?
- Wogegen ein Canonical hilft: Duplicate Content durch Mehrfach-URLs
- Wie eine Suchmaschine die kanonische URL wählt
- Das Canonical Tag richtig setzen
- Das richtige Werkzeug im Index-Management
- Wo das Canonical Tag mit anderen Signalen kollidiert
- Der Praxisfall: Parameter- und Filterseiten
- Wenn die Suchmaschine dem Canonical nicht folgt
- Fragen, die beim Canonical immer wieder aufkommen
- Unterstützung bei Kanonisierung und Index-Management
- Weiterführende Themen zur Kanonisierung
Canonical (engl. Canonical URL; kanonische URL)
Warum sollte jede Seite über ein Canonical verfügen?
Im Sprachgebrauch meint „Canonical" zwei Dinge, die man sauber auseinanderhalten sollte. Das Canonical Tag ist das Link-Element <link rel="canonical"> im Quelltext eines Dokuments. Die Canonical URL ist der Wert darin: die Adresse, die als bevorzugte, repräsentative Version eines Inhalts deklariert wird. Das Tag ist der Träger, die URL die Aussage.
Ist derselbe oder ein sehr ähnlicher Inhalt unter mehreren URLs erreichbar, bündelt ein Canonical Tag die Signale auf eine dieser URLs. Ein Canonical ist dabei ein Hinweis, keine Anweisung. Eine Suchmaschine nimmt ihn als starkes Signal, kann im Zweifel aber eine andere URL als repräsentativ wählen. Ein Canonical wirkt außerdem immer auf Ebene der einzelnen URL, nicht auf Ebene der ganzen Website. Damit ist das Canonical Tag ein zentrales Werkzeug gegen Duplicate Content und ein Baustein des technischen SEO.
Wogegen ein Canonical hilft: Duplicate Content durch Mehrfach-URLs
Der klassische Anlass für ein Canonical ist ein technisch nicht sauber konfigurierter Auftritt, der denselben Inhalt unter mehreren Adressen ausliefert: mit und ohne www, über http und https, mit und ohne abschließenden Schrägstrich, mit angehängten Sitzungs- oder Sortierparametern. Für die Nutzer ist das dieselbe Seite. Für eine Suchmaschine sind es verschiedene URLs mit identischem Inhalt, also Duplicate Content.
Ohne klare Kennzeichnung muss die Suchmaschine selbst entscheiden, welche dieser URLs in den Suchmaschinenindex kommt. Das hat drei unerwünschte Folgen:
- Ranking-Signale wie eingehende Links verteilen sich auf mehrere URLs, statt sich auf eine zu bündeln;
- die Suchmaschine verbraucht Crawl-Ressourcen für redundante URLs, die dann für wichtige Seiten fehlen;
- in den Suchergebnissen erscheint womöglich eine andere URL als die gewünschte.
Ein Canonical Tag benennt die bevorzugte URL und lenkt die Indexierung auf diese Version. Wichtig zur Einordnung: Bei echten www/http-Varianten ist eine serverseitige Weiterleitung per Statuscode 301 das sauberere Mittel, weil sie die Dubletten gar nicht erst erreichbar lässt. Das Canonical Tag ist die richtige Wahl, wenn die einzelnen URLs bewusst erreichbar bleiben sollen, ihre Signale aber auf einer Version zusammenlaufen sollen.
Wie eine Suchmaschine die kanonische URL wählt
Das Canonical Tag ist nur eines von mehreren Signalen, und Suchmaschinen gewichten diese Signale unterschiedlich. Findet die Suchmaschine mehrere sehr ähnliche URLs, fasst sie diese zu einem Cluster zusammen und wählt die Version, die für Nutzer objektiv am vollständigsten und nützlichsten ist. In diese Auswahl fließen mehrere Signale mit unterschiedlichem Gewicht ein. Google dokumentiert dabei:
- Weiterleitungen (etwa ein Statuscode 301) gelten als starker Hinweis.
- Das Canonical Tag (
rel="canonical") ist ebenfalls ein starker Hinweis. - Der Eintrag in der Sitemap zählt als schwacher Hinweis.
Zusätzlich bevorzugt die Suchmaschine https gegenüber http, und die interne Verlinkung wirkt mit: Wer konsequent auf die Canonical URL verlinkt statt auf eine Dublette, verstärkt seine Präferenz. Entscheidend ist die Widerspruchsfreiheit. Ein Canonical wirkt nur zuverlässig, wenn alle übrigen Signale dieselbe URL stützen. Zeigen interne Links, Sitemap oder Weiterleitungen auf eine andere URL als das Canonical Tag, löst die Suchmaschine den Konflikt nach eigenem Ermessen auf, und das Ergebnis muss nicht die gewünschte Version sein.
Das Canonical Tag richtig setzen
Der häufigste Weg ist das Link-Element im <head> eines HTML-Dokuments:
<link rel="canonical" href="https://www.beispiel.de/bevorzugte-seite">
Für Inhalte ohne HTML-Kopf, etwa PDF-Dateien, lässt sich derselbe Hinweis über den HTTP-Header senden:
Link: <https://www.beispiel.de/bevorzugte-seite>; rel="canonical"
Empfohlen ist das selbstreferenzierende Canonical Tag: Jede URL verweist auf sich selbst als kanonische Version. Das legt die bevorzugte Adresse eindeutig fest und fängt automatisch angehängte Parameter ab. Beim Setzen gelten einige harte technische Regeln, an denen Kanonisierungen sonst still scheitern:
- Nur ein Canonical Tag pro URL. Findet die Suchmaschine mehrere
rel="canonical"-Angaben, ignoriert sie alle. - Nur im
<head>. Einrel="canonical"im<body>wird verworfen. Das ist besonders bei per JavaScript nachgeladenen Canonical Tags relevant: Die Angabe muss im gerenderten<head>landen. - Absolute Canonical URLs verwenden und nie auf eine weitergeleitete, per Noindex ausgeschlossene oder per robots.txt gesperrte Adresse zeigen, sonst läuft das Signal ins Leere.
- Damit die Suchmaschine folgt, brauchen Dublette und Ziel eine deutliche inhaltliche Überschneidung. Ein Canonical Tag auf einen völlig anderen Inhalt wird ignoriert.
Das richtige Werkzeug im Index-Management
Ein häufiges Missverständnis wirft das Canonical Tag mit verwandten Werkzeugen in einen Topf. Sie lösen aber unterschiedliche Probleme, und für ein Ziel sollte man sich für genau eines entscheiden:
| Situation | Werkzeug | Wirkung |
|---|---|---|
| Inhalt bleibt erreichbar, Signale sollen auf einer URL gebündelt werden | Canonical Tag | Bündelt Signale, alle Varianten bleiben abrufbar |
| URL zieht dauerhaft um, alte Adresse soll niemanden mehr erreichen | Weiterleitung (Statuscode 301) | Führt Nutzer und Suchmaschine auf die neue URL |
| URL bleibt erreichbar, soll aber aus dem Index verschwinden | Noindex | Nimmt die einzelne URL aus dem Index |
| Ein ganzer Bereich soll gar nicht erst gecrawlt werden | Sperre in der robots.txt | Verhindert das Crawling, nicht zwingend die Indexierung |
Wo das Canonical Tag mit anderen Signalen kollidiert
Fehler im Index-Management entstehen selten an einem einzelnen Tag, sondern fast immer dort, wo sich Signale widersprechen. Drei Kollisionen sieht man in der Praxis immer wieder.
Canonical und Noindex auf derselben URL. Beide zusammen senden gegensätzliche Signale. Ein Noindex blockiert die URL vollständig aus der Suche, statt ihre Signale zu bündeln; um innerhalb einer Website die bevorzugte Version zu bestimmen, ist das Canonical Tag das vorgesehene Mittel. Beides zu kombinieren ist kein Feintuning, sondern ein Widerspruch, den die Suchmaschine irgendwie auflösen muss.
Canonical und hreflang bei mehrsprachigen Inhalten. Hier passiert ein besonders teurer Fehler. Bei Sprachversionen muss jede URL ein selbstreferenzierendes Canonical Tag auf sich in der eigenen Sprache tragen; die Verknüpfung der Sprachversionen übernimmt allein hreflang. Verschiedensprachige Versionen sind für die Suchmaschine ohnehin keine Duplikate, solange der Hauptinhalt übersetzt ist — ein sprachübergreifendes Canonical wäre also nicht bloß riskant, sondern grundfalsch: Es bricht den hreflang-Cluster, und die Suchmaschine wählt womöglich die falsche Sprachversion für den jeweiligen Markt. Ebenfalls wichtig: hreflang-, lang-, media- oder type-Attribute gehören nicht in das Canonical Tag selbst, sie werden für die Kanonisierung nicht ausgewertet.
Canonical und XML-Sitemap. In eine XML-Sitemap gehören ausschließlich Canonical-URLs. Trägt man dort auch die wegkanonisierten Dubletten ein, sendet man widersprüchliche Signale und belastet den Server, ohne die Indexierung zu verbessern. Der schwache, aber reale Sitemap-Hinweis soll dieselbe URL stützen wie das Canonical Tag, nicht eine konkurrierende.
Weitere verbreitete Fehler: alle URLs pauschal auf die Startseite kanonisieren (das nimmt einzelne Inhalte faktisch aus der Wertung) und jede Seite einer Blätterstrecke auf Seite 1 kanonisieren (jede Seite der Paginierung ist ein eigener Inhalt und sollte auf sich selbst verweisen).
Der Praxisfall: Parameter- und Filterseiten
Am häufigsten begegnet einem das Canonical Tag dort, wo Filter und Parameter viele fast gleiche URLs erzeugen: in Onlineshops mit Facettennavigation. Jeder gesetzte Filter, jede Sortierung, jede Kombination kann eine eigene URL sein. Das summiert sich schnell zu Tausenden Adressen, deren Crawling erhebliche Ressourcen bindet und am Crawl-Budget zehrt.
Je nach Ziel führen zwei Wege zum Ergebnis. Sollen die Filterseiten gar nicht in den Index, schließt man sie per robots.txt vom Crawling aus oder bildet die Filter über URL-Fragmente (#) ab, die Suchmaschinen ohnehin ignorieren. Sollen bestimmte Filterseiten indexierbar bleiben, empfiehlt sich eine konsistente Reihenfolge der Parameter und ein Canonical Tag von der gefilterten auf die ungefilterte Basis-URL. Über die Zeit senkt das die Crawl-Frequenz der Nicht-Canonical-Varianten. Liefert eine Filterkombination keine Treffer, gehört dorthin ein Statuscode 404; eine dauerhaft leere Kategorie bekommt ein Noindex, nicht ein Canonical Tag.
Wenn die Suchmaschine dem Canonical nicht folgt
Weil das Canonical Tag nur ein Hinweis ist, kann eine Suchmaschine eine andere URL als repräsentativ einstufen, etwa wenn die übrigen Signale dagegensprechen oder eine andere Variante als vollständiger gilt. Ob das passiert ist, muss man nicht raten. Für Google zeigt das URL-Prüf-Tool in der Search Console zu jeder Adresse die tatsächlich gewählte Canonical URL neben der selbst deklarierten. Weichen beide voneinander ab, erscheint im Bericht zur Seitenindexierung der Status „Duplikat, Google hat eine andere Seite als der Nutzer als kanonisch bestimmt", bei fehlender eigener Angabe „Duplikat ohne vom Nutzer ausgewähltes Canonical".
Die Ursachen sind meist handfest: fehlerhafte hreflang-Annotationen, falsche CMS-Einstellungen, eine Server-Fehlkonfiguration, syndizierte Inhalte oder fremde Kopien der Seite. Wer die Signale korrigiert, sollte Geduld einplanen. Die Suchmaschine bewertet Cluster nicht sofort neu; URLs lösen sich schneller aus einem Cluster, wenn der inhaltliche Unterschied klar und deutlich ausfällt. Der stille Standardfehler in der Praxis ist die Annahme, das eigene Canonical Tag habe sich durchgesetzt: Ein kurzer Blick ins URL-Prüf-Tool nach dem Setzen ersetzt diese Annahme durch Gewissheit.
Fragen, die beim Canonical immer wieder aufkommen
Kann eine URL mehrere Canonical Tags haben? Technisch ja, sinnvoll nein. Sobald die Suchmaschine mehr als eine rel="canonical"-Angabe findet, verwirft sie alle. Genau eine Angabe pro URL gehört ins <head>.
Ist ein selbstreferenzierendes Canonical Tag überall sinnvoll? In den meisten Fällen ja. Es legt die bevorzugte URL eindeutig fest und fängt automatisch angehängte Parameter ab. Zwingend ist es nicht, aber es nimmt der Suchmaschine eine Entscheidung ab.
Was passiert, wenn die Canonical URL auf eine 404-Seite zeigt? Dann läuft das Signal ins Leere, und die Suchmaschine fällt auf ihre übrigen Signale zurück. Eine Canonical URL sollte immer auf eine erreichbare, mit Statuscode 200 ausgelieferte Adresse verweisen, nicht auf eine weitergeleitete oder gesperrte.
Was ist der Unterschied zur Weiterleitung? Eine Weiterleitung per Statuscode 301 führt Nutzer und Suchmaschinen tatsächlich auf eine andere URL; die ursprüngliche Adresse ist dann nicht mehr direkt erreichbar. Ein Canonical Tag lässt alle Varianten erreichbar und benennt nur die bevorzugte Version für den Index.
Unterstützung bei Kanonisierung und Index-Management
Fehlerhafte Canonical-Angaben gehören zu den unauffälligsten technischen Problemen: Im Browser funktioniert alles, während im Hintergrund wichtige URLs aus der Wertung fallen oder die falsche Variante rankt. Ein Canonical Tag bündelt eben nur dann Signale, wenn interne Verlinkung, Sitemap, Weiterleitungen und hreflang dieselbe URL stützen. mindtwo prüft Kanonisierung im Zusammenhang mit Weiterleitungen, Indexsteuerung, hreflang und Sitemap, gleicht die tatsächlich gewählte Canonical URL in der Search Console ab und stellt die Signale widerspruchsfrei ein. Sprechen Sie uns an, wenn Ihre URL-Struktur sauber gebündelt gehört.
Weiterführende Themen zur Kanonisierung
- Wann Seiten in die Suche aufgenommen werden: die Indexierung
- Wie eine URL bewusst aus dem Index bleibt: die Noindex-Anweisung
- Die Alternative bei echtem Umzug: der Statuscode 301
- Welche URLs Suchmaschinen gemeldet bekommen: die Sitemap
Können wir weiterhelfen?
Sie haben ein spannendes Projekt und möchten mit uns zusammenarbeiten? Kontaktieren Sie uns jetzt!
Digitaler Erfolg? Ein Klick entfernt.
Unser Angebot ist so vielseitig wie die digitale Welt selbst. Von Webentwicklung bis hin zu strategischer Beratung bieten wir Ihnen ein Rundum-Paket für Ihren digitalen Erfolg. Entdecken Sie jetzt Ihre Möglichkeiten.
Erstgespräch vereinbaren
Vereinbaren Sie einen unverbindlichen und kostenlosen Beratungstermin und stellen Sie uns Ihr Projekt vor.