Zusammenfassung

  • Im Februar 2009 gab Google Websitebetreibern mit rel="canonical" eine Möglichkeit, bei doppelten Seiten die bevorzugte URL anzugeben. Das Unternehmen nannte die Angabe ausdrücklich einen starken Hinweis, keinen Befehl. Der Betreiber konnte vorschlagen; die Suchmaschine behielt die Auswahl.
  • RFC 6596 beschrieb 2012 den Preis einer falschen Zuordnung: Verweist Seite zwei eines mehrseitigen Artikels auf Seite eins als kanonische Fassung, kann ihr eigener Text als Dublette aus der Verarbeitung fallen.

Eine Warenkarte mit vier Adressen

Eine Produktseite erhält eine klare URL und weitere mit Kategorieparameter, Werbemarkierung oder Sitzungsnummer. Für Käufer bleibt es dasselbe Produkt; für einen Crawler entstehen mehrere Adressen. In seiner Mitteilung vom 12. Februar 2009 bot Google eine kurze Angabe im HTML-Kopf der Dubletten an: <link rel="canonical" href="..."> sollte die bevorzugte Adresse benennen.

Das war kein Umzug des Besuchers. Der Browser konnte die aufgerufene Seite weiter laden; die Nachricht richtete sich an den Suchindex. Google stellte in Aussicht, Verweise und andere Eigenschaften bei der bevorzugten URL zu bündeln. Auf die Frage, ob die Angabe Befehl oder Hinweis sei, antwortete es: ein starker Hinweis, der zusammen mit anderen Signalen geprüft werde. Der Betreiber kannte die Adressen, die sein System erzeugte. Die Suchmaschine kannte ihre Crawls und die Gruppen ähnlicher Seiten. Der eine schrieb den Vorschlag, die andere fällte die Auswahl.

Auch die Reichweite des Vorschlags änderte sich im Laufe des Jahres. Im ursprünglichen Text waren Angaben zwischen Subdomains möglich, zwischen vollständig verschiedenen Domains zunächst nicht; für einen Domainwechsel empfahl Google eine dauerhafte Weiterleitung. Ein Nachtrag vom 17. Dezember 2009 meldete Unterstützung über Domain-Grenzen hinweg. Wer diese Daten zusammenzieht, macht aus einer späteren Erweiterung fälschlich eine Eigenschaft des Starts.

Was der RFC tatsächlich bevorzugt

RFC 6596 definierte im April 2012 die kanonische Linkbeziehung: Die Zieladresse muss doppelten Inhalt oder eine vollständige Obermenge des Ausgangsinhalts liefern. Die Beziehung kann im HTML oder über einen HTTP-Link-Header stehen. Anwendungen können die Zieladresse anzeigen, Linksignale dort bündeln und nur ihren Inhalt verarbeiten. Der RFC legt die Bedeutung der Angabe fest. Er macht aus ihr keine Garantie für eine bestimmte Suchentscheidung.

Sein Beispiel eines mehrseitigen Artikels zeigt den Schaden besonders deutlich. Seite eins und zwei enthalten verschiedene Abschnitte; eine Gesamtansicht enthält beide. Die Teilseiten können sinnvoll auf die Gesamtansicht verweisen. Seite zwei auf Seite eins zu verweisen wäre eine falsche Gleichsetzung. Der RFC warnt, dass dann der besondere Inhalt der zweiten Seite als Dublette unbeachtet bleiben kann. Die Seite selbst bleibt für Leser erreichbar, während ihr Text im Index fehlen könnte.

Der RFC rät außerdem zu genau einer kanonischen Angabe pro Ressource und warnt vor Zielen mit Fehlermeldungen, dauerhaften Weiterleitungen oder weiteren abweichenden kanonischen Zielen. Bei widersprüchlichen Angaben darf die Anwendung eigene Heuristiken einsetzen. Googles heutige Erklärung beschreibt weiterhin eine Auswahl anhand mehrerer Signale, bei der ein anderes Ziel als das vom Betreiber gewünschte herauskommen kann. Die aktuelle Beschreibung belegt den heutigen Ablauf; die Machtverteilung stand bereits in der Antwort von 2009.