Duplikat – vom Nutzer nicht als kanonisch festgelegt: So beheben Sie es

„Duplikat – vom Nutzer nicht als kanonisch festgelegt“ bedeutet, dass Google eine URL als Kopie einer anderen Seite eingestuft, auf ihr keine kanonische URL gefunden und selbst entschieden hat, welche Version in der Suche erscheint. Ist die gemeldete URL eine Variante, auf der niemand landen sollte, etwa eine Kopie mit Tracking-Parameter oder per HTTP, und hat Google Ihre bevorzugte Seite gewählt, ist das genau das gewünschte Ergebnis und erfordert nichts. Handlungsbedarf besteht, wenn Google eine URL gewählt hat, die Sie nicht in den Ergebnissen haben wollen, oder wenn die gemeldete URL die Seite ist, die eigentlich ranken soll.

Was der Status laut Google bedeutet

Der Status steht im Bericht zur Seitenindexierung in der Tabelle mit den Gründen, warum Seiten nicht indexiert sind; in der englischen Oberfläche heißt er „Duplicate without user-selected canonical“. Laut Googles Dokumentation zum Bericht zur Seitenindexierung (Stand: Oktober 2026) ist die Seite ein Duplikat einer anderen Seite, gibt aber keine bevorzugte kanonische Seite an. Derselbe Eintrag sagt, dass Google die gemeldete URL nicht in der Suche ausliefert, beschreibt das als beabsichtigtes Verhalten und nicht als Fehler und nennt 2 Abhilfen: die kanonische URL ausdrücklich angeben, wenn Google die falsche URL gewählt hat, oder den Inhalt deutlich unterscheidbar machen, wenn die Seite in Wahrheit kein Duplikat ist.

„Duplikat“ ist Googles Urteil, nachdem ähnliche Seiten zu einem Cluster gruppiert wurden. „Vom Nutzer nicht als kanonisch festgelegt“ bedeutet, dass die gemeldete URL Google keine lesbare kanonische Angabe geliefert hat. Das unterscheidet diesen Status von seinen 2 Nachbarn:

Googles Dokumentation zur Kanonisierung ergänzt, dass eine angegebene kanonische URL ein Hinweis ist, keine Regel: Google berücksichtigt vor der Entscheidung weiterhin Weiterleitungen, Sitemap-Einträge und HTTPS.

Woher die doppelten URLs stammen

Fast jede gemeldete URL ist eine Seite, die unter mehr als einer Adresse erreichbar ist. Laut Googles Dokumentation zur URL-Struktur unterscheidet Google bei URLs zwischen Groß- und Kleinschreibung, und laut einem Blogbeitrag von Google Search Central zu abschließenden Schrägstrichen (April 2010) behandelt Google /shoes und /shoes/ als 2 verschiedene URLs (die Website-Root ist die Ausnahme). Jeder der folgenden Unterschiede erzeugt eine neue URL für denselben Inhalt.

• Kein Canonical auf der bevorzugten Seite. Gibt Ihre Seite keine kanonische URL an, tragen auch ihre Varianten keine, sodass jede Kopie, die Google findet, in diesem Status landet. WordPress gibt im Kern zum Beispiel nur auf einzelnen Beiträgen und Seiten ein Canonical-Tag aus; Archiv-, Kategorie-, Tag- und Blog-Startseitenansichten erhalten keines, sofern kein Theme oder Plugin eines ergänzt.
• Protokoll- und Host-Varianten. http:// und https:// oder www und die Domain ohne www, die alle mit Status 200 antworten, statt auf eine Adresse weiterzuleiten.
• Abschließender Schrägstrich und Groß-/Kleinschreibung. /shoes, /shoes/ und /Shoes/ liefern dieselbe Seite aus.
• Parameter und alternative Ansichten. Tracking-Parameter wie ?utm_source=, Sortier- und Filteroptionen, Session-IDs sowie Druck- oder Rasteransichten desselben Inhalts.
• Versehentliche Kopien. Eine für Crawler offene Demoversion der Website, die Googles Dokumentation ausdrücklich als Ursache nennt, ein Staging-Host oder eine alte Domain, die noch dieselben Seiten ausliefert.
• Ein Canonical, das Google nicht lesen kann. Google akzeptiert rel="canonical" nur im <head>, und laut Googles Dokumentation zu Seiten-Metadaten führt ein dort ungültiges Element wie iframe oder img dazu, dass Google das Ende des Heads annimmt und alles Folgende ignoriert. Ein Canonical nach einem solchen Element fehlt damit praktisch.
• Seiten, die Sie für verschieden halten. Produktfarben mit identischer Beschreibung oder Standortseiten, die bis auf den Städtenamen jeden Satz teilen.

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, und 1 lieferte mehr als eines aus. In derselben Stichprobe leiteten 2 von 45 (4 %) HTTP nicht auf HTTPS weiter.

