Alternative Seite mit richtigem kanonischen Tag: meist nichts zu tun

„Alternative Seite mit richtigem kanonischen Tag“ bedeutet, dass Google eine URL gefunden hat, deren Canonical-Tag auf eine andere URL zeigt, dieser Angabe zugestimmt und stattdessen die andere URL indexiert hat. Meist funktioniert das System damit genau wie vorgesehen, und es gibt nichts zu ändern. Zum Problem wird der Status nur, wenn eine Seite auf der Liste steht, die in den Suchergebnissen erscheinen soll; das geht in der Regel auf ein Template zurück, das das falsche Canonical schreibt.

Der Status erscheint im Bericht zur Seitenindexierung unter „Nicht indexiert“; in der englischen Oberfläche heißt er „Alternate page with proper canonical tag“. Googles portugiesische Hilfeseiten nennen denselben Grund „Página alternativa com tag canônica adequada“.

Was Google mit „Alternative Seite mit richtigem kanonischen Tag“ meint

Googles Dokumentation zum Bericht zur Seitenindexierung (Stand: Oktober 2026) beschreibt diese Seiten als Seiten, die als Alternative einer anderen Seite gekennzeichnet sind, und nennt 3 Beispiele: eine AMP-Seite mit einer kanonischen Desktop-Seite, eine Mobilversion einer kanonischen Desktop-Seite und eine Desktop-Version einer kanonischen Mobilseite. Weiter heißt es dort, die Seite verweise korrekt auf die kanonische Seite, die indexiert ist, und Sie müssten nichts unternehmen.

Zwei weitere Details sind wichtig. Laut dem Abschnitt „Nicht indexiert“ sind diese Seiten nicht unbedingt wegen eines Fehlers nicht indexiert; eine Zahl an dieser Stelle ist also keine Fehlerzahl. Und der Eintrag endet mit dem Hinweis, dass die Search Console Seiten in anderen Sprachen nicht als Alternativen erkennt. Eine übersetzte Seite, die hier auftaucht, ist deshalb ein Warnsignal.

Google kennt 3 Canonical-Status, und sie unterscheiden sich in 2 Fragen: Hat die Seite eine kanonische URL angegeben, und hat Google ihr zugestimmt?

Nur bei diesem der 3 Status stimmen Ihre Anweisung und Googles Entscheidung überein. Stehen Ihre URLs stattdessen in der dritten Zeile, behandelt der Leitfaden zu „Duplikat – vom Nutzer nicht als kanonisch festgelegt“ diesen Fall.

Welche URLs normalerweise in diesem Status landen

Jede URL, deren Canonical-Tag eine andere Seite nennt, kann hier landen, sobald Google zustimmt. Die üblichen Quellen:

• Tracking- und Kampagnenparameter. Links in Anzeigen, E-Mails und Social-Media-Beiträgen hängen Parameter wie ?utm_source= oder ?gclid= an. In Googles eigenem Beispiel wird eine Produkt-URL mit gclid-Parameter auf die saubere Produkt-URL kanonisiert.
• Sortieren und Filtern. Kategorieseiten, die dieselben Produkte umsortieren oder filtern (?sort=price, ?color=blue), erzeugen viele URLs für eine Seite.
• AMP-Paare. Die AMP-Spezifikation verlangt, dass das Canonical einer AMP-Seite auf die reguläre HTML-Version zeigt oder auf sich selbst, wenn es keine reguläre Version gibt. Jede gepaarte AMP-Seite ist ein erwarteter Eintrag.
• Separate mobile URLs. Eine Website, die m.example.com neben www.example.com ausliefert, kanonisiert die eine Version auf die andere.

Für all diese URLs ist „nicht indexiert“ das Ziel: eine URL pro Inhalt in den Suchergebnissen, genau das, was das Canonical-Tag verlangt hat. Googles Dokumentation zur Kanonisierung ergänzt, dass doppelte URLs seltener gecrawlt werden als die kanonische.

Ist das ein Problem? Belassen, beobachten oder beheben

Die Einschätzung hängt davon ab, was auf der Liste steht, nicht davon, wie lang sie ist.

