Was Canonical-Tags bewirken, wenn sie falsch gesetzt sind

Das Canonical-Tag ist kein Radiergummi für Duplicate Content

Ein Canonical-Tag teilt Suchmaschinen mit, welche URL Sie bevorzugen, wenn mehrere URLs denselben oder im Wesentlichen ähnlichen Inhalt enthalten. Die gängige HTML-Version sieht so aus:

<link rel="canonical" href="https://example.com/preferred-page/">

Es gibt auch eine HTTP-Header-Version, die vor allem für Nicht-HTML-Dateien wie PDFs nützlich ist:

Link: <https://example.com/preferred-file.pdf>; rel="canonical"

Das klingt einfach genug. Die Probleme beginnen, wenn Teams Canonical-Tags als sichere Methode behandeln, um alles Unbequeme aufzuräumen: facettierte Navigation, Tracking-Parameter, Druckseiten, nahezu doppelte Produktseiten, Paginierung, Staging-URLs und alte Kampagnenseiten.

Canonical-Tags sind kein Löschknopf. Sie sind keine Weiterleitung. Sie sind kein Ersatz für Informationsarchitektur. Und es ist nicht garantiert, dass sie befolgt werden.

Suchmaschinen verwenden Canonicals als starke Hinweise. Sie vergleichen das Canonical-Tag mit anderen Signalen: Weiterleitungen, internen Links, Sitemap-URLs, hreflang-Annotationen, Inhaltsähnlichkeit, HTTP-Statuscodes und den URLs, auf die Nutzer und Crawler tatsächlich stoßen. Wenn diese Signale widersprüchlich sind, kann die Suchmaschine Ihr Canonical ignorieren oder eine völlig andere kanonische URL wählen.

Deshalb kann es so verwirrend sein, Canonicals falsch zu setzen. Das Markup sieht im Browser korrekt aus, aber die falsche Seite erscheint in den Suchergebnissen — oder die richtige Seite verschwindet.

Was passiert, wenn ein Canonical auf die falsche URL zeigt

Wenn eine Suchmaschine doppelte oder nahezu doppelte URLs sieht, gruppiert sie sie in der Regel zu einem Cluster und wählt eine URL als kanonisch aus. Die gewählte kanonische URL ist die Version, die am ehesten indexiert und in den Suchergebnissen angezeigt wird. Signale aus den Duplikaten können in dieser gewählten URL zusammengeführt werden.

Wenn Ihr Canonical-Tag auf die falsche Seite zeigt, können mehrere Dinge passieren.

1. Die falsche URL wird indexiert

Angenommen, Sie haben zwei URLs:

• /mens-running-shoes/
• /sale/mens-running-shoes/

Wenn die Sale-Seite per Canonical auf die Hauptkategorieseite verweist, kann das in Ordnung sein, wenn der Inhalt nahezu identisch ist und die Sale-URL nur eine gefilterte Version darstellt. Wenn die Sale-Seite jedoch eigenen Text, eigene Produkte und eigene Suchnachfrage hat, kann das Canonical sie unterdrücken.

Die Seite kann weiterhin gecrawlt werden. Sie kann weiterhin für Nutzer zugänglich sein. Aber Suchmaschinen können entscheiden, sie nicht separat zu indexieren, weil Sie ihnen mitgeteilt haben, dass eine andere URL die bevorzugte Version ist.

Das ist der häufigste Canonical-Fehler: kein dramatischer technischer Ausfall, sondern ein leises Verschwinden aus dem Index.

2. Ranking-Signale werden an der falschen Stelle zusammengeführt

Canonicals werden häufig verwendet, um Signale wie Links und Varianten von Duplicate Content zusammenzuführen. Das ist nützlich, wenn die Duplikate wirklich gleichwertig sind. Es ist riskant, wenn sie es nicht sind.

Wenn ein Blogartikel Tracking-URLs hat wie:

• /guide-to-canonical-tags/?utm_source=newsletter
• /guide-to-canonical-tags/?utm_source=linkedin

Dann ist es sinnvoll, beide auf /guide-to-canonical-tags/ zu kanonisieren.

