Canonical-Fehler überwachen: Wenn die falsche URL rankt

Wie aus einer Seite vier Adressen werden

Doppelte Inhalte entstehen selten aus Nachlässigkeit. Sie entstehen, weil eine Anwendung mehrere Wege anbietet, denselben Inhalt aufzurufen. Ein Newsletter hängt einen Kampagnenparameter an, ein Filter erzeugt eine Sortierreihenfolge, eine Druckansicht liefert dieselben Absätze ohne Navigation, ein Server beantwortet die Adresse mit und ohne www und mit und ohne abschließenden Schrägstrich. Jede dieser Adressen liefert Statuscode 200 und gültiges HTML. Für den Besucher ist das unauffällig; für eine Suchmaschine sind es vier eigenständige Dokumente mit fast identischem Text, zwischen denen sie sich entscheiden muss. Wie sich solche Nebenwege im eigenen Bestand überhaupt auffinden lassen, beschreibt der Beitrag zu verwaisten Seiten und interner Verlinkung.

Die Auszeichnung, die dieses Problem lösen soll, ist älter als die meisten heutigen Redaktionssysteme: Sie ist seit April 2012 als RFC 6596 festgeschrieben und war von Anfang an für genau diese Fälle gedacht - Parameter-URLs, Sitzungskennungen und auf mehrere Teilseiten aufgeteilte Inhalte (IETF, RFC 6596). Der Grundgedanke hat sich seither nicht verändert. Verändert hat sich, wie viele Ausspielwege eine einzelne Seite heute hat: serverseitig erzeugtes HTML, ein Zwischenspeicher davor, eine Anwendungsschicht im Browser, dazu die Varianten für mobile Ansichten. Jede dieser Schichten kann die Angabe setzen, überschreiben oder verschlucken, und keine von ihnen meldet es.

• Kampagnen- und Sitzungsparameter: utm-Angaben und Sitzungsnummern erzeugen je Aufruf eine neue Adresse.
• Filter, Sortierung und Blätterung: Facettennavigationen erzeugen mehr Adressen, als es Produkte gibt.
• Groß- und Kleinschreibung: Pfade unterscheiden sich technisch, der Inhalt nicht.
• Host- und Protokollvarianten: mit und ohne www, mit und ohne abschließenden Schrägstrich.
• Druck- und Leseansichten: eigene Adressen für dieselben Absätze, oft ohne Auszeichnung im Kopfbereich.
• Sprach- und Regionsfassungen: dieselbe Sprache für mehrere Märkte, wo hreflang abgrenzt und nicht das Canonical.

Der Schaden ist selten ein Rankingverlust im Wortsinn. Häufiger verteilt sich, was eigentlich zusammengehört: Verweise von außen zeigen auf die eine Adresse, interne Verlinkungen auf die andere, die Sitemap führt eine dritte. Die Suchmaschine wählt eine davon als kanonisch aus und führt die Signale dort zusammen - nur eben womöglich auf einer Adresse, die der Betreiber nicht in der Ergebnisliste sehen wollte. Wer eine Weiterleitungskette davorschaltet, verschiebt das Problem nur, wie der Beitrag zu Weiterleitungsketten im Detail zeigt.

Ein starkes Signal, aber keine Anweisung

Der erste Denkfehler steckt im Namen. Ein Canonical-Tag ist kein Befehl, sondern ein Hinweis. Die Suchmaschine wertet ihn zusammen mit anderen Merkmalen aus und kann zu einem abweichenden Ergebnis kommen. Im Bericht zur Seitenindexierung gibt es dafür einen eigenen Statuswert: Die Seite ist als kanonisch ausgezeichnet, doch der Anbieter hält eine andere Adresse für die bessere Wahl (Google Search Console-Hilfe). Das ist im technischen Sinn kein Fehler. Es ist eine abweichende Entscheidung - und genau deshalb fällt sie in keiner Fehlerliste auf, sondern nur dann, wenn jemand gezielt danach sieht.