Ist das ein Problem? Beheben, belassen oder beobachten

Die Einschätzung hängt davon ab, welche URL Google ausgewählt hat und ob Sie die gemeldete URL in der Suche haben wollen.

flowchart TD
    A["URL gemeldet: Duplikat – vom Nutzer nicht als kanonisch festgelegt"] --> B["URL-Prüfung: von Google ausgewählte kanonische URL ablesen"]
    B --> C{"Ist Googles Wahl die URL, die Sie in der Suche wollen?"}
    C -->|ja| D{"Verweisen Ihre Links oder Ihre Sitemap auf die gemeldete URL?"}
    D -->|nein| E["Belassen: Die Kopie wird wie vorgesehen gefiltert"]
    D -->|ja| F["Links und Sitemap auf die bevorzugte URL umstellen"]
    C -->|nein| G{"Ist der Inhalt wirklich identisch?"}
    G -->|nein| H["Seiten deutlich unterscheidbar machen"]
    G -->|ja| I["Bevorzugte URL angeben: Canonical, Weiterleitungen, Links, Sitemap"]
    F --> J["Live-URL testen, dann Fehlerbehebung überprüfen"]
    H --> J
    I --> J

So bestätigen Sie, welche Ursache zutrifft

1. Die Beispiele nach Mustern gruppieren. Die Beispieltabelle zeigt höchstens 1.000 Zeilen und listet möglicherweise nicht jede betroffene URL. Suchen Sie daher nach Mustern (alle http://, alle ?utm_, alle in Großbuchstaben), statt zu zählen.
2. Eine gemeldete URL prüfen. Vergleichen Sie in der URL-Prüfung „Vom Nutzer angegebene kanonische URL“ mit „Von Google ausgewählte kanonische URL“. Bei diesem Status zeigt das indexierte Ergebnis als vom Nutzer angegebene kanonische URL meist „Keine“. Zeigt „Live-URL testen“ dort inzwischen eine kanonische URL, wurde sie nach Googles letztem Crawl dieser URL ergänzt.
3. Die 2 URLs Zeichen für Zeichen vergleichen. Protokoll, Host, Groß-/Kleinschreibung, abschließender Schrägstrich und Parameter. Der Unterschied benennt die Ursache.
4. Herausfinden, wo Google der Variante begegnet ist. Im Prüfergebnis zeigt „Verweisende Seite“ eine Seite, über die Google die URL möglicherweise gefunden hat, und „Sitemaps“ listet jede Sitemap, die sie enthält.
5. Die Varianten so abrufen, wie ein Crawler es tut. Ein Browser verbirgt Weiterleitungen, die rohe Antwort nicht.

# Status code and redirect target for each variant of one page
for u in http://example.com/shoes/ https://example.com/shoes/ \
         https://www.example.com/shoes https://www.example.com/Shoes/ \
         "https://www.example.com/shoes/?utm_source=newsletter"; do
  curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}  $u\n" "$u"
done

# The canonical tag in the HTML the server returns, before any JavaScript runs
curl -s https://www.example.com/shoes/ | grep -io '<link[^>]*canonical[^>]*>'

