Wer als Entwickler komplexe Listenansichten oder E-Commerce-Kategorien baut, läuft in eine gefährliche Falle. Sie wollen Duplicate Content vermeiden, doch Ihre Applikation generiert ihn automatisch. Das Szenario: Eine Kategorie-Seite /schuhe. Der Nutzer klickt auf "Farbe: Rot". Die URL wird zu /schuhe?color=red. Der Inhalt ist zu 95% identisch mit der Hauptseite. Der Nutzer klickt auf "Sortieren: Preis aufsteigend". Die URL wird zu /schuhe?color=red&sort=price_asc.

Für Googlebot sind das drei völlig verschiedene Seiten mit fast gleichem Inhalt. Wenn Sie tausende Filter-Kombinationen zulassen, verschwenden Sie das Crawl-Budget für wertlosen Müll (sogenannte "Spider Traps"). Um Duplicate Content vermeiden zu können, müssen wir dem Bot erklären, welche URL das "Original" ist und welche nur eine Variante.

Ein leuchtendes Labyrinth aus Datenpfaden, das die Probleme von Duplicate Content und vielen ähnlichen URLs visualisiert.

1. Der Canonical Tag: "Ich bin nur eine Kopie"

Das wichtigste Werkzeug im Header ist der <link rel="canonical">. Er fungiert als "Soft Redirect". Er sagt der Suchmaschine: "Du kannst diese URL hier crawlen, aber bitte indexiere stattdessen die URL, die ich dir hier nenne."

Die Logik für Entwickler:

Die Hauptseite (Self-Referencing): Jede Seite sollte standardmäßig auf sich selbst zeigen. URL: /schuhe -> Canonical: /schuhe Warum? Das schützt vor externen Parametern (z.B. Facebook-Tracking-IDs ?fbclid=...), die sonst Duplicate Content erzeugen würden.
Die Filter-Seite (Pointing to Root): Wenn die Filterung den Inhalt nicht grundlegend ändert (z.B. Sortierung), muss der Canonical auf die Kategorie ohne Parameter zeigen. URL: /schuhe?sort=price -> Canonical: /schuhe

Code-Beispiel:

HTML

<head>
  <link rel="canonical" href="https://example.com/schuhe" />
</head>

Vorsicht: Wenn ein Filter den Inhalt massiv ändert (z.B. /schuhe?marke=nike), ist das für den User eine neue Seite. Hier sollte der Canonical selbstreferenzierend sein (/schuhe?marke=nike), damit diese spezielle Landingpage bei Google ranken kann.

Drei identische Webseiten, wobei zwei davon mit einem leuchtenden Pfeil auf die dritte als das Original verweisen (Canonical Tag).

2. Paginierung: Das "Seite 2" Problem

Früher nutzte man rel="next" und rel="prev", um paginierte Seiten zu verketten. Wichtig für Entwickler: Google nutzt diese Tags seit Jahren nicht mehr! (Bing nutzt sie noch).

Wie gehen wir also heute mit /blog/page/2 um? Viele Entwickler machen den Fehler und setzen den Canonical von Seite 2 auf Seite 1. Das ist falsch! Seite 2 hat anderen Inhalt (andere Artikel) als Seite 1. Sie ist kein Duplikat.

Best Practice für Pagination:

Canonical: Jede Seite zeigt auf sich selbst. /blog/page/2 -> Canonical: /blog/page/2
HTML-Links: Nutzen Sie normale <a href="...">-Links für die Paginierung, keine JS-Buttons (<button onClick="loadMore()">). Googlebot klickt keine "Load More"-Buttons, er folgt Links.

3. Robots.txt und Noindex: Blockieren statt kanonisieren

Der Canonical Tag ist nur eine "Empfehlung" an Google. Manchmal müssen wir härter durchgreifen, um Server-Last zu sparen.

Wann `robots.txt`? (Crawling verbieten)

Wenn Sie Parameter haben, die unendlich viele Kombinationen erzeugen (z.B. Session-IDs oder komplexe Preis-Filter ?price_min=10&price_max=11), sollten Sie dem Bot verbieten, diese überhaupt abzurufen.

# robots.txt
User-agent: *
Disallow: /*?sort=
Disallow: /*?session_id=

Effekt: Google ruft diese URLs nie ab. Das spart massiv Crawl-Budget.

Wann `noindex`? (Indexierung verbieten)

Wenn Google die Seite sehen darf (um Links zu folgen), sie aber nicht im Suchergebnis auftauchen soll (z.B. "Suchergebnisseite", "Warenkorb").

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

Der tödliche Fehler: Blockieren Sie eine URL niemals gleichzeitig per robots.txt UND setzen Sie sie auf noindex. Wenn Google die Seite in der robots.txt verboten wird, kann der Bot sie nicht lesen. Er sieht also das noindex-Tag im HTML gar nicht! Die Seite kann trotzdem im Index landen (als leeres Ergebnis).

Fazit: Logik vor Inhalt

Um Duplicate Content vermeiden zu können, müssen Backend-Entwickler eine klare Logik für Parameter definieren.

Ist die URL nur eine Sortierung? -> Canonical auf Hauptseite.
Ist die URL eine wichtige Filter-Seite (Marke)? -> Canonical auf sich selbst (indexierbar).
Ist die URL technischer Müll (Session-ID)? -> Blockieren via robots.txt.

Wir haben jetzt das Backend und die URL-Struktur im Griff. Aber was passiert, wenn das Frontend die URLs manipuliert, ohne dass der Server davon weiß?

#pagination

Duplicate Content vermeiden: Pagination, Filter & URL-Parameter