Die Verfahren zur Zusammenführung wirken abgestuft und lassen sich stapeln. Am stärksten wirkt die dauerhafte Weiterleitung, weil sie die Doppelung technisch beseitigt. Darunter liegt die Auszeichnung im Kopfbereich. Die Aufnahme in eine Sitemap ist ausdrücklich als schwaches Signal beschrieben, das eine Adresse zur kanonischen werden lässt (Google Search Central). Wer sich allein auf die Sitemap verlässt, hat also nicht die stärkste, sondern die schwächste Karte gespielt - ein Punkt, der im Zusammenspiel mit dem Sitemap-Monitoring regelmäßig unterschätzt wird.

Drei Einbauwege und wie verbreitet sie sind

Die Angabe kann an drei Stellen stehen, und die Verteilung ist deutlich: Im ausgelieferten Roh-HTML findet sie sich auf 64,40 Prozent der Desktop-Seiten und 64,27 Prozent der mobilen Seiten (Web Almanac 2025). Nach dem Rendern liegt der Anteil bei 66,01 Prozent beziehungsweise 66,11 Prozent (Web Almanac 2025). Der dritte Weg, die Angabe im HTTP-Antwortkopf, ist mit 0,58 Prozent auf dem Desktop und 0,50 Prozent mobil praktisch ungenutzt (Web Almanac 2025) - obwohl er der einzige ist, der auch für Dateien ohne Kopfbereich funktioniert.

Der Antwortkopf verdient mehr Aufmerksamkeit, als seine Verbreitung nahelegt. Ein Handbuch als PDF, ein Datenblatt, eine Preisliste - all das hat keinen Kopfbereich, in dem eine Auszeichnung stehen könnte. Ohne die Angabe in der Kopfzeile bleibt für solche Dateien nur die Weiterleitung oder das Auslassen. Und weil die Kopfzeile in keinem Seitenquelltext auftaucht, fällt ihr Verlust bei einer Änderung am Zwischenspeicher niemandem auf, solange niemand die Antwort selbst mitliest. Ein einfacher Abruf mit dem Header-Werkzeug zeigt in wenigen Sekunden, ob die Zeile noch da ist.

Ob die Angabe gelesen wird, entscheidet der Kopfbereich

Hier liegt der Fehler, der am häufigsten übersehen wird, weil er nicht in der Zeile selbst steckt, sondern in ihrer Umgebung. Die Auszeichnung wird nur anerkannt, wenn sie im Kopfbereich der Seite steht - und dieser Kopfbereich muss dafür gültiges HTML sein (Google Search Central). Steht dort ein Element, das dort nicht stehen darf, endet der Kopfbereich nach der Lesart des Auswerters an dieser Stelle. Alles Nachfolgende rutscht in den Rumpf der Seite, das Canonical eingeschlossen. Die Zeile steht dann zeichengleich im Quelltext und wirkt trotzdem nicht.

Wie oft das vorkommt, ist gemessen: Auf 10,1 Prozent der Desktop-Seiten und 10,3 Prozent der mobilen Seiten findet sich ungültiges HTML im Kopfbereich (Web Almanac 2025). Zulässig sind dort genau acht Elementarten - title, meta, link, script, style, base, noscript und template (Web Almanac 2025); ein Element einer anderen Art beendet den Abschnitt vorzeitig. Der häufigste Störer ist dabei kein exotisches Konstrukt, sondern ein Bild: Ein verirrtes img-Element taucht auf 27,2 Prozent der betroffenen Desktop-Seiten und 23,0 Prozent der mobilen Seiten auf (Web Almanac 2025). Ein Zählpixel, das ein Marketingwerkzeug in den Kopfbereich einfügt, reicht aus.

• Bilder und Zählpixel: ein einzelnes img-Element beendet den Kopfbereich - der häufigste Einzelfall.
• Rumpf-Elemente aus Vorlagen: div, span oder p vor dem schließenden Kopf-Tag.
• iframes von Einbindungen: Einbettungen, die ihr Markup an der Stelle des Skripts einsetzen.
• Nicht geschlossene Elemente: ein offenes Anführungszeichen zieht den Rest der Zeile in sich hinein.
• Kommentarblöcke mit Markup: auskommentierte Bausteine, unvollständig geschlossen ausgeliefert.
• Ausgabe vor dem Dokumenttyp: eine Leerzeile oder Fehlermeldung vor der ersten Zeile.

