Duplicate Content nach Moz: Welcher der vier Fixes gehört zu welchem Duplikat?

Duplicate Content ist nach der Definition von Moz Inhalt, der im Internet an mehr als einer Stelle erscheint, wobei eine Stelle über eine eigene, eindeutige URL definiert ist. Genau in diesem Zusatz steckt die ganze Praxis: Das Problem ist nie der Text allein, sondern das Paar aus Text und URL.

Deutschsprachige Ratgeber definieren den Begriff nahezu deckungsgleich. vioma schreibt, Duplicate Content trete auf, wenn die gleichen Inhalte auf verschiedenen URL aufrufbar sind. Die Haufe Akademie spricht von Inhalten, die innerhalb einer oder mehrerer Domains mehrfach vorkommen. Aufgesang fasst es als Inhalte, die auf mehreren Seiten innerhalb einer Website oder auf verschiedenen Websites vorkommen. Seokratie ergänzt die Folge: Duplicate Content verursacht Suchmaschinen wie Google Probleme, und die Inhalte der betroffenen Seite werden dort schlechter gefunden.

Alle diese Quellen beantworten dieselbe Frage: Was ist es? Offen bleibt die Frage, die im Audit tatsächlich ansteht: Welcher Fix gehört zu diesem konkreten Duplikat, und woran erkenne ich den Typ? Moz listet vier Lösungswege auf, den 301-Redirect, rel="canonical", Meta Robots noindex sowie die bevorzugte Domain und das Parameter-Handling in der Google Search Console. Diese Seite ordnet sie zu.

Die eine Frage, die den Typ bestimmt

Die Sortierung nach Textähnlichkeit hilft bei der Zuordnung nicht. vioma unterscheidet Exact Duplicate Content, Partial Duplicate Content und Near Duplicate Content. Das beschreibt den Grad der Übereinstimmung sauber, führt aber zu keiner Maßnahme: Zwei exakt identische Seiten können je nach Zweck eine 301 oder ein Canonical brauchen, zwei nur teilweise identische Filterseiten können indexierbar, kanonisiert oder auf noindex gesetzt werden.

Die Frage, die den Typ bestimmt, lautet stattdessen:

Wird diese zweite URL gebraucht, und von wem?

Daraus ergibt sich ein Entscheidungsbaum mit drei Verzweigungen und einer Querschnittsregel:

Liefern mehrere URLs denselben Hauptinhalt?
  |
  +-- Nein, nur eine URL wird gebraucht ............... 301-Weiterleitung
  |
  +-- Ja, die Variante wird gebraucht
         |
         +-- von Nutzern UND als Suchergebnis
         |      -> eine Hauptversion bestimmen ........ rel="canonical"
         |
         +-- nur von Nutzern, nicht als Suchergebnis
                -> aus dem Index nehmen ............... noindex

Quer dazu: Entstehen die Varianten massenhaft nach URL-Muster?
  -> Regel je Parameterklasse statt Einzelfall ........ Parameter-Konzept

Die vierte Stufe ist keine fünfte Auszeichnung, sondern die Entscheidung, den Fix nicht pro URL, sondern pro URL-Klasse zu treffen.

Die vier Fixes im direkten Vergleich

Die vier Maßnahmen sind nicht austauschbar. Eine 301 verändert das Ziel für den Nutzer. Ein Canonical lässt die Variante bestehen und ist ein Hinweis, kein Befehl. noindex schließt eine Seite aus dem Index aus, konsolidiert aber nicht automatisch alle Signale auf einer anderen URL. Und eine Parameterregel ist eine Entscheidung über hunderte URLs auf einmal.

Warum die richtige Zuordnung zählt, zeigt die Risikoliste von WEVENTURE: Ranking- und Sichtbarkeitsverlust, verwässertes Crawl-Budget, Indexierungsprobleme, Verlust von Backlink-Wert und schlechte User Experience. Diese fünf Risiken treffen nicht gleichmäßig zu. Crawl-Budget und Indexierung leiden vor allem unter Typ 4, der Backlink-Wert vor allem unter Typ 1. Wer den Typ kennt, weiß auch, welches Risiko er gerade abstellt.

Typ 1: Protokoll-, Host- und Pfadvarianten

Moz nennt HTTP gegenüber HTTPS sowie WWW gegenüber non-WWW ausdrücklich als Entstehungsweg. In dieselbe Diagnoseklasse gehören abweichende Schreibweisen des Pfads.

http://example.de/produkt
https://example.de/produkt
https://www.example.de/produkt
https://www.example.de/Produkt/

Liefern alle vier Adressen denselben Inhalt, sind das keine vier Seiten, sondern vier technische Zugänge zu einer Ressource.

Passender Fix: 301-Weiterleitung.

So erkennen Sie den Typ im Audit:

• Titel, H1 und Hauptinhalt stimmen überein, es unterscheiden sich nur Protokoll, Host, Slash oder Groß- und Kleinschreibung.
• Jede Variante antwortet mit Statuscode 200.
• Interne Links verweisen gemischt auf mehrere Formen.
• Canonical-Angabe und XML-Sitemap nennen nicht dieselbe Zielversion.
• Backlinks verteilen sich über mehrere Schreibweisen derselben Seite.

Legen Sie genau eine verbindliche Form fest und leiten Sie alle übrigen dorthin. Ein Canonical wäre hier der schwächere Fix: Wenn eine Variante keinen eigenen Zweck hat, soll sie gar nicht erst als eigenes Ziel erreichbar bleiben. Genau diesen Fall deckte früher die Einstellung der bevorzugten Domain in der Search Console ab, die Moz noch aufführt. Google bietet sie heute nicht mehr an, weshalb die Entscheidung serverseitig über Weiterleitungen fallen muss.

Typ 2: Notwendige Darstellungs- und Navigationsvarianten

Manche Systeme brauchen mehrere URLs, obwohl der Hauptinhalt identisch bleibt: Druckansichten, Produkte in mehreren Kategoriepfaden, Sortierungen, kampagnenbezogene Zieladressen, erlaubt übernommene Inhalte.

/ratgeber/beispiel/
/ratgeber/beispiel/?druck=1
/produkte/schuhe/modell-a/
/marken/hersteller/modell-a/

Passender Fix: rel=“canonical”.

<link rel="canonical" href="https://www.example.de/ratgeber/beispiel/">

So erkennen Sie den Typ im Audit:

• Mehrere URLs zeigen denselben zentralen Inhalt.
• Jede Variante erfüllt einen nachvollziehbaren Darstellungs- oder Navigationszweck.
• Eine Weiterleitung würde eine gebrauchte Funktion entfernen.
• Externe Links oder Kampagnen rufen die Varianten weiterhin auf.
• Für die Suche ist dennoch nur eine Version sinnvoll.

Auch die Hauptseite sollte ein selbstreferenzielles Canonical tragen. Und weil das Canonical ein Hinweis bleibt: Verlinken Sie intern ausschließlich auf die kanonische Adresse und führen Sie nur diese in der Sitemap. Widersprechen sich interne Links, Sitemap und Canonical, wählt Google im Zweifel eine andere URL aus als die von Ihnen gewünschte.

Typ 3: Seiten mit Nutzwert, aber ohne Suchwert

Eine Seite kann für Besucher sinnvoll und für den Index ungeeignet sein. Interne Suchergebnisse sind der Klassiker, dazu kommen persönliche Übersichten, Prozessschritte und dünne Filterkombinationen.

Passender Fix: Meta Robots noindex.

<meta name="robots" content="noindex,follow">

So erkennen Sie den Typ im Audit:

• Die Seite erfüllt eine Funktion, hat aber kein stabiles eigenes Suchthema.
• Viele Seiten unterscheiden sich nur durch Listen, Auswahlwerte oder Nutzereingaben.
• Titel und Überschriften wiederholen sich über große URL-Mengen.
• Die Seiten stehen trotz geringer Suchnachfrage im Index.

Zwei Abgrenzungen sind wichtig. Wurde eine URL vollständig ersetzt, ist die 301 konsequenter als noindex. Und noindex sollte nicht routinemäßig mit einem Canonical auf eine fremde URL kombiniert werden: Das eine fordert Ausschluss, das andere Zusammenführung. Damit die Anweisung überhaupt ankommt, muss die Seite crawlbar bleiben. Eine per robots.txt blockierte Seite kann ihr eigenes noindex nicht mitteilen.

Typ 4: Parameter erzeugen URL-Massen

Aus wenigen Funktionen entstehen hier sehr viele Kombinationen:

/kategorie/schuhe/?farbe=schwarz
/kategorie/schuhe/?sort=preis
/kategorie/schuhe/?farbe=schwarz&sort=preis
/kategorie/schuhe/?utm_source=newsletter

Passender Fix: ein Parameter-Konzept, also eine Regel je Parameterklasse.

• Tracking-Parameter verändern den Inhalt nicht. Interne Links kommen ohne sie aus, die Varianten kanonisieren auf die saubere URL.
• Sortierparameter ändern nur die Reihenfolge und werden auf die unsortierte Hauptversion kanonisiert.
• Filterparameter verändern den Bestand. Hier ist zu entscheiden, ob die Kombination eine eigene Nachfrage bedient. Eine gepflegte Seite für schwarze Laufschuhe darf indexierbar sein, die Kombination aus Farbe, Größe, Lieferzeit und Preisbereich bekommt noindex.
• Session- und technische Parameter gehören gar nicht erst in crawlbare Links, sonst entstehen praktisch unbegrenzt neue URLs.

So erkennen Sie den Typ im Audit:

• Die Zahl gefundener URLs liegt deutlich über der Zahl geplanter Seiten.
• Dieselben Parameter tauchen in vielen Verzeichnissen auf.
• Parameter lassen sich in beliebiger Reihenfolge kombinieren.
• Titel, H1 und Inhalt bleiben trotz wechselnder URL nahezu gleich.
• Indexierte URLs enthalten Tracking-, Sortier- oder Sessionwerte.

Das von Moz genannte URL-Parameter-Tool der Search Console existiert heute nicht mehr. Die Steuerung liegt damit vollständig bei Ihnen: interne Verlinkung auf parameterfreie Haupt-URLs, Canonicals, gezieltes noindex und eine konsistente URL-Erzeugung.

Sonderfall: gescrapte und kopierte Inhalte

Als dritten Entstehungsweg nennt Moz gescrapte oder kopierte Inhalte. Das Duplikat liegt dann nicht in Ihrer Website, sondern auf fremder Domain, und keiner der vier Fixes greift dort ohne Zugriff.

Wie aussichtslos die manuelle Verfolgung ist, hat SEOmoz schon im Illustrated Guide to Duplicate Content in the Search Engines vom 12.03.2007 beziffert: Allein das Verfolgen aller Kopien eigener Inhalte im Web hätte mindestens zwei 40-Stunden-Wochen Arbeit bedeutet. Die Konsequenz ist deshalb nicht Jagd, sondern ein eindeutiges Ursprungssignal auf der eigenen Seite.

Bei erlaubter Übernahme setzt die veröffentlichende Website ein domainübergreifendes Canonical auf das Original oder publiziert nur einen Auszug mit Verweis auf die Ursprungsseite. Bei unerlaubtem Scraping prüfen Sie zuerst Ihre eigene URL: indexierbar, selbstreferenzielles Canonical, eindeutig intern verlinkt, früh in der Sitemap. Ein noindex auf der eigenen Originalseite wäre hier der teuerste Fehlgriff.

Die vier häufigsten Fehlzuordnungen

1. Canonical statt 301 bei Protokoll- und Host-Varianten. Die überflüssige URL bleibt erreichbar, sammelt weiter interne Links und bleibt ein Kandidat für Googles eigene Auswahl.
2. noindex statt 301 bei ersetzten Seiten. Die Seite fällt aus dem Index, ihre Signale laufen ins Leere statt auf den Nachfolger.
3. robots.txt statt noindex. Blockierte URLs können weiterhin als Treffer auftauchen, nur dass die Anweisung zum Ausschluss nie gelesen wird.
4. Einzelfix statt Parameterregel. Jede von Hand kanonisierte Filter-URL ist in dem Moment veraltet, in dem eine neue Kombination entsteht.

Vom Site-Audit zur Entscheidung

Moz nennt zum Auffinden doppelter Inhalte zwei Wege: ein Site-Audit und die Prüfung der indexierten Seiten. Beide liefern Listen, keine Entscheidungen. Erfassen Sie deshalb pro URL-Cluster:

• URL und Statuscode
• indexierbar oder noindex
• Canonical-Ziel und die von Google tatsächlich gewählte kanonische URL
• Zahl und Ziel interner Links
• Aufnahme in der XML-Sitemap
• Protokoll, Host, verwendete Parameter
• Übereinstimmung von Titel, H1 und Hauptinhalt

Anschließend bekommt jedes Cluster genau eine Absicht: Nur eine URL soll existieren, also 301. Mehrere müssen erreichbar bleiben, eine ist die Hauptversion, also Canonical. Die Seite wird gebraucht, soll aber nicht ranken, also noindex. Viele Varianten folgen einem Muster, also Parameterregel.

Kontrolle nach der Umsetzung

Jede Maßnahme wird nach dem Ausrollen technisch nachgeprüft. Eine 301 führt direkt auf die endgültige Ziel-URL, ohne Kette und ohne Schleife. Canonical-Ziele antworten mit 200, sind indexierbar und inhaltlich passend. noindex-Seiten bleiben crawlbar, bis die Anweisung verarbeitet ist. Parameterregeln schließen keine wertvollen Landingpages mit aus.

Dazu die Signalprüfung: Interne Links zeigen auf die bevorzugte URL, die Sitemap enthält nur kanonische und indexierbare URLs, Canonicals verwenden dieselbe Host-, Protokoll- und Pfadform wie die Weiterleitungsziele, und die Navigation erzeugt keine neuen Parametervarianten nach.

Damit steht der anwendbare Kern der Moz-Doktrin von 2007 bis heute: Duplicate Content ist weniger ein Textproblem als ein Problem widersprüchlicher URL-Signale. Überflüssige URLs werden weitergeleitet, notwendige Varianten kanonisiert, funktionale Seiten ohne Suchwert aus dem Index genommen und massenhaft erzeugte Parameter durch Regeln statt Einzelfälle beherrscht.