Wenn aber eine spanische Version, eine Druckversion mit zusätzlichem Inhalt oder eine Produktvariante mit anderer Suchintention auf dasselbe Canonical zeigt, führen Sie möglicherweise Signale zusammen, die getrennt bleiben sollten. Das Ergebnis kann eine schwächere Relevanz für alle diese Seiten sein.

Bei Canonical-Tags geht es um Gleichwertigkeit. Wenn zwei Seiten unterschiedliche Suchintentionen erfüllen, sollten sie wahrscheinlich nicht aufeinander kanonisiert werden.

3. Suchmaschinen ignorieren das Tag

Ein Canonical ist kein Befehl. Wenn das Canonical-Ziel weiterleitet, einen 404 zurückgibt, blockiert ist, ein noindex hat oder sehr unterschiedliche Inhalte enthält, können Suchmaschinen es ignorieren.

Das ist in gewisser Hinsicht gut: Ein schlechtes Canonical zerstört nicht immer die Indexierung. Es bedeutet aber auch, dass Sie nicht davon ausgehen können, dass das Tag tut, was Sie denken. Eine Seite kann ein Canonical deklarieren, während Google ein anderes auswählt.

Das ist besonders häufig der Fall, wenn interne Links, Sitemaps und Canonicals nicht übereinstimmen. Wenn jeder interne Link auf /product zeigt, Ihre Sitemap /product/ aufführt und Ihr Canonical auf https://www.example.com/product?ref=main verweist, haben Sie einen kleinen Streit zwischen Ihren eigenen Signalen erzeugt.

Suchmaschinen sind gut darin, diesen Streit aufzulösen. Sie lösen ihn aber nicht immer so auf, wie Sie es beabsichtigt haben.

4. Das Debugging wird unnötig schwierig

Schlechte Canonicals schlagen selten laut fehl. Sie erzeugen Symptome, die wie andere SEO-Probleme aussehen:

• „Discovered, currently not indexed“ oder ein entsprechender Indexierungs-Schwebezustand
• Die falsche URL rankt für eine Suchanfrage
• Parameter-URLs erscheinen in Berichten
• Kategorieseiten erscheinen nicht, obwohl sie crawlbar sind
• Internationale Seiten werden in die falsche Sprachversion zusammengeführt
• Neue Templates starten mit weniger indexierten Seiten als erwartet

Deshalb sollte Canonical-Debugging den rohen HTML-Code, gerendertes HTML, HTTP-Header, Weiterleitungen und Sitemap-Einträge einschließen. Wenn Sie bereits Weiterleitungsketten oder nicht übereinstimmende Header untersuchen, gelten dieselben Gewohnheiten; ein praktischer HTTP-Prüfablauf wie in unserem Leitfaden zum Debugging von Weiterleitungen und HTTP-Headern in der Produktion findet Canonical-Widersprüche meist schneller als das Anstarren eines CMS-Felds.

Die teuersten Canonical-Fehler

Alles auf die Startseite kanonisieren

Das passiert immer noch. Ein Template-Feld bleibt leer, ein Plugin fällt auf die Site-Root zurück, und plötzlich deklarieren Hunderte von Seiten die Startseite als Canonical.

Suchmaschinen können dies ignorieren, weil der Inhalt offensichtlich unterschiedlich ist. Wenn jedoch genug Signale unordentlich sind, können einige Seiten entfernt oder falsch geclustert werden. Mindestens senden Sie auf jeder Seite einen nutzlosen und widersprüchlichen Hinweis.

Die Startseite ist fast nie das Canonical für eine interne Seite.

Paginierte Seiten auf Seite eins kanonisieren

Lange Zeit haben einige Websites /category/page/2/, /page/3/ und so weiter zurück auf Seite eins kanonisiert. Die Absicht war, doppelte Kategorieseiten zu vermeiden.

Das Problem ist, dass paginierte Seiten keine Duplikate sind. Sie enthalten unterschiedliche Elemente und helfen Crawlern, tiefere Inhalte zu entdecken. Wenn Sie alle auf Seite eins kanonisieren, kann das die Wahrscheinlichkeit verringern, dass Suchmaschinen die späteren Seiten vollständig verarbeiten.