Der Bestand baut sich langsam ab: Gegenüber dem Vorjahr ist der Anteil ungültiger Kopfbereiche um 4,7 Prozent auf dem Desktop und 5,2 Prozent mobil zurückgegangen (Web Almanac 2025). Das ist eine Bewegung im niedrigen einstelligen Bereich pro Jahr, keine Trendwende. Betroffen ist dabei nicht nur das Canonical: Im selben Abschnitt stehen die Angaben zur Indexierungssteuerung, die auf 47,0 Prozent der Desktop-Seiten und 47,9 Prozent der mobilen Seiten gesetzt sind (Web Almanac 2025), dazu Titel auf 98,6 Prozent und Beschreibungen auf 67,7 Prozent der Desktop-Seiten (Web Almanac 2025). Fällt der Kopfbereich, fällt alles davon gemeinsam. Ähnlich empfindlich reagieren mehrsprachige Auszeichnungen, wie der Beitrag zu hreflang-Fehlern beschreibt.

Wenn das Rendern die Angabe überschreibt

Der häufigste Canonical-Konflikt entsteht nicht beim Ausliefern, sondern erst im Browser. Auf 2,71 Prozent der Desktop-Seiten und 3,02 Prozent der mobilen Seiten ändert das Rendern den Wert, der im Roh-HTML stand (Web Almanac 2025). Der Wert ist gestiegen: 2024 lag er bei 1,9 Prozent auf dem Desktop und 2,1 Prozent mobil (Web Almanac 2024). Umgekehrt gilt: Nur in rund 2 Prozent der Fälle fehlt die Angabe im Roh-HTML und ist erst im gerenderten Dokument vorhanden (Web Almanac 2025). Wer allein das ausgelieferte HTML prüft, meldet dort also einen Fehlbestand, den es nicht gibt - und übersieht zugleich den größeren Fall, in dem eine vorhandene Angabe später ersetzt wird.

Der Weg über JavaScript ist zwar möglich, aber ausdrücklich nicht empfohlen: Eine Anwendung kann eine Canonical-Auszeichnung nachträglich einfügen, und die Suchmaschine liest sie auch, hält den Weg jedoch nicht für den richtigen (Google Search Central). Dazu kommt die Frage des Zeitpunkts. In die Renderwarteschlange gelangen ausschließlich Seiten mit Statuscode 200, sofern keine Anweisung die Indexierung untersagt (Google Search Central) - wie lange eine Seite dort liegt, ist offen. In dieser Zeit gilt der Wert aus dem Roh-HTML. Zwei Fassungen derselben Angabe existieren also nebeneinander, und welche gerade zählt, entscheidet ein Zeitpunkt, den niemand im Haus kennt.

Neben dem Überschreiben beim Rendern gibt es den stillen Fall des Widerspruchs innerhalb derselben Auslieferung: Auf 0,72 Prozent der Desktop-Seiten und 0,71 Prozent der mobilen Seiten stehen zwei Canonical-Angaben, die auf unterschiedliche Ziele zeigen (Web Almanac 2025). Auch der Antwortkopf wird beim Rendern überschrieben, auf 0,25 Prozent der Desktop-Seiten und 0,21 Prozent der mobilen Seiten (Web Almanac 2025). Der Bestand solcher Widersprüche geht kaum zurück - von 0,8 auf 0,7 Prozent im Jahresvergleich (Web Almanac 2025) -, und er ist gewachsen: 2022 waren 0,4 Prozent betroffen, 2024 hatte sich der Wert auf 0,8 Prozent verdoppelt (Web Almanac 2024). Der Fehler wächst mit der Zahl der Ausspielwege, nicht mit der Nachlässigkeit der Betreiber. Wer nach jeder Auslieferung ohnehin prüft, ob noch der alte Stand ausgegeben wird, kennt das Muster aus dem Beitrag zu den Cache-Fallen nach dem Deploy.

Was ein technischer Standardtest nicht sieht

