Sie sind hier:

Wie man rel=canonical richtig verwendet

Tobias Schwarz
Tobias Schwarz

Tobias Schwarz ist als CTO & Gründer von Audisto für die technische Weiterentwicklung der SaaS-Lösung verantwortlich. Als bekannter Experte für alle Fragestellungen rund um Technical SEO, die technische Analyse und kontinuierliche Optimierung von großen internationalen Webseiten gibt Tobias sein Wissen gerne als Speaker auf Konferenzen, in Workshops und Podcasts weiter. Insbesondere Strukturoptimierung sowie kontinuierliche und automatisierte Qualitätskontrolle von Webseiten gehören dabei zu seinen Lieblingsthemen.

Mehr von diesem AutorArtikel als PDF laden
Christian Müller
Christian Müller

Christian Müller ist als SEO-Consultant tätig. Seine Schwerpunkte liegen im Bereich technische Suchmaschinenoptimierung, Offpage-SEO und Penalty Recovery. Darüber hinaus betreibt er seit 2006 Projekte überwiegend im Finanzbereich.

Mehr von diesem AutorArtikel als PDF laden

URL-Kanonisierung mittels link rel=canonical kann ein sehr effektives Mittel sein, um Probleme mit internen oder externen doppelten Inhalten in den Griff zu bekommen. Es dient dem Zweck, die bevorzugte Version eines Inhalts, der auf mehreren URLs verfügbar ist, auszuweisen. Dies ist hilfreich, wenn viel Syndication stattfindet bzw. mit GET-Parametern gearbeitet wird. Der Beitrag von Tobias Schwarz und Christian Müller zeigt, wie rel=canonical richtig verwendet wird, beleuchtet häufige Fehler und erklärt, wann man rel=canonical einsetzen sollte und wann nicht.

Rel=canonical ist ein Link-Attribut, mit dem sich im Falle von Duplizierung die bevorzugte Variante von Dokumenten definieren lässt. Rel=canonical sorgt nicht dafür, dass die Dubletten nicht gecrawlt und indexiert werden. Stattdessen fungiert es als ein Vorschlag für die Suchmaschine, welche Version bevorzugt werden soll, falls es von einem Dokument zwei oder mehr Varianten gibt, die gleich oder zumindest sehr ähnlich sind.

Um zu verstehen, wie rel=canonical von Suchmaschinen genutzt wird, stellen Sie sich das folgende Szenario vor: Die Suchmaschine hat ein ungefiltertes Set von Suchergebnissen für eine spezifische Suchanfrage. Um die Ergebnismenge weiter zu reduzieren, versucht die Suchmaschine, Dubletten herauszufiltern. An diesem Punkt wird der Rel=canonical-Vorschlag verarbeitet. Bei korrekter Verwendung folgt die Suchmaschine diesem Vorschlag in den meisten Fällen und zeigt nur noch das bevorzugte Dokument an.

Es gibt einige Fälle, in denen rel=canonical falsch angewendet wird. Effekte können Rankingverluste oder verschenktes Rankingpotenzial sein.

Wie man rel=canonical richtig einsetzt

Canonical im HTML-Markup vs. Canonical im HTTP-Header

Es gibt zwei Wege, um rel=canonical zu implementieren. Der populärste Ansatz ist die Verwendung als Link-Tag im <head>-Bereich im HTML-Markup.

 
 <html> <head> <link rel="canonical" href="http://example.com/page.html"> </head> <body> ...
 

Codeblock-Unterschrift: Rel-Canonical-Markup im HTML <head>

Link rel=canonical kann allerdings auch mit dem HTTP-Header gesendet werden.

 
 HTTP/1.1 200 OK Content-Type: application/pdf Link: <http://example.com/page.html>; rel="canonical" Content-Length: 4223 ...
 

Codeblock-Unterschrift: Rel-Canonical-Markup im HTTP-Header

Diese Variante eignet sich für Nicht-HTML-Dokumente und kommt oft im Kontext von Druckversionen, downloadbaren PDF-Versionen, Grafiken und ähnlichen Arten von Inhalten vor.