• Belassen, wenn die Beispiel-URLs Varianten sind, die Sie nie indexiert haben wollten, und jedes Canonical die Version nennt, die in der Suche erscheinen soll. Das ist der Normalzustand, auch bei Tausenden Einträgen.
• Beobachten, wenn die Zahl im Gleichschritt mit einer Ihrer Änderungen steigt: ein neuer Kategoriefilter, eine Anzeigenkampagne, ein neues AMP-Template. Prüfen Sie einige Beispiele, bestätigen Sie das Muster, fertig.
• Beheben, wenn eine Seite hier erscheint, die indexiert werden soll. Das bedeutet meist, dass ein Template auf vielen Seiten gleichzeitig das falsche Canonical schreibt.
• Untersuchen, wenn die Zahl ohne eine Änderung springt, die Sie benennen können. Öffnen Sie die Beispiele: Eine neue Quelle von Parameter-Links ist harmlos, Artikel-, Produkt- oder Sprachpfade dagegen deuten auf ein Template.

flowchart TD
    A["URL als alternative Seite gelistet"] --> B{"Soll diese URL eigenständig in der Suche erscheinen?"}
    B -->|nein| C{"Nennt ihr Canonical die Version, die indexiert werden soll?"}
    C -->|ja| D["Belassen: Der Status ist erwartet"]
    C -->|nein| E["Canonical auf die richtige Version richten"]
    B -->|ja| F{"Ist es eine übersetzte Seite?"}
    F -->|ja| G["Beheben: Canonical auf sich selbst, in der eigenen Sprache"]
    F -->|nein| H{"Ist es Seite 2 oder später einer Serie?"}
    H -->|ja| I["Beheben: Jede Seite mit Canonical auf sich selbst"]
    H -->|nein| J["Das Template korrigieren, das das Canonical schreibt"]

Die 4 Muster, die echte Seiten hierher bringen, jedes davon ein Fall zum Beheben:

1. Jede Seite zeigt auf die Startseite. Ein Theme oder ein eingebundener Header bildet das Canonical aus der Website-Adresse statt aus der Adresse der aktuellen Seite. Artikel- und Produktseiten verlangen dann, in die Startseite aufzugehen, und wenn Google zustimmt, landen sie hier.
2. Paginierte Seiten zeigen auf Seite 1. Laut Googles Dokumentation zur Paginierung soll die erste Seite einer Serie nicht als Canonical verwendet werden; jede Seite sollte ihr eigenes haben.
3. Übersetzte Seiten zeigen auf die Originalsprache. Googles Dokumentation zur Kanonisierung behandelt Sprachversionen nur dann als Duplikate, wenn der Hauptinhalt in derselben Sprache ist, und verlangt ein Canonical in derselben Sprache. Eine französische Seite, die auf ihr englisches Gegenstück kanonisiert ist, entfernt die französische Seite aus dem Index. Das vollständige Muster beschreibt unsere Analyse von Canonical-Tags, die über Sprachgrenzen hinweg zeigen.
4. Varianten zeigen auf die falsche übergeordnete Seite. Eine Farb- oder Standortseite mit eigener Suchnachfrage, die auf eine allgemeine übergeordnete Seite kanonisiert ist, weil eine Regel auf einen ganzen Seitentyp angewendet wurde.

So bestätigen Sie, welcher Fall vorliegt

Die Search Console zeigt Ihnen, welche URLs betroffen sind. Die Ursache bestätigen Sie in 4 Schritten.

1. Die Beispiele nach Mustern gruppieren. Öffnen Sie den Grund im Bericht zur Seitenindexierung und exportieren Sie die Beispiele. Laut Dokumentation sind die Beispiele auf 1.000 Einträge begrenzt und enthalten möglicherweise nicht jede URL; behandeln Sie den Export also als Stichprobe. Sortieren Sie nach Pfad und Parameter: Eine Liste aus ?utm_- und ?sort=-URLs ist eine Liste zum Belassen; Blogbeiträge, Produkte oder /fr/-Pfade sind die, die Sie untersuchen sollten.