Ein verbreiteter technischer Test bescheinigt fast allen Seiten ein formal gültiges Canonical: Von den Seiten, auf denen überhaupt ein Canonical-Element erkannt wurde, bestanden 98 Prozent die entsprechende Prüfung (Web Almanac 2024). Diese Zahl beruhigt zu Unrecht. Geprüft wird die Form - ob die Angabe existiert, ob sie eine gültige absolute Adresse enthält, ob sie nur einmal vorkommt. Ob das Ziel inhaltlich das richtige ist, ob es erreichbar ist, ob es selbst wiederum weiterleitet oder ob es in der Sitemap steht, bleibt außerhalb der Reichweite eines solchen Tests.

Der Indexierungsbericht zeigt nicht den ganzen Bestand

Die naheliegende Bezugsquelle für Canonical-Befunde ist der Bericht zur Seitenindexierung. Er ist nützlich und er ist begrenzt. Je Status zeigt er höchstens 1.000 Beispieladressen (Google Search Console-Hilfe) - wer mehr Varianten erzeugt hat, sieht seinen Bestand dort nicht vollständig. Der Anbieter selbst schränkt zusätzlich ein: Für Websites mit weniger als 500 Seiten sei der Bericht vermutlich entbehrlich (Google Search Console-Hilfe). Umgekehrt gelesen heißt das: Oberhalb dieser Größe braucht es eine eigene Beobachtung, die nicht auf eine Beispielliste angewiesen ist. Wie eine belastbare Bestandsaufnahme aussieht, zeigt der Beitrag zur Prüfung der Monitoring-Abdeckung.

Dazu kommt der Zeitversatz. Ein Bericht bildet einen zurückliegenden Verarbeitungsstand ab, nicht die Auslieferung von heute Morgen. Beides ergänzt sich: Der Bericht sagt, wie die Suchmaschine entschieden hat, die eigene Messung, was ausgeliefert wurde.

Die Beziehung canonical benennt die bevorzugte IRI aus Ressourcen mit doppeltem Inhalt.

— RFC 6596, sinngemäß übersetzt

Doppelte Adressen kosten Abrufbudget

Bei kleinen Websites ist die Frage nach dem Abrufbudget akademisch. Der Anbieter nennt als groben Anhaltspunkt mittlere und größere Websites ab 10.000 eigenständigen Seiten mit täglich wechselnden Inhalten (Google Search Central) - ausdrücklich als Schätzung, nicht als Schwelle. Oberhalb davon zählt jede abgerufene Adresse. Werden Varianten abgerufen, statt neuer Inhalte, verschiebt sich der Takt, in dem Änderungen bemerkt werden. Auch die Sitemap stößt an eine harte Grenze: Eine einzelne Datei fasst höchstens 50.000 Adressen oder 50 MB im unkomprimierten Zustand (Google Search Central). Wer mehr Varianten erzeugt als Inhalte, füllt dieses Kontingent mit Doppelungen.

Wie viele Seiten überhaupt als Ziel einer Zusammenführung dienen, ist ebenfalls erhoben: 7 Prozent der Desktop-Seiten und 9 Prozent der mobilen Seiten werden von anderen Seiten als kanonische Fassung benannt (Web Almanac 2025). Das ist der Ort, an dem sich entscheidet, ob die Zusammenführung greift oder ins Leere läuft. Zum Vergleich: Nur 3,5 Prozent der Desktop-Seiten und 2,4 Prozent der mobilen Seiten schließen sich aktiv per noindex aus (Web Almanac 2025). Doppelungen werden also überwiegend nicht ausgeschlossen, sondern zusammengeführt - was die Richtigkeit der Angabe zur eigentlichen Stellschraube macht. Welche Rolle die robots-Datei dabei spielt und wo sie gerade nicht hilft, klärt der Beitrag zu robots.txt-Fehlern.

<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="utf-8">
  <title>Regenjacke Nordwind - Shop</title>
  <link rel="canonical" href="https://shop.example/produkt/regenjacke">
  <link rel="alternate" hreflang="en" href="https://shop.example/en/product/rain-jacket">
  <meta name="robots" content="index,follow">
  <!-- Ab hier nur noch script, style, link, meta, base, title, noscript -->