Wenn man rel=canonical nutzt

Am weitesten verbreitet ist die selbstreferenzierende Verwendung von Canonicals für jedes eigenständige Dokument einer Seite. Die Aussage in Richtung Suchmaschine lautet damit: „Hallo, ich bin das Originaldokument. Indexiere mich und liste mich in Suchergebnissen, wenn du mehrere Dokumente mit diesem Inhalt findest.”

Diese Herangehensweise verhindert Probleme mit identischen Kopien des Inhaltes. Probleme mit doppelten Inhalten können intern wie extern auftreten.

Die folgenden Szenarien können durch korrekte Verwendung von rel=canonical verhindert werden:

Probleme mit Get-Parametern

  • Tracking-Parameter
  • Session-Parameter
  • Ungewollte/unerwartete Parameter
  • Unsortierte Parameter

Probleme mit mehreren URLs für den gleichen Inhalt

  • CMS erzeugt mehr als eine URL für den Inhalt (z. B. URL mit ID vs. sprechende URL)

Probleme mit der Verfügbarkeit auf verschiedenen Hosts/Protokollen/Ports

  • HTTP/HTTPS
  • Port 80/8080
  • Mit www/ohne www
  • Verschiedene Domains

Probleme mit externer Syndizierung

Wie und wann man rel=canonical nicht verwendet

Vollständige URLs statt gekürzter URLs für rel=canonical verwenden

Eine potenzielle Quelle für Probleme bei der Nutzung von rel=canonical ist die Nutzung gekürzter URLs anstelle vollständiger, absoluter URLs.

Die Chancen stehen gut, dass eine Webseite Inhalte über verschiedene Protokolle und Hosts, aber mit gleichem Verzeichnis und Dateinamen anbietet.

Im Quelltext kann exakt die gleiche Angabe zu rel=canonical zu finden sein – jedoch zeigt in diesem Fall jede Version auf eine andere URL.

Stellen Sie sich vor, Sie haben zwei Seiten mit verschiedenen Protokollen wie in folgendem Beispiel:

example.com/page.html

 
 <link rel="canonical" href="page.html">
 
 

example.com/page.html

 
 <link rel="canonical" href="page.html">
 
 

Wenn diese Canonicals aufgelöst werden, resultieren daraus zwei verschiedene URLs:

 
 http://example.com/page.html https://example.com/page.html
 

Je kompletter die Canonical-URL ist, desto weniger fehleranfällig ist die Notation.

 
 <link rel="canonical" href="page.html">
 

Dies kann Probleme erzeugen mit:

  • Verzeichnissen
  • Hosts
  • Protokollen
 
 <link rel="canonical" href="/page.html">
 
 

Dies kann Probleme erzeugen mit

  • Hosts
  • Protokollen
 
 <link rel="canonical" href="//example.com/page.html">
 
 

Dies kann Probleme erzeugen mit:

  • Protokollen
 
 <link rel="canonical" href="http://example.com/page.html">
 
 

Diese Schreibweise ist nicht anfällig für die vorgenannten Probleme.

Obwohl es legitime Gründe gibt, gekürzte oder relative URLs zu verwenden und RFC6596 diese Art der Verwendung explizit erlaubt, kann eine Vielzahl von Problemen vermieden werden, indem man mit absoluten URLs arbeitet.

Merke:

  • Relative URLs sind kürzer, aber fehleranfälliger, schwerer zu warten und für externe Crawler schwerer zu verstehen.
  • Wenn die Inhalte auf eine externe Webseite geklont werden, bringen relative URLs im Canonical keine Vorteile – tatsächlich könnte dem Content-Dieb damit Hilfe geleistet werden.

Es empfiehlt sich, für rel=canonical ausschließlich absolute URLs zu verwenden.

rel=canonical nicht für Lokalisierung nutzen

Wenn Ihre Webseite für mehr als ein Land bzw. mehr als eine Sprache optimiert ist, sollte den Suchmaschinen eine Hilfestellung geboten werden, um die Inhalte richtig einzuordnen und in den Suchergebnissen auszuspielen.