Jede Variante sollte mit 301 auf die bevorzugte URL antworten oder mit 200 und einem Canonical, das sie benennt. Eine Variante, die mit 200 und ohne Canonical antwortet, kann immer wieder in diesem Status landen.

So beheben Sie die einzelnen Ursachen

Fehlendes Canonical. Geben Sie jeder indexierbaren Seite ein selbstreferenzierendes Canonical mit absoluter URL, möglichst weit oben im <head> des HTML, das der Server ausliefert. Googles Dokumentation empfiehlt sowohl die selbstreferenzierende Form als auch absolute URLs.

<head>
  <meta charset="utf-8">
  <link rel="canonical" href="https://www.example.com/shoes/">
  <title>Trail running shoes</title>
</head>

Bilden Sie das Canonical aus der eigenen bevorzugten Adresse der Seite, nie aus der angefragten URL. Ein Template, das die Anfrage zurückgibt, macht /shoes/?utm_source=newsletter zu seinem eigenen Canonical, und die Varianten wandern dann eher in den Status „Duplikat – Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt“, statt zusammengeführt zu werden.

Protokoll- und Host-Varianten. Leiten Sie jede Variante mit einer einzigen 301-Weiterleitung um, die Pfad und Query-String beibehält. Unter nginx sieht die HTTP-Seite so aus; geben Sie dem HTTPS-Serverblock für die Domain ohne www dieselbe return-Zeile.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

Google bevorzugt HTTPS-Seiten als kanonisch, sofern nichts dagegen spricht, etwa ein ungültiges Zertifikat oder eine Weiterleitung von HTTPS zurück auf HTTP. Leiten Sie jede Variante in einem Schritt auf die endgültige Adresse; unser Leitfaden zu Weiterleitungsketten zeigt, wie sich Protokoll-, Host- und Slash-Regeln zu Ketten aufschichten, wenn jede einzeln hinzugefügt wird.

Abschließender Schrägstrich und Groß-/Kleinschreibung. Entscheiden Sie sich für eine Schreibweise, leiten Sie die andere per 301 darauf um und lassen Sie das CMS Links in dieser Schreibweise erzeugen. Googles URL-Richtlinien empfehlen eine einheitliche Groß-/Kleinschreibung.

Parameter und alternative Ansichten. Ein korrektes selbstreferenzierendes Canonical auf der sauberen URL deckt Tracking-Parameter ab, denn jede getaggte Kopie benennt dann die saubere Seite. Verlinken Sie intern nicht mehr auf Parameter-URLs, verlagern Sie Session-IDs in Cookies und geben Sie Druck- und alternativen Ansichten ein Canonical auf die Hauptseite. Verstecken Sie Duplikate nicht per robots.txt: Laut Google kann eine blockierte URL trotzdem ohne ihren Inhalt indexiert werden, und Google kann das Canonical auf einer Seite, die es nicht abrufen darf, nicht lesen. Google rät außerdem davon ab, noindex zur Auswahl einer kanonischen Seite innerhalb einer Website zu verwenden, und das Tool zum Entfernen von URLs blendet jede Version einer URL aus.

Versehentliche Kopien. Schützen Sie Staging-Hosts mit einem Login; leiten Sie alte Domains Seite für Seite weiter.

Seiten, die keine Duplikate sind. Geben Sie jeder Seite Inhalte, die den anderen fehlen: technische Daten, Verfügbarkeit, lokale Details. Googles Dokumentation zur Fehlerbehebung weist darauf hin, dass Seiten nach der Änderung noch bis zu 2 Wochen in einem Duplikat-Cluster bleiben können.

Alle Signale angleichen. Listen Sie in Ihrer XML-Sitemap nur bevorzugte URLs und verlinken Sie intern auf dieselbe URL, die Ihr Canonical nennt. Google warnt davor, in einer Sitemap eine URL und in rel="canonical" eine andere anzugeben. Unsere Analyse von Sitemaps, die ihren Seiten widersprechen, und der Leitfaden zu Canonical-Tags behandeln die übrigen Konflikte.