2. Eine URL aus jeder verdächtigen Gruppe prüfen. Lesen Sie in der URL-Prüfung unter „Seitenindexierung“ die Felder „Vom Nutzer angegebene kanonische URL“ und „Von Google ausgewählte kanonische URL“. Bei diesem Status nennen beide normalerweise das Canonical-Ziel, nicht die geprüfte URL. Laut Dokumentation kann der Live-Test nicht vorhersagen, welche URL als kanonisch ausgewählt wird; lesen Sie diese Felder daher im indexierten Ergebnis.

3. Das Canonical-Ziel prüfen. Es sollte indexiert sein, mit Status 200 antworten, kein noindex tragen und sich selbst als kanonisch nennen. Ein Ziel, das weiterleitet oder auf noindex steht, widerspricht dem Canonical, das darauf zeigt, und Google wählt dann womöglich eine andere URL; der Leitfaden zur Indexierbarkeit von Seiten erklärt, wie diese Signale zusammenwirken.

4. Das Canonical im HTML lesen, das Ihr Server ausliefert. Googles Dokumentation verlangt, dass JavaScript das Canonical-Link-Element nicht verändert. Vergleichen Sie daher das Roh-HTML mit dem, was der Browser zeigt:

# Canonical tag in the HTML the server returns
curl -s "https://example.com/blog/my-post/" | grep -Eio '<link[^>]*rel=.?canonical[^>]*>'

# Canonical sent as an HTTP header (used for PDFs and other non-HTML files)
curl -sI "https://example.com/files/guide.pdf" | grep -i '^link:'

Nennen Roh-HTML und gerenderte Seite verschiedene URLs, schreibt ein Skript das Tag nach dem Laden um. Bei 34 externen Websites, bei denen SEOReport zwischen Mai und Oktober 2026 das Roh-HTML des Servers mit der gerenderten Startseite verglichen hat, war bei 6 (18 %) mindestens eines der Elemente Title, Meta-Description, Canonical oder H1 erst nach dem Rendering vorhanden. Der Leitfaden zum JavaScript-Rendering zeigt, wie Sie diese Elemente in die Serverantwort verlagern.

So beheben Sie die einzelnen Fälle

Im Prinzip ist die Lösung immer dieselbe: Jede Seite, die indexiert werden soll, nennt sich selbst als kanonisch, mit einer absoluten URL im <head>, und jede Variante zeigt auf diese Seite.

<!-- On https://example.com/fr/tarifs/ : the French page names itself -->
<link rel="canonical" href="https://example.com/fr/tarifs/" />

<!-- On https://example.com/shoes/?sort=price : the variant names the main page -->
<link rel="canonical" href="https://example.com/shoes/" />

Für die 4 Fälle: Bilden Sie das Canonical aus dem eigenen Pfad der Seite, nicht aus der Basisadresse der Website; geben Sie jeder Seite einer Serie ihr eigenes Canonical; lassen Sie jede Sprachversion sich selbst nennen und überlassen Sie die Verknüpfung der Versionen hreflang (der Leitfaden zur hreflang-Implementierung enthält das Markup); und geben Sie Varianten mit eigener Suchnachfrage ein selbstreferenzierendes Canonical.

Gleichen Sie dann die unterstützenden Signale an, denn Google rät davon ab, über verschiedene Methoden unterschiedliche Canonical-Anweisungen zu senden: Listen Sie in Ihrer XML-Sitemap nur kanonische URLs, und verlinken Sie intern auf die kanonische URL statt auf eine Variante. Ein selbstreferenzierendes Canonical auf jeder indexierbaren Seite ist die Grundlage. Bei 45 externen Websites, die SEOReport zwischen Mai und Oktober 2026 geprüft hat, lieferten 14 (31 %) eine Startseite ohne Canonical-Tag im vom Server ausgelieferten HTML aus.

Zwei Änderungen sollten Sie bei unbedenklichen Einträgen vermeiden: noindex hinzufügen (siehe Fragen unten) und Varianten per robots.txt blockieren. Eine Sperre in der robots.txt verhindert, dass Google das Canonical überhaupt liest, und laut Googles Dokumentation können gesperrte URLs trotzdem ohne ihren Inhalt indexiert werden.