In der Regel sollten paginierte Seiten selbstreferenzierende Canonicals haben, sofern es keinen konkreten Grund zur Zusammenführung gibt.

Gefilterte Seiten kanonisieren, ohne die Suchintention zu prüfen

Facettierte Navigation schafft schwierige Entscheidungen. Manche gefilterten URLs sind Ballast:

• ?sort=price_ascending
• ?view=grid
• ?sessionid=123

Andere können wertvolle Landingpages sein:

• /sofas/blue/
• /laptops/16gb-ram/
• /hotels/paris/pet-friendly/

Pauschale Canonical-Regeln löschen oft nützliche Suchseiten zusammen mit nutzlosem Parameterrauschen. Bevor Sie gefilterte Seiten kanonisieren, fragen Sie, ob die gefilterte Seite stabile Inhalte, interne Links, Suchnachfrage und ein eigenständiges Nutzerbedürfnis hat.

Wenn die Antwort ja lautet, verdient sie es möglicherweise, mit einem selbstreferenzierenden Canonical indexierbar zu sein.

Canonicals auf weitergeleitete oder blockierte URLs zeigen lassen

Ein Canonical-Ziel sollte sauber, indexierbar sein und 200 OK zurückgeben. Lassen Sie Canonicals nicht auf URLs zeigen, die weiterleiten, Fehler zurückgeben, Cookies erfordern, durch robots.txt blockiert sind oder noindex tragen.

Dies ist eine der einfachsten Prüfungen, die sich automatisieren lässt. Crawlen Sie Ihre Website und markieren Sie Canonical-Ziele, die keine saubere 200-Antwort zurückgeben.

Canonical und noindex so vermischen, als bedeuteten sie dasselbe

rel="canonical" und noindex lösen unterschiedliche Probleme.

Verwenden Sie Canonical, wenn Duplikate existieren und Sie Signale auf eine bevorzugte URL zusammenführen möchten. Verwenden Sie noindex, wenn Sie nicht möchten, dass eine Seite überhaupt indexiert wird.

Beides zusammen zu verwenden, sendet eine ungünstige Botschaft: „Indexiere diese Seite nicht, aber verwende sie auch als Duplikatsignal für eine andere Seite.“ Suchmaschinen können damit oft umgehen, aber es ist keine saubere Anweisung. Wenn eine Seite ein Duplikat ist, kanonisieren Sie sie. Wenn sie nicht in der Suche erscheinen soll und keine sinnvolle Duplikatbeziehung hat, ziehen Sie noindex in Betracht.

Ein praktisches Canonical-Audit

Sie brauchen keine große SEO-Plattform, um viele Canonical-Probleme zu finden. Beginnen Sie mit einem Crawl, einigen URL-Stichproben und einer Tabelle.

Prüfen Sie für jedes wichtige Template:

1. Hat die Seite genau ein Canonical-Tag? Mehrere Canonical-Tags erzeugen Mehrdeutigkeit.
2. Ist das Canonical absolut? Verwenden Sie die vollständige URL einschließlich Protokoll und Hostname.
3. Gibt das Canonical-Ziel 200 OK zurück? Vermeiden Sie weitergeleitete, blockierte oder fehlerhafte Ziele.
4. Ist das Canonical-Ziel indexierbar? Kein noindex, keine robots-Blockierung, keine Authentifizierungspflicht.
5. Ist der Inhalt wirklich gleichwertig? Ähnlich ist nicht immer gleichwertig.
6. Stimmen interne Links überein? Verlinken Sie nach Möglichkeit auf das kanonische URL-Format.
7. Stimmt die Sitemap überein? Sitemaps sollten im Allgemeinen kanonische, indexierbare URLs aufführen.
8. Stimmen hreflang-Tags überein? Internationale Seiten benötigen konsistente Canonical- und hreflang-Beziehungen.
9. Entspricht das gerenderte HTML dem rohen HTML? JavaScript kann Tags ändern oder einfügen.
10. Welches Canonical hat die Suchmaschine gewählt? Inspection-Tools können zeigen, wenn sich Ihr deklariertes Canonical vom ausgewählten Canonical unterscheidet.

