Was doppelter Content ist und wie er sich auf das SEO-Ranking auswirkt

Von doppeltem Content spricht man, wenn derselbe Textblock, oder eine fast identische Version davon, über mehrere unterschiedliche URLs erreichbar ist. Das passiert innerhalb einer Website, wenn zwei Pfade zum selben Produkt führen, oder über Domain-Grenzen hinweg, wenn ein Artikel unverändert auf einer anderen Seite erneut veröffentlicht wird. Google crawlt und indexiert pro URL, nicht pro Inhalt: Jede Adresse, die denselben Text ausliefert, ist technisch gesehen eine neue Seite, die verarbeitet, verglichen und eingeordnet werden muss.

Das exakte Duplikat ist der einfachste Fall. Dieselbe Seite, geladen mit und ohne Tracking-Parameter, mit und ohne Slash am Ende, über http und https, mit und ohne www. Das HTML ändert sich kaum zwischen den Versionen, nur die Adresse ist anders. Meist ist das ein technischer Nebeneffekt und keine redaktionelle Entscheidung, und fast immer reicht ein einziges Werkzeug zur Lösung: Canonical oder Redirect.

Near Duplicate, also nahezu doppelter Content, ist eine andere Sache. Der Text ist nicht identisch, aber so ähnlich, dass er kaum zusätzlichen Wert bringt: die Produktseite eines T-Shirts in Größe S und dieselbe Seite in Größe M mit zwei geänderten Wörtern, eine Pressemitteilung, die auf zehn Portalen mit demselben Fließtext läuft, eine Druckversion eines Artikels, oder eine Landingpage, die zwischen zwei Märkten halb übersetzt wurde, ohne die Beziehung zwischen beiden Versionen per Hreflang zu markieren. Das ist in der Praxis mit Abstand der häufigere Fall. Kaum eine Website hat absichtlich exakte Duplikate, aber fast jede Website ab einer gewissen Größe sammelt Near-Duplicate-Varianten an, ohne es zu merken.

In beiden Fällen ist die praktische Wirkung ähnlich. Google entscheidet sich meist für eine Version, die es in den Ergebnissen zeigt, und behandelt die übrigen als Nebenkopien, die nicht eigenständig konkurrieren. Die Website verliert dadurch keine Autorität, gewinnt aber auch nichts, wenn die Kopien getrennt bleiben, statt die Autorität auf einer URL zu bündeln. Dazu kommt ein indirekter Kostenpunkt: doppelte Seiten zu crawlen, zu vergleichen und zu verwerfen kostet Crawl-Budget, das Google sonst für neue oder relevante Inhalte derselben Website einsetzen könnte.

Hier steckt der am meisten wiederholte Mythos im deutschsprachigen SEO: Google würde doppelten Content mit einer automatischen algorithmischen Strafe bestrafen. Das stimmt nicht, und Google sagt das in der offiziellen Search-Central-Dokumentation explizit. Wird keine kanonische URL angegeben, bestimmt die Suchmaschine selbst, welche Version, wörtlich, "die objektiv beste Version" ist, um sie Nutzern in der Suche zu zeigen, und bündelt dort die Signale der übrigen Kopien.

Die eigentliche Ausnahme liegt in Googles Spam-Richtlinien, nicht im doppelten Content an sich. Fremden Content in großem Stil zu übernehmen, automatisiert und ohne eigenen Mehrwert, kann tatsächlich zu einer manuellen Maßnahme führen oder dazu, dass diese Seiten gar nicht mehr in den Ergebnissen auftauchen. Der Unterschied liegt in der Absicht: unbeabsichtigt doppelter Content durch die Struktur der Website ist etwas anderes als fremden Content zu kopieren, um das Ranking zu manipulieren.

Vier Ursachen erklären die meisten Fälle, die bei einem technischen Audit auftauchen.

Die erste sind URL-Parameter. Ein einziger GET-Parameter kann Dutzende Varianten derselben Seite erzeugen: Filter in einem Onlineshop, Sortierparameter, UTM-Kampagnencodes oder Session-IDs. Die Seite bleibt dieselbe, aber für einen Crawler ist jede Parameterkombination eine eigene URL, die bewertet werden muss.

Die zweite ist die Syndizierung von Content: derselbe Artikel, dieselbe Pressemitteilung oder Produktbeschreibung wird auf mehreren Seiten veröffentlicht, ohne festzulegen, welche die Originalquelle ist. Das kommt häufig bei Marktplätzen vor, die Herstellerbeschreibungen unverändert übernehmen, und bei Medien, die Pressemitteilungen weiterverbreiten, ohne sie umzuschreiben.

Die dritte sind Produktvarianten im E-Commerce und die Facettennavigation: dasselbe T-Shirt in fünf Farben und drei Größen, jede mit eigener URL und einer Beschreibung, die sich nur in einem Wort unterscheidet, oder eine Kategorieseite, die für jede Kombination aus Preis-, Marken- und Größenfilter eine eigene URL erzeugt.

Die vierte sind internationale Duplikate ohne Hreflang: dieselbe Seite, übersetzt oder fast identisch, für unterschiedliche deutschsprachige oder englischsprachige Märkte, ohne das Tag, das Google mitteilt, dass jede Version einem anderen Land oder einer anderen Sprache dient und keine Kopie einer anderen ist.