So prüfen Sie die Korrektur

1. Führen Sie „Live-URL testen“ für eine gemeldete URL und ihre bevorzugte Seite aus. Der Live-Test zeigt die vom Nutzer angegebene kanonische URL; laut Google kann er nicht vorhersagen, welche URL Google auswählen wird.
2. Nutzen Sie „Indexierung beantragen“ für einige wichtige bevorzugte Seiten; es gibt ein Tageslimit.
3. Klicken Sie beim Status auf „Fehlerbehebung überprüfen“, sobald jedes Vorkommen des Musters behoben ist. Laut Googles Dokumentation dauert die Validierung in der Regel bis zu etwa 2 Wochen, manchmal deutlich länger, und sie bricht ab, wenn Google noch ein Vorkommen findet.
4. Rechnen Sie damit, dass die URLs den Status wechseln statt zu verschwinden. Varianten, die jetzt weiterleiten, erscheinen als „Seite mit Weiterleitung“; Varianten mit einem Canonical, das Google akzeptiert, erscheinen meist unter „Alternative Seite mit richtigem kanonischen Tag“. Beides sind normale Zustände für eine Kopie.
5. Prüfen Sie Ihre bevorzugten Seiten nach einigen Wochen erneut und bestätigen Sie, dass die „Von Google ausgewählte kanonische URL“ der von Ihnen angegebenen URL entspricht.

Die Search Console zeigt Ihnen, welche URLs Google als Kopien eingestuft hat, aber nicht, welche websiteweite Einstellung sie immer wieder erzeugt. Eine vollständige SEOReport-Diagnose prüft diese websiteweiten Quellen von außen: www und die Domain ohne www, die beide die Website ausliefern, HTTP ohne Weiterleitung auf HTTPS, uneinheitliche Slash-Schreibweise in Sitemap-, Canonical- und hreflang-URLs sowie eine Startseite ohne oder mit mehr als einem Canonical. Außerdem benennt sie Beinahe-Duplikate unter den Artikeln. Parameter-Kopien und Unterseiten ohne Canonical erfordern weiterhin die URL-Prüfung und die obigen Kontrollen. Die Varianten jedes Templates zu prüfen, ist Arbeit auf Website-Ebene, und deshalb schafft eine einzelne KI-Chat-Sitzung sie selten.

Häufige Fragen

Schadet dieser Status meinen Rankings?

Google bezeichnet ihn als beabsichtigtes Verhalten, und ein gewisses Maß an doppeltem Inhalt ist normal. Kosten entstehen, wenn Google eine URL auswählt, die Sie nicht in den Ergebnissen haben wollen, oder wenn Crawling-Zeit in Kopien fließt. Google weist darauf hin, dass die kanonische Seite am regelmäßigsten gecrawlt wird und Duplikate seltener.

Warum listet der Bericht URLs, auf die meine Website nie verlinkt?

Google findet URLs über externe Links, getaggte Kampagnen, alte Sitemaps und frühere Versionen Ihrer Website. Ein korrektes Canonical auf der sauberen URL erledigt diese Kopien, egal woher sie stammen.

Sollten die doppelten URLs nach der Korrektur aus der Search Console verschwinden?

Meist bleiben sie unter einem anderen Status gelistet, wie die Prüfschritte oben beschreiben. Eine nicht indexierte URL ist nur relevant, wenn Sie sie in der Suche haben wollen; das ist derselbe Test wie bei Gecrawlt – zurzeit nicht indexiert.

Wie heißt dieser Status in anderen Sprachen der Search Console?

Googles lokalisierte Hilfeseiten (Stand: Oktober 2026) nennen ihn auf Deutsch „Duplikat – vom Nutzer nicht als kanonisch festgelegt“, auf Spanisch „Duplicada: el usuario no ha indicado ninguna versión canónica“ und auf Französisch „Page en double sans URL canonique sélectionnée par l'utilisateur“. Bedeutung und Lösungen sind in jeder Sprache identisch.