Wenn Google rel=canonical ignoriert

Du willst, dass Nutzer deine Hauptseite finden – und nicht auf einer verwaisten Subdomain oder einer Test-URL landen. In diesem Artikel erfährst du, warum Google rel=canonical manchmal ignoriert, wie du das erkennst und in welcher Reihenfolge du es zuverlässig behebst. Außerdem siehst du, wie falsche URLs in KI-Assistenten landen und was du tun kannst, damit Buchungen, Vertrauen und Sichtbarkeit nicht auf der Strecke bleiben – inklusive Quick-Wins, Checkliste und einem realistischen Ablaufplan.

Das Thema ist relevanter, als es klingt: Wenn eine Praxis- oder Studio-Seite statt der Buchungsseite plötzlich eine alte Demo-URL als „Original“ präsentiert, fühlt sich das für Nutzer an wie eine geschlossene Tür mit „Bitte woanders klingeln“. Und genau so gehen Anfragen verloren.

Rel=canonical sagt Suchmaschinen, welche URL als „Hauptversion“ gelten soll. Wichtig: Es ist ein starker Hinweis, aber keine Anweisung. Wenn andere Signale dagegen sprechen (zum Beispiel interne Links oder Sitemaps), kann Google die Canonical-Angabe überstimmen. Das sorgt dafür, dass in Suchergebnissen – und dadurch auch in Antworten von KI-Assistenten – plötzlich die falsche Variante auftaucht.

Was ist rel=canonical?

Rel=canonical ist ein Link-Tag, das du auf Seiten setzt, die du mit einer anderen URL konsolidieren willst. Ziel: Duplicate- oder Near-Duplicate-Varianten wie www vs. non-www, http vs. https, Tracking-Parameter, Filterseiten oder Staging-Domains sollen nicht konkurrieren, sondern die Signale (Crawlbudget, Backlinks, Relevanz) an die Haupt-URL bündeln. Google behandelt das als „Hint“ – wenn andere Website-Signale widersprechen, gewinnt nicht automatisch die Canonical-Angabe.

Die falsche URL in der Praxis

Angenommen, Google zeigt statt www.meinepraxis.de/termin die alte Subdomain demo.meinepraxis.de/termin. Nutzer können dort nicht buchen, springen ab, oder melden sich genervt beim Support. KI-Assistenten, die stark auf Suchergebnisse setzen, übernehmen solche falschen URLs oft ungeprüft. Ergebnis:

Weniger Buchungen und Anfragen.
Mehr Rückfragen und Supportkosten.
Ein vermeidbarer Vertrauensverlust.

In Audits sehe ich das besonders bei Neustarts, Domain-Umzügen, CMS-Wechseln und wenn Teams „mal eben“ eine Subdomain veröffentlichen, die intern nie als öffentlich gedacht war.

Ursachen

Zugängliche Subdomains: Staging, Demo, Test – ohne Schutz und ohne noindex.
Konflikt-Signale: Interne Links, Sitemaps oder hreflang verweisen auf die „falsche“ URL.
Doppelte Inhalte: Parameter-Varianten, Paginierung, Filter, Session-IDs.
Technik-Missverständnisse: 200-OK für Seiten, die eigentlich Soft-404 sind, oder Weiterleitungen, die ins Leere laufen.
Mixed Protocol/Host: http/https oder www/non-www parallel erreichbar, Canonical inkonsistent.
Noindex/Canonical-Widerspruch: Eine Seite ist noindex, verweist aber als Canonical auf sich selbst oder umgekehrt.

Quick Wins

So bekommst du es schnell wieder in den Griff – in der Praxis funktioniert diese Reihenfolge am besten:

Sichtprüfung: Suche in Google nach site:deinedomain.de, nach deiner Marke plus „Termin“ oder „Öffnungszeiten“. Achte auf Subdomains, Parameter und unerwartete Pfade.
URL-Inspektion: Prüfe problematische URLs in der Search Console Hilfe und dokumentiere, welche Variante Google aktuell als Canonical sieht.
Sperren statt verstecken: Staging/Demo mit HTTP-Auth schützen und noindex setzen. Nicht nur im Menü „verstecken“.
301-Weiterleitungen: Falsche Hosts (http → https, non-www → www oder umgekehrt) und veraltete Pfade sauber auf die Haupt-URL umleiten.
Canonicals bereinigen: Auf allen Duplikaten konsequent auf die Haupt-URL verweisen. Keine zyklischen oder wechselnden Canonicals.
Sitemaps straffen: Nur indexierbare, kanonische URLs eintragen. Alles andere raus.
Interne Links korrigieren: Menü, Footer, Teaser, hreflang und strukturierte Daten auf die Haupt-URL bringen.
Re-Crawl anstoßen: Wichtige Seiten mit der URL-Prüfung neu crawlen lassen. Geduld: Änderungen brauchen oft Tage bis Wochen.