Hier kann auch Lighthouse hilfreich sein, aber nur innerhalb seiner Grenzen. Es kann einige Probleme mit Crawlability und Dokumenten markieren, versteht aber weder Ihre kommerzielle Absicht noch Ihre Canonical-Strategie. Behandeln Sie es als eine Eingabe, nicht als Urteil. Wenn Sie eine ruhigere Methode brauchen, um nützliche Befunde von Rauschen zu trennen, lesen Sie, wie man einen Lighthouse-Bericht ohne Panik interpretiert.

Selbstreferenzierende Canonicals sind meist eine gute Standardeinstellung

Jede wichtige indexierbare Seite sollte in der Regel sich selbst als Canonical deklarieren. Nicht, weil Suchmaschinen es ohne das Tag nicht herausfinden könnten. Sondern weil selbstreferenzierende Canonicals Mehrdeutigkeit reduzieren, wenn Parameter, Tracking-Links, kopierte URLs und CMS-Eigenheiten alternative Pfade zu demselben Inhalt schaffen.

Für eine saubere Produktseite ist dies normalerweise richtig:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

Für eine Tracking-URL sollte das Canonical in der Regel zurück auf die saubere Version zeigen:

<link rel="canonical" href="https://example.com/products/linen-shirt/">

Bei einer wirklich anderen Produktvariante kommt es darauf an. Wenn das rote, blaue und schwarze Hemd dieselbe Beschreibung haben und sich nur die Farbe ändert, kann eine kanonische Produktseite ausreichen. Wenn jede Variante eigene Nachfrage, Bewertungen, Bilder, Bestand und interne Links hat, können separate indexierbare Seiten sinnvoll sein.

Es gibt keine universelle Canonical-Regel für Varianten. Es gibt nur die Frage: Sind diese Seiten für einen Suchenden austauschbar?

Canonical-Tags sollten zur tatsächlichen URL-Policy Ihrer Website passen

Die meisten Canonical-Fehler sind Symptome eines tieferliegenden Problems mit der URL-Policy. Die Website hat nicht entschieden, ob Trailing Slashes wichtig sind, ob URLs mit Großbuchstaben aufgelöst werden sollen, ob Parameter erlaubt sind, ob HTTP auf HTTPS weiterleitet oder ob www kanonisch ist.

Wählen Sie eine saubere Version jeder URL und bringen Sie das gesamte System dazu, übereinzustimmen:

• Leiten Sie nicht bevorzugte URL-Versionen auf bevorzugte Versionen weiter.
• Verlinken Sie intern auf bevorzugte Versionen.
• Nehmen Sie bevorzugte Versionen in XML-Sitemaps auf.
• Verwenden Sie selbstreferenzierende Canonicals auf bevorzugten Seiten.
• Kanonisieren Sie nur echte Duplikate auf die bevorzugte URL.

Wenn all diese Signale in dieselbe Richtung zeigen, werden Canonical-Tags langweilig. Das ist das Ziel.

Das Fazit

Canonical-Tags sind mächtig, weil sie Indexierung und Signalzusammenführung beeinflussen. Aus demselben Grund sind sie gefährlich.

Ein falsches Canonical entfernt eine Seite nicht immer aus der Suche. Suchmaschinen können es ignorieren. Aber sich darauf zu verlassen, dass Suchmaschinen schlechte Signale retten, ist keine Strategie. Der sicherere Ansatz besteht darin, Kanonisierung echten Duplikaten vorzubehalten, Ziele sauber und indexierbar zu halten und interne Links, Weiterleitungen, Sitemaps und Canonicals dieselbe Geschichte erzählen zu lassen.

Canonicals sind nicht der Ort, an dem man unordentliche Architektur versteckt. Sie sind der Ort, an dem man bestätigt, dass sie aufgeräumt wurde.