So prüfen Sie die Korrektur

Sobald die Template-Änderung live ist, prüfen Sie eine korrigierte URL, führen den Live-Test aus, um zu bestätigen, dass Google sie abrufen kann, und nutzen „Indexierung beantragen“ für einige wichtige Seiten. Nach dem erneuten Crawl sollte „Vom Nutzer angegebene kanonische URL“ im indexierten Ergebnis die Seite selbst zeigen, und die Seite sollte diesen Status verlassen.

Bei einer Korrektur, die viele URLs betrifft, nutzen Sie im Bericht zur Seitenindexierung beim Grund „Fehlerbehebung überprüfen“. Laut Googles Dokumentation dauert die Validierung in der Regel bis zu etwa 2 Wochen und kann länger dauern. Rechnen Sie damit, dass die Zahl über Tage bis Wochen sinkt, während Google neu crawlt, aber erwarten Sie auf einer Website mit Tracking-Links, Filtern oder AMP-Seiten nicht, dass sie 0 erreicht. Das Ziel ist eine kleinere Zahl, die aus den richtigen URLs besteht.

Was eine vollständige Diagnose zu diesem Status prüft

Eine vollständige SEOReport-Diagnose sieht nicht, welche URLs Google als Alternativen gruppiert hat; das zeigt nur die Search Console. Sie prüft die Seite, die Sie steuern: ob das Canonical-Ziel Ihrer Startseite in Ordnung ist (keine Weiterleitung, indexierbar, kanonisch auf sich selbst), ob sich das Canonical der Startseite zwischen Smartphone und Desktop oder zwischen Roh-HTML und gerenderter Seite unterscheidet, ob Seiten in anderen Sprachen ein Canonical tragen, das nicht auf sie selbst zeigt, und Canonical-Ziele, auf die keine der untersuchten Seiten verlinkt. Jeder Befund nennt die gefundenen URLs. Unser Leitfaden zu Canonical-Tags erklärt, wie Canonical-Tags funktionieren.

Häufige Fragen

Schadet eine große Zahl alternativer Seiten meiner Website?

Nein. Eine große Zahl aus Parametern, Filtern oder AMP-Seiten spiegelt nur wider, wie viele URL-Varianten es gibt. Relevant wird sie, wenn sie Seiten enthält, die indexiert werden sollen.

Sollte ich diese URLs auf noindex setzen, um den Bericht aufzuräumen?

Nein. Das Canonical-Tag hält sie bereits aus dem Index heraus, und Google empfiehlt für die Wahl einer kanonischen Seite innerhalb einer Website rel="canonical" statt noindex. Ein zusätzliches noindex fügt nur eine widersprüchliche Anweisung hinzu. Der Artikel zu URL als „noindex“ markiert erklärt, wann noindex das richtige Werkzeug ist.

Warum steht meine übersetzte Seite hier, wenn die Search Console Seiten in anderen Sprachen nicht als Alternativen erkennt?

Weil ihr Canonical-Tag eine andere URL nennt, meist die Seite in der Originalsprache, und Google dem gefolgt ist. Ändern Sie ihr Canonical so, dass es auf sie selbst zeigt.

Warum erscheinen hier URLs, auf die ich nie verlinkt habe?

Google findet URLs über Links an beliebigen Stellen, auch in Anzeigen, E-Mails und Social-Media-Beiträgen, die Tracking-Parameter anhängen. Diese URLs liefern das Canonical-Tag Ihrer Seite aus, und Google führt sie deshalb mit der Haupt-URL zusammen.

Wie lange dauert es nach einer Korrektur, bis die Seite diesen Status verlässt?

Google muss die Seite erneut crawlen und das neue Canonical verarbeiten, was Tage bis Wochen dauert. „Indexierung beantragen“ bittet Google, einzelne wichtige Seiten zu crawlen, und „Fehlerbehebung überprüfen“ verfolgt die ganze Gruppe.