Was ein Canonical-Checker wirklich tut
Ein Canonical-Checker ruft eine URL ab, analysiert den HTML-<head>-Bereich nach <link rel="canonical" href="...">, liest den HTTP-Response-Header auf einen Link: <...>; rel="canonical"-Header und vergleicht die beiden. Wenn beide vorhanden sind und sich unterscheiden, liegt ein Konflikt vor. Wenn keiner vorhanden ist, hat die Seite kein explizites Canonical und riskiert Duplicate-Content-Probleme.
Er generiert auch gängige URL-Varianten und testet jede einzelne. Gegeben https://www.example.com/page, testen wir http://www.example.com/page, https://example.com/page, http://example.com/page, https://www.example.com/page/ und https://www.example.com/page?utm_source=test. Jede Variante könnte ein anderes Canonical zurückgeben, eine Weiterleitung oder das gleiche Canonical wie das Original. Unser Checker ordnet die Ergebnisse, sodass Sie das vollständige Bild in einer Tabelle sehen.
Drei Probleme tauchen wiederholt auf. Das erste sind Domain-übergreifende Canonicals – bei denen der Tag auf eine völlig andere Domain verweist, normalerweise nach einer Migration oder CDN-Fehlkonfiguration. Das zweite sind Weiterleitungsketten – bei denen eine URL auf ein anderes Canonical verweist, das wiederum auf ein drittes weiterleitet. Das dritte sind fehlende Canonicals auf paginierten oder gefilterten Seiten, was zu Duplicate-Content-Strafen führt.
So nutzen Sie diesen Canonical-Checker
- Fügen Sie Ihre URL in Primary URL ein. Nutzen Sie die Version, die Sie als Canonical einstufen – normalerweise https, www falls Sie das nutzen, und ohne Schrägstrich am Ende, es sei denn, Ihr CMS erfordert ihn.
- Fügen Sie zusätzliche Varianten in Extra variants to check ein, falls Sie bestimmte URLs testen möchten. Eine pro Zeile. Wir generieren die gängigen Varianten automatisch (Protokoll, Subdomain, Schrägstrich), daher ist dieses Feld optional.
- Klicken Sie auf Check canonicals. Sie erhalten eine Tabelle mit einer Zeile pro getesteter URL. Jede Zeile zeigt die URL, den HTTP-Statuscode, das Canonical aus dem HTML-Tag, das Canonical aus dem HTTP-Header und ob sie übereinstimmen.
- Schauen Sie sich die Conflicts-Spalte an. Eine rote Flagge bedeutet, dass sich das HTML-Canonical vom HTTP-Canonical unterscheidet, oder die URL verweist auf sich selbst, obwohl sie das nicht sollte, oder das Canonical verweist auf eine URL, die 404 zurückgibt.
- Klicken Sie auf Download report, um die Tabelle als CSV zu exportieren. Nutzen Sie sie, um Canonicals massenhaft in Ihrem CMS zu reparieren oder geben Sie sie an einen Entwickler weiter.
Versuchen Sie, https://www.example.com/page auf einer WordPress-Site zu überprüfen. Sie könnten feststellen, dass die www-Version auf https://www.example.com/page (non-www) verweist und dass die non-www-Version auf sich selbst verweist. Wenn beide Versionen 200 zurückgeben, könnte Google sie als Duplikate behandeln, es sei denn, eine leitet auf die andere weiter. Der Checker zeigt diesen Konflikt in einem Durchgang.
Warum URL-Varianten Duplicate Content erzeugen
Google behandelt https://example.com/page, https://www.example.com/page, http://example.com/page und https://example.com/page/ als vier separate URLs. Wenn alle vier 200 zurückgeben und identische Inhalte anzeigen, muss Google erraten, welche das Original ist. Canonical-Tags schaffen Klarheit, indem sie eine URL als Quelle deklarieren. Die anderen drei sollten entweder auf die Canonical weiterleiten oder ein Canonical-Tag enthalten, das auf sie verweist.
Drei praktische Folgen.
Verwässerung von Link-Equity. Wenn die Hälfte Ihrer Backlinks auf die www-Version und die Hälfte auf die non-www-Version verweist, sieht Google zwei Seiten, die die Autorität teilen. Ein Canonical konsolidiert diese Equity auf eine URL.
Verschwendete Crawl-Budget. Wenn Google alle vier Varianten crawlt, verwendet es vier Anfragen, um eine Seite zu indexieren. Auf großen Websites vervielfacht sich dies über Tausende von Seiten. Canonical-Tags oder 301-Weiterleitungen beenden die Duplizierung.
Index-Verwirrung. Google könnte die falsche Variante indexieren – die http-Version statt https oder die Version mit Schrägstrich, wenn Sie keinen bevorzugen. Ein Canonical-Tag sagt Google, welche in den Suchergebnissen angezeigt werden soll.
HTML-Canonical vs. HTTP-Header-Canonical
Das HTML-Canonical befindet sich im <head>: <link rel="canonical" href="https://example.com/page">. Das HTTP-Header-Canonical befindet sich in den Response-Headern: Link: <https://example.com/page>; rel="canonical". Beide dienen dem gleichen Zweck. Wenn beide vorhanden sind und übereinstimmen, großartig. Wenn beide vorhanden sind und sich unterscheiden, wählt Google eines – normalerweise das HTTP-Header-Canonical, da es vor dem Parsen des HTML gesendet wird.
CDNs, Proxys und serverseitige Weiterleitungen fügen manchmal HTTP-Header-Canonicals hinzu, ohne dass der Website-Besitzer es weiß. Wenn Ihr CMS ein HTML-Canonical ausgeben, das auf URL A verweist, aber Ihr CDN ein HTTP-Header hinzufügt, das auf URL B verweist, haben Sie einen stillen Konflikt. Unser Checker zeigt beide, sodass Sie Unstimmigkeiten erkennen können.
Einige CMSs und Frameworks setzen Canonicals standardmäßig falsch. Shopify kanonisiert Produkt-URLs manchmal zu der ersten Kollektion, in der sie erscheinen, auch wenn das Produkt in fünf Kollektionen ist. WordPress-Multisite-Installationen können auf die falsche Subdomain kanonisieren, wenn die Site-URL-Einstellung veraltet ist. Das Testen von Varianten offenbart diese Edge Cases.
Selbstreferenzierende Canonicals und wann sie wichtig sind
Ein selbstreferenzierendes Canonical bedeutet, dass das Canonical-Tag der URL auf sich selbst verweist: <link rel="canonical" href="https://example.com/page"> auf https://example.com/page. Dies ist korrekt für die kanonische Version einer Seite. Es sagt Google „dies ist das Original, kein Duplikat."
Wenn jedoch eine Variante selbstreferenziert – https://example.com/page/ verweist auf sich selbst statt auf die Version ohne Schrägstrich – haben Sie ein Problem. Google sieht zwei selbstreferenzierende URLs mit identischen Inhalten und muss sich für eine entscheiden. Die bessere Lösung ist, die Schrägstrich-Version per 301 auf die Version ohne Schrägstrich umzuleiten oder die Schrägstrich-Version auf die Version ohne Schrägstrich zu kanonisieren.
Paginierte URLs – /blog/page/2, /blog/page/3 – sollten auf sich selbst kanonisieren, nicht auf /blog, da jede Seite einzigartige Inhalte hat. Gefilterte oder sortierte URLs – /products?sort=price – sollten oft auf die ungefilterte Version /products kanonisieren, da sich die Inhalte überlappen. Unser Checker erzwingt diese Regeln nicht automatisch; er zeigt das Canonical, das Sie setzen, und kennzeichnet Unstimmigkeiten. Sie legen die Richtlinie fest.
Häufige Fehler
- Jede URL kanonisiert zur Startseite. Einige Plugins und Themes haben dies als Standard. Es sagt Google, dass jede Seite ein Duplikat des Home ist. Überprüfen Sie eine tiefe Seite – einen Blog-Beitrag oder ein Produkt – um zu bestätigen, dass es auf sich selbst kanonisiert, nicht auf
/. - Canonical verweist auf eine 404. Nach einer Migration oder URL-Änderung können alte Seiten immer noch auf URLs kanonisieren, die nicht mehr existieren. Unser Checker ruft die Canonical-URL ab und meldet den Statuscode. Wenn es 404 ist, entfernen Sie das Canonical oder aktualisieren Sie es.
- Canonical verweist auf eine Weiterleitung. Wenn das Canonical
https://example.com/oldist, aber diese URL 301 auf/newweiterleitet, muss Google der Weiterleitung folgen. Besser ist es, direkt auf/newzu kanonisieren. - Relative URLs im Canonical-Tag nutzen.
<link rel="canonical" href="/page">funktioniert in den meisten Browsern, ist aber technisch ungültig. Nutzen Sie absolute URLs:href="https://example.com/page". - HTTP zu HTTPS kanonisieren, aber nicht umleiten. Wenn die http-Version auf https kanonisiert, aber immer noch 200 zurückgibt, sehen Nutzer auf der http-URL Mixed-Content-Warnungen und bleiben auf http. Eine 301-Weiterleitung ist besser als ein Canonical-Tag für Protokolländerungen.
- Nur die kanonische Version testen. Sie müssen die Varianten testen, um zu sehen, was sie tun. Wenn die www-Version nicht auf die non-www-Version kanonisiert, haben Sie ein Duplikat.
Erweiterte Tipps
- Testen Sie eine URL von jedem Seitentyp: Startseite, Kategorie, Produkt, Blog-Beitrag, paginiertes Archiv. Canonicals unterscheiden sich oft je nach Template, und ein Problem in einem Template betrifft alle Seiten, die es nutzen.
- Überprüfen Sie Abfrageparameter.
?utm_source=twitterund?ref=emailsollten auf die saubere URL kanonisieren, wenn der Inhalt identisch ist. Wenn sie das nicht tun, erstellen Sie unendliche Varianten. - Suchen Sie nach Domain-übergreifenden Canonicals nach einer Migration. Wenn Sie von
old-domain.comzunew-domain.comumgezogen sind, aber vergessen haben, die Canonicals zu aktualisieren, könnten Seiten auf der neuen Domain immer noch auf die alte kanonisieren. Dies sagt Google, die alte Site zu indexieren. - Wenn Sie hreflang-Tags für lokalisierte Seiten nutzen, bestätigen Sie, dass jede Sprachvariante auf sich selbst kanonisiert. Ein häufiger Fehler ist, dass alle Sprachversionen auf die englische URL kanonisieren.
- Kanonicals massenhaft in Ihrer Sitemap überprüfen. Wenn Ihre Sitemap 500 URLs auflistet, kann ein Skript diesen Checker in einer Schleife aufrufen und eine CSV aller exportieren, die nicht selbstreferenzieren. Fangen Sie Probleme, bevor Google es tut.
- Nach dem Bereitstellen eines neuen Themes, Plugins oder CMS-Updates erneut überprüfen. Die Canonical-Logik kann stillschweigend brechen, wenn sich eine Abhängigkeit ändert.
Wenn Ihre Canonical-Überprüfung Konflikte offenbart, beheben Sie sie in Ihren CMS-Einstellungen oder Theme-Code, dann führen Sie die Überprüfung erneut aus. Wenn Sie auch bestätigen möchten, dass Ihre Sitemap nur kanonische URLs enthält, nutzen Sie den Sitemap-Checker, um einen Querverweis herzustellen. Um zu sehen, wie die vollständigen Metadaten Ihrer Seite – Titel, Meta Description, OG-Tags und Canonical – in Google, Twitter und LinkedIn angezeigt werden, zeigt der Website-Metadaten-Checker alle nebeneinander an. Wenn Sie bestätigen möchten, dass Googlebot die kanonische URL erreichen kann und nicht von robots.txt blockiert wird, führt die SEO-Checkliste 20 On-Page-Überprüfungen durch, einschließlich Canonical-Validierung.