Es gibt nach wie vor Webseiten, bei denen rel=canonical auf die bevorzugte Sprachversion bzw. lokalisierte Version des Inhaltes verweist.

Die zugrunde liegende Fehleinschätzung ist, dass sich rel=canonical nutzen lässt, um eine bevorzugte Sprachvariante anzugeben.

Grundsätzlich sollte zur Lokalisierung rel=”alternate” hreflang=”x” verwendet werden, um klarzustellen, welche Version welchem Zielmarkt zugeordnet ist.

Hreflang kann genutzt werden, um eine Verbindung zwischen allen separaten Sprach- und Landesversionen Ihres Inhaltes zu schaffen. Der Wert “x-default” kann verwendet werden, um eine URL zu spezifizieren, die an Nutzer außerhalb der Zielregionen und -sprachen bevorzugt ausgeliefert wird.

Weitere Informationen zum Thema  „Wie man eine multilinguale Webseite aufsetzt” (http://einfach.st/gcanon) bietet die Hilfe der Google Search Console.

Es empfiehlt sich, rel=canonical nicht mit dem Ziel der Lokalisierung einzusetzen.

rel=canonical nicht für PageRank Sculpting nutzen

In einigen Fällen wird Canonical genutzt, um PageRank Sculpting zu betreiben. PageRank Sculpting ist eine Methode, die den PageRank-Fluss innerhalb der Webseite optimieren soll. Auf jeder Webseite gibt es Seiten, die rechtlichen oder strukturellen Vorgaben geschuldet sind. Üblicherweise handelt es sich dabei um Inhalte wie Impressum, Datenschutzerklärung, teils aber auch Paginierungs- und Kategorieseiten. Diese Inhalte haben keine Relevanz für die Suchergebnisse, weshalb ihr PageRank auf Inhalte höherer Priorität übertragen werden soll.

Der Webmaster würde in diesem Fall beispielsweise im Impressum ein Canonical-Tag mit der Startseite oder einer wichtigen Seite als Ziel-URL hinterlegen.

Diese Herangehensweise basiert auf der Annahme, dass ein Canonical hinsichtlich des PageRank-Flusses wie ein 301-Redirect verarbeitet wird. Tests zeigten, dass dies nicht der Fall ist.

Diese Herangehensweise ist nicht empfehlenswert. Im schlimmsten Fall können Suchmaschinen die Canonical-Definitionen der Webseite insgesamt ignorieren, woraus sich eine Kette von Folgeproblemen ergeben kann.

Benutzen Sie Canonicals nicht für PageRank Sculpting!

Canonical-Nutzung in der Paginierung

Paginierung ist eine Herangehensweise, um Inhalte zu stückeln und auf einzelnen miteinander verknüpften Unterseiten zu verteilen. Paginierung wird genutzt, wann immer eine Ausgabe zu groß wäre, um sie noch sinnvoll auf einer URL auszugeben. In diesem Fall kann der Inhalt aufgesplittet werden.

Abbildung 1: Beispiel: Paginierung bei Amazon.de

Wenn Ihre Webseite Paginierung nutzt, wollen Sie die Suchmaschinen vielleicht daran hindern, den Inhalt jenseits der ersten Paginierungsseite zu crawlen oder zu indexieren. Dies trifft insbesondere zu, wenn:

  • … die Paginierungsseiten keinen Wert für den Suchindex haben;
  • … die Webseite eine sehr tiefe Paginierungs-Ebene erreicht, sodass Crawler einen nennenswerten Anteil des Crawl-Budgets für den Crawl der Paginierung aufwenden;
  • … die Paginierung zu Thin Content führt.

Innerhalb einer Paginierung hat man es in der Regel nicht mit doppeltem Inhalt zu tun. Der Inhalt innerhalb einer Paginierung ist sich sogar meist nicht einmal ähnlich. Rel=canonical ist für doppelte oder ähnliche Inhalte bestimmt. Die Definition von nicht selbstreferenzierenden Canonicals bei Paginierungsseiten ist in den meisten Fällen eine fehlerhafte Nutzung des Canonical-Elements.

Mit einem nicht selbstreferenzierenden Canonical auf einer Paginierungsseite teilt man Suchmaschinen mit, den Inhalt der spezifischen Seite zu ignorieren. Sollte dies das Ziel sein, so sollte die Noindex-Robots-Direktive benutzt werden, um die Indexierung zu verhindern, oder das Crawling der Seiten über eine Regel in der robots.txt komplett blockiert werden.

Eine praktikable Variante für einen nicht selbstreferenzierenden Canonical in der Paginierung kann die Verwendung einer „Show all”-Seite sein, auf der alle Elemente innerhalb der Paginierung gelistet sind. Ein sinnvoller Anwendungsfall für diese Vorgehensweise könnte ein längerer Artikel sein, der in Einzeldokumente aufgesplittet ist. Nicht ratsam ist diese Variante für Paginierung mit hoher Anzahl von Ebenen und reinen Listingpages.

Variante 1:

Canonical auf Einstiegsseite

example.com/page.html

<link rel=”canonical” href=”http://example.com/page.html” />

example.com/page.html

<link rel=”canonical” href=”http://example.com/page.html” />

example.com/page.html

<link rel=”canonical” href=”http://example.com/page.html” />

Tabellenunterschrift: Resultat: Suchmaschinen werden nur die erste Seite der Paginierung in Suchergebnissen anzeigen oder die Canonical-Definitionen werden ignoriert und alle Seiten werden angezeigt

Variante 2:

Selbstreferenzierender Canonical

example.com/page.html

<link rel=”canonical” href=”http://example.com/page.html” />

<link rel=”next” href=”http://example.com/page.html?seite=2” />

example.com/page.html

<link rel=”canonical” href=”http://example.com/page.html?seite=2” />

<link rel=”prev” href=”http://example.com/page.html” />

<link rel=”next” href=”http://example.com/page.html?seite=3” />

example.com/page.html

<link rel=”canonical” href=”http://example.com/page.html?seite=3” />

<link rel=”prev” href=”http://example.com/page.html?seite=2” />

Tabellenunterschrift: Resultat: Suchmaschinen werden alle Seiten der Paginierung in den Suchergebnissen anzeigen

Variante 3:

“Show all”-Variante

example.com/page.html

<link rel=”canonical” href=”http://example.com/page.html?seite=full” />

example.com/page.html

<link rel=”canonical” href=”http://example.com/page.html?seite=full” />

example.com/page.html

<link rel=”canonical” href=”http://example.com/page.html?seite=full” />

example.com/page.html

<link rel=”canonical” href=”http://example.com/page.html?seite=full” />

Tabellenunterschrift: Resultat: Suchmaschinen werden bevorzugt das Dokument in den Suchergebnissen anzeigen, welches den gesamten Inhalt auf einer Seite darstellt

Canonical-Nutzung für ähnliche Produktangebote

Ein häufig anzutreffender Fehler – speziell bei Online-Shops – ist die Verwendung von rel=canonical für sehr ähnliche Produkte, insbesondere bei nur sehr geringen Abweichungen wie unterschiedlicher Farbe oder Produktversionen.

Der positive Effekt: Ähnliche Produkte erzeugen keinen doppelten Inhalt.

Der negative Effekt: Die Standardproduktversion wird in den Suchergebnissen bevorzugt. Wenn Kunden nach der alternativen Variante suchen, wird mit hoher Wahrscheinlichkeit die falsche Produktversion in den Suchergebnissen angezeigt.

​​​​​​​Beispiel:

Ein Online-Shop verkauft T-Shirts. Das gleiche Shirt wird in verschiedenen Farben angeboten: blau, rot und gelb auf jeweils unterschiedlichen URLs. Um Probleme mit doppelten Inhalten zu vermeiden, werden Canonical-URLs verwendet. Diese zeigen auf die Produktversion, die sich am besten verkauft (angenommen, es ist das blaue T-Shirt), sodass dieses in den Suchergebnissen bevorzugt wird. Das blaue T-Shirt bekommt eine selbstreferenzierende Canonical-URL, alle anderen Produktvarianten zeigen mit ihrem Canonical auf das blaue T-Shirt.

Abbildung 2: Suboptimale Suchergebnisse durch Einsatz von Canonical bei ähnlichen Produkten

Tipp

Checkliste technische Fehlerquellen

  • Markup-Fehler – Gibt es HTML-Markup-Fehler im Zusammenhang mit dem Canonical-Tag?
  • Mehrfach-Angaben – Gibt es mehr als ein Canonical-Tag in dem Dokument?
  • Canonical außerhalb des HTML <head> – Wurde das Canonical-Tag außerhalb des <head>-Bereichs des Dokuments eingesetzt?
  • HTTP-Header vs HTML – Sind Canonical-Angaben in HTML <head> und HTTP-Header gleichzeitig vorhanden? Widersprechen sich die Angaben?
  • Link-Ziele Status-Codes – Gibt es Canonical-Link-URLs, die keinen Status 200 ausliefern?

Checkliste konzeptionelle Fehlerquellen

  • Relative/gekürzte URLs – Liegen gekürzte/relative URLs als Canonical-Ziele vor, die auf absolute umgeschrieben werden können?
  • Ähnliche Produkte – Werden Canonical-Angaben genutzt, um bei mehreren Produktvarianten ein bevorzugtes Produkt zu definieren? Können die Produkte stattdessen auf selbstreferenzierende Canonicals und strukturiertes Produkt-Markup (isSimilarTo) umgeschrieben werden?
  • Mobile Webseiten – Wird link rel=canonical im Zusammenhang mit mobilen Webseiten korrekt genutzt? Sind mobile Versionen in der Desktopversion mit rel=alternate media=x ausgezeichnet?
  • Paginierung – Wird link rel=canonical im Zusammenhang mit Paginierungen richtig verwendet? Sind alle Paginierungsseiten mit selbstreferenzierenden Canonical-URLs oder einer  „Show all”-Seite als Ziel versehen?
  • Lokalisierung – Wird Canonical im Zusammenhang mit Lokalisierung richtig eingesetzt? Muss auf selbstreferenzierende URLs in Kombination mit link rel=alternate hreflang=”x” umgestellt werden?
  • PageRank Sculpting  Müssen Link-rel=canonical-Angaben korrigiert werden, da diese zum Zweck des PageRank Sculpting gemacht wurden?

Wenn nun ein Nutzer nach „rotes T-Shirt” sucht, könnte Google sich daran erinnern, dass einmal ein rotes T-Shirt in diesem Online-Shop gefunden wurde. Aber Google erinnert sich ebenfalls daran, dass dort eine Canonical-URL zu finden war, die auf das blaue Shirt verweist.

Im Resultat wird wahrscheinlich das weniger passende blaue Shirt in den Suchergebnissen gezeigt, was potenziell zu einer geringeren Klickrate in den Suchergebnissen führt.

Eigentlich möchte der Shopbetreiber, dass alle Produktversionen in den Index wandern und im richtigen Moment gefunden werden, ohne dort als doppelte Inhalte wahrgenommen zu werden. Die technische Lösung für dieses Problem findet sich in Form von Schema.org-Markups.

Schema.org bietet für Produktdaten eine Auszeichnung namens „isSimilarTo” (https://schema.org/isSimilarTo). Mithilfe dieser strukturierten Daten kann Google mitgeteilt werden, dass blaues, rotes und gelbes Shirt sich sehr ähnlich sind und sich lediglich in einem kleinen Merkmal unterscheiden. Mithilfe von isSimilarTo kann auch eine selbstreferenzierende Canonical-URL auf ähnlichen Produkten eingeführt werden.

Google und andere Suchmaschinen werden diese Anweisung üblicherweise verstehen und die korrekte Produktversion im passenden Kontext anzeigen.

Canonical-Nutzung für mobile Webseitenversionen

In manchen Fällen bieten Webseiten eine dedizierte mobile Webseitenversion z. B. auf einem extra Host wie m.example.com oder in einem extra Verzeichnis wie example.com/m/ an.

Die Frage ist nun, wie Probleme mit doppelten Inhalten bei einer eigenständigen mobilen Webseite vermieden werden können.

Google empfiehlt, eine Kombination aus rel=alternate und rel=canonical (http://einfach.st/gcanon2) zu nutzen.

Rel=alternate sagt der Suchmaschine, dass andere Versionen dieses Inhaltes existieren, die in Abhängigkeit von Endgerät und User Agent besser für den Nutzer geeignet sind.

In einigen Fällen konnte beobachtet werden, dass die mobile Webseitenversion per rel=canonical direkt auf die Desktop-Version der Website verweist, ohne eine Rel=alternate-Auszeichnung. Im Ergebnis wird die mobile Webseitenversion wahrscheinlich nicht in den Suchergebnissen angezeigt.

Auch Mobilnutzer bekommen weiterhin die Desktopversion in den Suchergebnissen zu sehen. Dass diese allerdings nicht auf Mobilnutzer zugeschnitten ist, führt bei fehlender automatischer Weiterleitung potenziell zu einer geringeren Nutzerinteraktionsrate auf der betroffenen Webseite.

Tatsächlich gewollt ist ein Zustand, in dem sich sowohl die mobile als auch die Desktopversion der Webseite im Index befinden. Das lässt sich durch die Kombination aus rel=alternate und rel=canonical erreichen.

Beispiel:

Desktop Version http://example.com

<html>

<head>

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

<link rel="alternate" href="http://m.example.com/" media=”only screen and (max-width: 640px)”>

</head>

<body>

Mobile Version http://m.example.com

<html>

<head>

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

</head>

<body>

Häufige unbeabsichtigte Fehler mit rel=canonical

Mehrere Canonicals mit verschiedenen Ziel-URLs

Wenn ein zweites Canonical-Tag in die Seite integriert wird und beide unterschiedliche Ziel-URLs enthalten, so ist es wahrscheinlich, dass Suchmaschinen beide Canonical-Vorgaben ignorieren.

Zu einer zweiten Canonical-Definition kommt es üblicherweise unbeabsichtigt als Ergebnis der Inbetriebnahme eines neuen SEO-Plug-ins o. Ä., was sich in unerklärlichem Suchmaschinenverhalten äußern kann.

Achtung: Dies gilt auch für Kombinationen aus HTTP-Header-Canonical und HTML-Canonical. Dieses Problem lässt sich leicht übersehen.

Canonical-Nutzung außerhalb der HTML <head> area

Ein weiterer häufig auftretender Fehler bei der Nutzung von rel=canonical ist eine Platzierung außerhalb des HTML-Head, meist im Body-Tag. Die meisten Suchmaschinen ignorieren Canonical-Angaben, die nicht im Head hinterlegt sind.

Canonical-Nutzung zeigt auf URL mit anderem Statuscode als 200

Wenn die Canonical-URL einen Serverstatus liefert, der nicht 200 ist, dann kann dies dazu führen, dass die Canonical-Angabe ignoriert wird.

Wenn das Canonical-URL-Ziel einen 30x Redirect liefert, ist der Crawler der Suchmaschine gezwungen, eine weitere URL zu crawlen. Kommt dies im großen Stil vor, kann das Crawlbudget der Webseite massiv belastet werden.

Im schlimmsten Fall liefert die Canonical-URL einen Status 4xx oder gar 5xx aus. Status 4xx und 5xx führen dazu, dass die Canonical-Angabe für die Suchmaschine nicht verwertbar ist. Die Suchmaschine wird wahrscheinlich infolgedessen die Canonical-Angabe der Seite ignorieren. Das Ergebnis ist, dass möglicherweise doppelte Inhalte in die Suchergebnisse rutschen.

Stellen Sie sicher, dass die Canonical-URLs einen Server-Status-Code 200 ausliefern.