Kanonische URLs: eine Seite, eine Adresse

Warum dieselbe Seite unter einem Dutzend Adressen lebt, was rel=canonical dagegen ausrichten kann und was nicht — und welche Canonical-Fehler Ihr eigenes SEO still untergraben.

SEO · Veröffentlicht: 29. September 2026 · 6 Min. Lesezeit · Ольга Мирошник

Für Sie ist eine Seite ein Stück Inhalt. Für eine Suchmaschine ist eine Seite eine URL. Antwortet derselbe Inhalt unter zehn URLs, sieht der Crawler zehn Seiten, muss herausfinden, dass es Kopien sind, und dann raten, welche Sie gemeint haben. Kanonisierung ist die Arbeit, dieses Raten überflüssig zu machen.

Wie eine Seite zu vielen Adressen kommt

Niemand veröffentlicht Duplikate absichtlich. Der Server akzeptiert einfach mehr Adressvarianten, als man denkt:

• Host. Sowohl www.example.com als auch example.com antworten.
• Protokoll. http:// liefert die Website noch aus, statt auf https:// weiterzuleiten.
• Abschließender Slash. /pricing und /pricing/ liefern dasselbe Dokument.
• Groß- und Kleinschreibung. Auf einem Server, der sie nicht unterscheidet, funktionieren /Blog/Post und /blog/post.
• Indexdateien. /docs/ und /docs/index.html sind dieselbe Datei.
• Query-Parameter. ?utm_source=newsletter, ?sort=price, ?sessionid=… — jede Kombination ist eine neue URL mit identischem oder nahezu identischem Inhalt.
• Paginierung. /blog?page=2 ist eine echte, eigenständige Seite — wird aber oft fälschlich als Duplikat von Seite 1 behandelt.

Multiplizieren Sie das, und eine Website mit hundert Seiten stellt Tausende Adressen bereit. Links, Shares und die Aufmerksamkeit des Crawlers verteilen sich darauf.

Ein Host, durchgesetzt per 301

Am günstigsten lassen sich Duplikate auf Host- und Protokollebene beseitigen, und das richtige Werkzeug ist hier eine permanente Weiterleitung, kein Tag. Wählen Sie eine Form — etwa https://example.com — und leiten Sie alle anderen Kombinationen in einem einzigen Sprung dorthin:

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

Zwei Details zählen. Die Weiterleitung muss ein 301 (oder 308) sein, kein 302: Eine temporäre Weiterleitung sagt der Suchmaschine, dass die alte Adresse weiterhin die echte ist. Und es sollte ein Sprung sein: Die Kette http://www → https://www → https:// funktioniert, kostet aber bei jedem Erstbesuch einen zusätzlichen Roundtrip. Beim abschließenden Slash gilt dasselbe: eine Variante wählen, die andere weiterleiten.

rel=canonical ist ein Hinweis

Für Duplikate, die sich nicht weiterleiten lassen — Tracking-Parameter, Sortierungen, Druckversionen —, deklarieren Sie die bevorzugte Adresse im Head der Seite:

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

Das ist ein Hinweis, keine Anweisung. Google gewichtet ihn zusammen mit Weiterleitungen, internen Links, Sitemap und hreflang und kann eine andere kanonische URL wählen, wenn diese Signale sich widersprechen. Ihre Aufgabe ist, dass alle Signale auf dieselbe URL zeigen.

Bewährte Praxis:

• Selbstreferenzierende Canonicals. Jede indexierbare Seite nennt sich selbst. Das schützt sie vor Parametervarianten, mit denen Sie nicht gerechnet haben.
• Absolute URLs. Ein relatives href="/pricing/" ist zulässig, wird aber gegen den Host und das Protokoll aufgelöst, unter denen die Kopie ausgeliefert wurde — also genau das Duplikat, das Sie beseitigen wollten.
• Paginierte Seiten kanonisieren auf sich selbst. Seite 2 nennt Seite 2, nicht Seite 1; sonst wird alles schwerer auffindbar, worauf nur Seite 2 verlinkt.

Nicht-HTML-Dateien nutzen einen Header. Ein PDF hat keinen Head, also wird der Hinweis in der Serverantwort mitgeschickt:

Link: <https://example.com/guide.pdf>; rel="canonical"

Fehler, die echten Schaden anrichten

Canonical überall auf die Startseite. Ein Template setzt auf jeder Seite dasselbe Canonical. Damit haben Sie der Suchmaschine gesagt, dass Ihre gesamte Website ein Duplikat von / ist.

Canonical auf eine Seite, die es nicht gibt. Das Ziel leitet weiter, liefert 404 oder trägt noindex. Die Signale widersprechen sich, und die Suchmaschine ignoriert den Hinweis meist.

Konflikte mit hreflang und Sitemap. Die Sitemap listet /pricing, das Canonical sagt /pricing/, hreflang verweist auf eine dritte Variante. Überall sollte genau die kanonische URL stehen.

JavaScript ändert es. Das Server-HTML sagt das eine, ein clientseitiger Router oder ein SEO-Plugin schreibt das Tag nach dem Laden um. Crawler können jede der beiden Versionen sehen. Rendern Sie das korrekte Canonical auf dem Server und fassen Sie es danach nicht mehr an.

Mehrere Canonical-Tags. Zwei Plugins fügen je eins hinzu. Bei widersprüchlichen Werten wird der Hinweis in der Regel ganz verworfen.

So prüfen Sie

Holen Sie das rohe HTML und schauen Sie, was der Server tatsächlich sendet — nicht, was die DevTools nach Ausführung der Skripte anzeigen:

curl -s https://example.com/pricing/ | grep -i 'rel="canonical"'
curl -sI http://www.example.com/ | grep -iE '^(HTTP|location)'

Der zweite Befehl sollte ein einzelnes 301 auf den gewählten Host zeigen. Ein SiteScan-Report übernimmt einen Teil davon automatisch: Er markiert Seiten ohne Canonical-Link, Seiten, deren Canonical eine andere Adresse nennt, Websites, auf denen sowohl der Host mit www als auch der ohne www mit 200 antwortet, statt dass einer permanent weiterleitet, sowie Host-Weiterleitungen über ein temporäres 302.

Checkliste

1. Ein Host und ein Protokoll; jede andere Kombination liefert ein einzelnes 301.
2. Eine Slash-Variante am Ende, die andere wird weitergeleitet.
3. Jede indexierbare Seite hat ein absolutes, selbstreferenzierendes Canonical.
4. Canonical-Ziele liefern 200, sind indexierbar und leiten nicht weiter.
5. Sitemap, hreflang und interne Links verwenden genau die kanonischen URLs.
6. Paginierte Seiten kanonisieren auf sich selbst.
7. PDFs und andere Dateien senden bei Bedarf einen Link-Header.
8. Das Canonical im Server-HTML stimmt mit dem nach Ausführung von JavaScript überein.