</head>
<body>
  <!-- Zählpixel und Einbindungen gehören hierher, nicht in den Kopfbereich -->
  <img src="/pixel.gif" alt="" width="1" height="1">
</body>
</html>

Canonical-Angaben laufend überwachen

Eine einmalige Prüfung beim Relaunch beantwortet die Frage für einen Tag. Der Bestand verändert sich danach durch jede Vorlagenänderung, jedes zusätzliche Skript und jede Anpassung am Zwischenspeicher. Sinnvoll ist deshalb eine wiederkehrende Messung, die den ausgelieferten Zustand mit dem erwarteten vergleicht und die Abweichung benennt. Das SEO-Monitoring von XICTRAQ liest die Auszeichnungen der hinterlegten Adressen in festem Takt aus und hält den Befund neben Erreichbarkeit, Zertifikatslaufzeit und Inhaltsänderung fest - verarbeitet und gehostet in Deutschland.

• Vorhandensein je Adresse: steht eine Canonical-Angabe im Kopfbereich, und genau einmal?
• Ziel und Erreichbarkeit: liefert die genannte Adresse Statuscode 200, leitet sie weiter oder fehlt sie?
• Selbstverweis oder Fremdverweis: zeigt die Seite auf sich selbst, und ist das beabsichtigt?
• Roh gegen gerendert: unterscheidet sich der ausgelieferte Wert vom gerenderten?
• Kopfbereich gültig: endet er vor der Angabe, weil ein unzulässiges Element davorsteht?
• Antwortkopf vorhanden: trägt die Kopfzeile für Dateien ohne Kopfbereich die erwartete Angabe?
• Abgleich mit der Sitemap: steht die kanonische Adresse dort, und die Varianten nicht?

Wichtig ist die Trennung von Alarm und Bericht. Eine Abweichung, die eine ganze Vorlage betrifft, gehört sofort gemeldet, weil sie mit einem Deploy entstanden ist und mit einer Änderung wieder verschwindet. Ein einzelner Befund auf einer selten aufgerufenen Adresse gehört in den wiederkehrenden Bericht, nicht in die Benachrichtigung um drei Uhr morgens. Die Berichte und Statusseiten bündeln solche Befunde in einem festen Rhythmus, ohne dass jede einzelne Abweichung als Störung behandelt wird.

Vom Einzelbefund zur festen Kontrollschleife

Der Einstieg ist ein Bestand, keine Werkzeugentscheidung. Zuerst die Liste der Adressen, die tatsächlich ausgeliefert werden - aus Sitemap, Serverprotokoll und interner Verlinkung zusammengeführt. Danach je Adresse die vier Werte: Statuscode, Canonical im Roh-HTML, Canonical nach dem Rendern, Angabe im Antwortkopf. Aus dem Abgleich entsteht die erste Fehlerliste, und sie ist erfahrungsgemäß kürzer als befürchtet und anders sortiert als erwartet. Ein schneller Zwischenschritt ist die Prüfung der Weiterleitungsziele mit dem Weiterleitungs-Werkzeug, weil ein Canonical auf eine weiterleitende Adresse zwei Befunde in einem ist.

Aus der Liste wird eine Kontrollschleife, sobald die vier Werte in festem Takt erhoben und mit dem letzten Stand verglichen werden. Sinnvoll ist, den erwarteten Wert je Adresse zu hinterlegen, statt nur Änderungen zu melden: Dann fällt auch der Fall auf, in dem eine Angabe seit Monaten falsch steht und sich deshalb nicht ändert. Damit rückt die Frage vom Zeitpunkt des Relaunchs auf den Betrieb - und dorthin gehört sie, denn Canonical-Fehler entstehen typischerweise nicht beim Bauen, sondern beim Weiterbauen. Welche Spuren veraltete Bausteine im Stapel in den Antwortköpfen hinterlassen, beschreibt der Beitrag zu den Versionsbannern in Server-Headern; die Preisübersicht steht unter Preise und Pläne.