Der häufigste Fall in der Praxis ist der erste: dieselbe Produktseite, erreichbar mit und ohne Tracking-Parameter. So sieht das an einem realen Beispiel mit einer zds.es-URL aus:

<!-- Version 1: saubere URL -->
https://zds.es/shop/laufschuhe

<!-- Version 2: dieselbe Seite, mit Parametern aus einem Newsletter -->
https://zds.es/shop/laufschuhe?utm_source=newsletter&utm_campaign=sommer2026

<!-- Beide Versionen brauchen denselben Canonical im <head> -->
<link rel="canonical" href="https://zds.es/shop/laufschuhe" />

Beide URLs liefern exakt dasselbe HTML aus. Ohne Canonical könnte Google beide separat indexieren, eingehende Links zwischen ihnen aufteilen und im schlechtesten Fall die Version mit Parametern statt der sauberen URL in den Ergebnissen zeigen. Zeigt das Canonical-Tag konsequent auf die parameterfreie URL, bündeln alle Varianten ihre Signale dort, egal von wo der Traffic kommt.

Der Canonical-Tag ist das wichtigste Werkzeug gegen doppelten Content, und das aus gutem Grund: Er ist ein starkes Signal an Google, welche Version die Referenzversion ist, ohne den Zugriff auf die übrigen zu entfernen. Das ist die richtige Wahl, wenn die doppelten URLs weiter existieren müssen, etwa weil sie Traffic aus Kampagnen, Nutzerfiltern oder externen Integrationen erhalten, die sich nicht einfach abschalten lassen.

Ein Redirect 301 ist vorzuziehen, wenn die doppelte URL keinen Grund mehr hat, weiter zu bestehen: eine Migration von http auf https, ein Wechsel von www auf ohne-www, oder eine URL-Umstrukturierung, bei der der alte Pfad überflüssig wird. Hier ist es sinnlos, zwei lebende Versionen zu pflegen oder Google entscheiden zu lassen; man leitet weiter, und der gesamte Wert eingehender Links geht direkt auf die neue URL über.

Noindex bleibt Seiten vorbehalten, die aus technischer oder Nutzer-Notwendigkeit existieren, aber der Suche nichts bringen: interne Suchergebnisse, sehr spezifische Filterkombinationen, Druckversionen oder automatisch erzeugte Seiten mit wenig eigenem Content. Anders als Canonical entfernt Noindex die Seite direkt aus dem Index, statt ihre Signale auf eine andere URL zu bündeln. Canonical und Noindex auf derselben Seite zu kombinieren und damit zwei widersprüchliche Anweisungen gleichzeitig zu senden, ist einer der häufigsten Fehler in echten Audits.

Bei Syndizierung über Domain-Grenzen hinweg hängt die Lösung davon ab, ob man die übernehmende Seite kontrolliert. Handelt es sich um einen Partner, mit dem eine Beziehung besteht, ist es richtig, ihn zu bitten, einen Canonical zur Originalquelle zu setzen oder seine Kopie mit Noindex zu markieren. Kopiert eine fremde Seite ohne Erlaubnis, bringt Canonical nichts, weil diese fremde Seite nicht bearbeitet werden kann; dann ist eine Urheberrechtsbeschwerde der richtige Weg, kein technisches Tag.

• Selbstreferenzierenden Canonical setzen: Die kanonische Version verweist in ihrem eigenen Canonical-Tag auf sich selbst.
• Die sitemap.xml nur mit kanonischen URLs pflegen, nie mit Varianten, die Parameter oder Session-IDs enthalten.
• Intern immer auf die kanonische Version verlinken statt auf Parameter-Varianten; die interne Verlinkung der Website dafür regelmäßig prüfen.
• Hreflang setzen, wenn der Content tatsächlich nach Land oder Sprache unterschiedlich ist, nie als Ersatz für Canonical.
• Syndizierungspartner bitten, ihre Kopie per Canonical auf die Originalquelle zu setzen oder sie mit Noindex zu markieren.
• Die eigene Website mit einem Crawler wie Screaming Frog rastern, um identische Inhalte zu erkennen, bevor das Problem in Produktion landet.

• Canonical, der auf eine andere, thematisch fremde Seite verweist und damit die eigentliche Beziehung zwischen beiden Versionen zerstört.
• Canonical-Ketten: Seite A verweist auf B, B verweist auf C, statt dass alle direkt auf die finale Version zeigen.
• Eine URL per robots.txt sperren, die einen Canonical zu einer anderen URL trägt: Kann Googlebot sie nicht crawlen, kann es das Tag auch nicht lesen.
• Canonical und Noindex auf derselben URL kombinieren und damit zwei widersprüchliche Signale gleichzeitig senden.
• Canonical benutzen, um Content zu "verstecken", der eigentlich einzigartig ist und für sich selbst indexiert werden sollte.
• Doppelten Content mit thematisch ähnlichem Content verwechseln: Zwei Artikel zum selben Thema mit unterschiedlichem Blickwinkel sind keine Duplikate, sondern verwandter Content, und beide können ranken.