Canonical Tags und KI-Suche: Welche URL am Ende zitiert wird

Von Manfred Mayer Rieger · Veröffentlicht 18. Oktober 2026

Im Februar 2025 ließ das Tow Center an der Columbia University denselben Test durch acht KI-Suchwerkzeuge laufen: eine Frage zu einem bestimmten Nachrichtenartikel stellen, dann prüfen, welche Quelle die Antwort als Beleg nennt. Ein Testfall betraf USA Today – ein Verlag, dessen robots.txt den Crawler von ChatGPT ausdrücklich aussperrt. ChatGPT antwortete trotzdem. Nicht mit einer Absage, sondern mit dem Zitat einer Kopie desselben Artikels, die bei Yahoo News zweitverwertet worden war. An die eigentlichen Server von USA Today war der Chatbot nie herangekommen. Er hatte die Geschichte einfach woanders gefunden, und das Zitat verriet mit keinem Wort, dass dieses “woanders” nicht die Quelle war.

Dieselbe Studie fand bei Perplexity Pro etwas Ähnliches, diesmal mit der Texas Tribune – trotz einer erklärten Partnerschaft zwischen beiden Seiten: Von zehn Testanfragen zitierte das Tool dreimal zweitverwertete Versionen von Tribune-Artikeln, einmal sogar eine inoffizielle Nachveröffentlichung, die niemand bei der Tribune autorisiert hatte. Ein Lizenzvertrag entschied also nicht, welche URL den Zuschlag bekam. Etwas anderes tat das.

Was soll ein Canonical-Tag eigentlich klären?

Googles eigene Dokumentation nennt dieses Problem Kanonisierung: die eine URL auswählen, die eine Gruppe doppelter oder fast identischer Seiten vertritt. Ein rel="canonical"-Tag ist die Art, wie eine Website eine Präferenz äußert – diese Seite, nicht jene, soll indexiert und angezeigt werden. Google listet die üblichen Ursachen solcher Duplikate: regionale Varianten, Sortier- und Filterparameter, eine offen gebliebene Staging-Kopie, eine Seite, die sowohl über http als auch über https erreichbar ist.

Dieselbe Dokumentation ist an einer Stelle unmissverständlich: Ein Canonical-Tag ist ein Hinweis, keine Anweisung. Google wägt ihn gegen Weiterleitungen, Sitemap-Einträge und den http/https-Unterschied ab und kann trotzdem eine andere URL wählen, wenn diese Signale sich widersprechen. Der Tag formuliert eine Absicht. Durchsetzen tut er sie nicht.

Was passiert, wenn der Tag selbst falsch ist?

Eine technische Crawl-Prüfung, die den Quelltext über die meistbesuchten Seiten einer Website hinweg liest – nicht nur die Startseite –, findet dabei meist dieselbe Handvoll Fehler, nur jeweils anders verkleidet. Ein Canonical-Tag, der auf eine völlig andere Domain zeigt, oft ein Überrest einer Migration oder einer Staging-Umgebung, die niemand abgeschaltet hat. Einer, der als relativer Pfad geschrieben ist und sich je nachdem, welche URL ihn ursprünglich aufgerufen hat, unterschiedlich auflöst. Einer, der auf eine unsichere http://-Adresse zeigt, obwohl die Website längst auf https:// umgestellt wurde und der Tag nie angepasst wurde. Und eine Seite, die sich selbst als canonical ausweist, während ein separates noindex den Suchmaschinen sagt, keine Version davon zu indexieren – zwei Anweisungen auf einer Seite, die sich gegenseitig widersprechen.

Nichts davon ist exotisch. Es ist genau das, was eine Template-Änderung oder eine halb abgeschlossene Migration leise zurücklässt, auf Seiten, die danach niemand mehr angesehen hat – dieselbe Art Grundlagenarbeit, die auch ein GEO-Audit und eine Prüfung der strukturierten Daten nebenbei aufdecken.

Liest ein KI-Crawler diesen Tag tatsächlich?

Hier lautet die ehrliche Antwort: nicht bestätigt. OpenAIs Crawler-Dokumentation ist bei der Zugriffssteuerung sehr genau – GPTBot und OAI-SearchBot lassen sich über robots.txt unabhängig voneinander erlauben oder blockieren, Änderungen wirken nach rund einem Tag, und ein gemeinsamer Crawl kann beiden Zwecken dienen, wenn eine Website beide Bots zulässt. Zur Frage, ob ein Canonical-Tag etwas daran ändert, welche URL einer der beiden Bots einmal innerhalb des Zugangs als maßgeblich behandelt, sagt sie nichts. Weder OpenAI noch ein anderer KI-Anbieter äußert sich dazu öffentlich, und auch die oben zitierte Studie hat Canonical-Tags nicht als eigene Variable untersucht. Das ist eine echte Lücke im öffentlich bekannten Wissen, keine Kleinigkeit, die hier unter den Tisch fällt.

Was lohnt sich dann wirklich zu reparieren?

Das Signal korrekt zu setzen, bleibt wichtig für die Ebene darunter, selbst ohne Beleg, dass der Abrufschritt eines Sprachmodells es direkt liest. Mehrere KI-Antwortfunktionen – darunter Googles AI Overviews – greifen auf denselben zugrunde liegenden Index zurück, den rel="canonical" eigentlich informieren soll. Ein falscher Canonical-Tag kann diesen Index verwirren, unabhängig davon, ob je ein Chatbot selbst auf den Tag schaut, und ein verwirrter Index ist ein weiterer Weg, auf dem am Ende die falsche URL das ist, was alles Nachgelagerte findet.

Die Prüfung selbst ist schnell erledigt: den Quelltext einer Seite öffnen und im Head nach link rel="canonical" suchen. Prüfen, ob es eine absolute URL ist, auf derselben Domain, über https, und ob dieselbe Seite nicht gleichzeitig ein noindex trägt. Das über eine Handvoll wichtiger Seiten wiederholen – Produktseiten, zentrale Inhalte, alles, was zweitverwertet wird oder unter mehr als einem URL-Pfad existiert. Es ist ein kleiner, mechanischer Teil eines umfassenderen technischen Reviews, und die meisten Websites, die eine Migration, einen Domainwechsel oder einen CMS-Wechsel hinter sich haben, tragen irgendwo mindestens einen dieser Fehler mit sich herum.

Ein Canonical-Tag bringt ein KI-Tool nicht dazu, die richtige URL zu zitieren. Er beseitigt nur einen ehrlichen Grund, warum es das nicht tut.