Kleiner Realitätscheck: Es reicht nicht, nur ein Canonical zu setzen. Wenn Sitemaps, interne Links oder Weiterleitungen etwas anderes behaupten, folgt Google oft den stärkeren Signalen – genau deshalb musst du das Paket als Ganzes korrigieren.

KI-Assistenten und falsche URLs

Viele Assistenten und Answer-Features ziehen ihre Hinweise aus Top-Ergebnissen. Wenn Google eine Demo-URL präferiert, landet diese häufig auch in KI-Antworten. Du unterbrichst diese Kette, indem du die kanonische URL nicht nur technisch sauber machst, sondern sie auch in allen externen Profilen führst – etwa im Google Unternehmensprofil und in Social-Bios.

Prävention

Release-Checkliste: Vor jedem Go-Live: Auth-Schutz aktiv, noindex auf Staging, Sitemaps aktualisiert, Weiterleitungen getestet.
Konsistenz überall: Gleiche Haupt-URL in Impressum, Footer, E-Mail-Signaturen, Social- und Branchenprofilen. Wenn du deine Profile und Links alle Kanäle zentral steuern kannst, verhinderst du viele inkonsistente Signale.
Monitoring: Marken-Suche regelmäßig prüfen, Alerts für neue indexierte Subdomains setzen, Logfiles auf Crawls ungewöhnlicher Hosts beobachten.
Parameter-Policy: UTM & Filterseiten mit Canonical auf die bereinigte URL oder per 301 aufräumen – nie indexieren lassen.
Lokale Buchung klar führen: Die Buchungs-URL gehört in Navigation, Footer, Schema.org-Data und alle Profile. Wenn du ein Online-Buchungssystem wie Exzellsystem nutzt, halte genau diese eine URL überall konsistent.

Fazit

Rel=canonical ist wichtig – aber nur eine Stimme im Chor. Du gewinnst die richtige URL zurück, wenn Canonical, interne Links, Sitemaps und Weiterleitungen dieselbe Geschichte erzählen. So landen Nutzer und KI-Assistenten dort, wo sie hingehören: auf deiner Hauptseite, mit funktionierender Buchung und ohne Umwege.

Vertiefe die Details in der Google-Dokumentation zu canonical und setze die Schritte heute um. Jede Woche, in der eine falsche URL kursiert, kostet dich Vertrauen und Anfragen.

Weiterführendes

Hilfreich für die Umsetzung: die Search Console Hilfe und die Google-Dokumentation zu canonical.

FAQ

Warum ignoriert Google mein rel=canonical?

Weil andere Signale stärker sind. Wenn interne Links, Sitemaps, hreflang oder Weiterleitungen eine andere URL bevorzugen – oder die kanonische Seite schwer erreichbar ist –, entscheidet sich Google oft gegen dein Canonical. Bringe alle Signale in Einklang und stoße danach den Re-Crawl an.

Hilft noindex statt canonical?

Noindex ist ein klares Verbot der Indexierung und kann für Duplikate sinnvoll sein, die du wirklich nie im Index sehen willst (z. B. Staging). Canonical eignet sich, wenn Varianten existieren sollen, aber Signale an eine Haupt-URL bündeln. Häufig brauchst du beides an den richtigen Stellen.

Wie schnell korrigiert Google eine falsche Canonical-Auswahl?

Nach technischen Fixes siehst du erste Änderungen oft in wenigen Tagen, manchmal dauert es mehrere Wochen – abhängig von Crawl-Frequenz und Autorität. Beschleunige das durch URL-Inspektion, saubere Sitemaps und starke interne Verlinkung auf die Haupt-URL.

Soll ich die falsche URL in robots.txt blockieren?

Nur, wenn du sie wirklich nicht mehr crawlen lassen willst. Bedenke: Blockierte URLs können ihr Canonical nicht mehr ausliefern. Für Duplikate ist eine Kombination aus 301-Weiterleitung, noindex und korrektem Canonical oft besser als robots-Blocking.

Wie gehe ich mit UTM-Parametern und Filterseiten um?

Am sichersten sind 301-Weiterleitungen auf die bereinigte URL oder ein konsequenter Canonical auf die Haupt-Variante. Sorge dafür, dass solche URLs nicht in Sitemaps oder internen Links landen, und prüfe regelmäßig Logfiles auf Indexierungsversuche.

Was, wenn KI-Assistenten weiterhin die falsche URL nennen?

Stelle sicher, dass die korrekte URL in allen sichtbaren Quellen dominiert: Website, Sitemaps, interne Links, Google Unternehmensprofil, Social-Bios und Branchenverzeichnisse. Danach gib dem System Zeit – viele Assistenten aktualisieren sich mit dem Index.