Canonical Link
Die ursprüngliche Idee der Adressen im Web beinhaltet auch, dass man über eine Adressangabe eine Seite finden kann. Schließlich heißt der Fachbegriff nicht umsonst URI — Uniform Resource Identifier. Es gibt aber zahlreiche Beispiele, bei denen das nicht der Fall ist. Oft sind Session-IDs, Query-Parameter oder andere temporäre Informationen in der Adresse enthalten. Die machen es schwierig, sich eine solche Seite zu merken (Bookmark, Favorit) oder die Adresse weiterzugeben. Für Googles Suchmaschine ist es offensichtlich ein Problem, dass eine Seite unter verschiedenen URIs gefunden werden kann. Grund genug für Google, einen eigenen Weg vorzuschlagen, dem sich aber andere anschließen.
Der Weg besteht darin, dass Webadmins ein Element der unten beschriebenen Bauart in ihre Seiten einbauen können, und damit einen kanonischen URI (in diesem Fall auch ein URL) für die jeweilige Seite angeben können. Ein Beispiel:
Nehmen wir an, ein Benutzer A hat eine Seite in einem Online-Shop über die normale Navigation erreicht und der Browser zeigt die Adresse
http://www.example.com/shop?products=xml&sort=price&session=xcvch5667
Ein anderer Benutzer B gelangt zur Seite mit der Adresse
http://www.example.com/shop?products=xml&sort=date&session=abbhj9336
Beide Seiten enthalten dieselben Produkte zum Thema XML; einmal nach Preis, ein anderes Mal chronologisch sortiert. Die Session-ID ist für die Seite völlig irrelevant. Der Shop braucht sie, um den Benutzer eindeutig zu identifizieren.
Ein Suchmaschinen-Crawler kann nicht ohne Weiteres entscheiden, ob es sich um zwei Adressen für dieselbe Seite handelt. An dieser Stelle kann der Webadmin eingreifen und folgendes Element in den Kopf der HTML-Seite einfügen:
<link rel=”canonical” href=”http://www.example.com/shop?products=xml” />
Maßgeblich ist hierbei die Angabe rel=”canonical”. Google beschreibt diese Konvention in einem Blogbeitrag. Des Weiteren heißt es dort, dass neben Google auch Ask.com, Microsoft und Yahoo die “kanonischen Links” unterstützen. Die dem Blogbeitrag folgende Diskussion geht auch darauf ein, dass HTTP bereits etwas entsprechendes anbietet (Content-Location). Eine Antwort, die vermutlich von einem Google-Mitarbeiter stammt, besagt, dass die Content-Location-Angaben, die von Webservern aktuell versendet werden (falls überhaupt), nicht brauchbar sind.
Fazit
Dass sich jemand des Problems angenommen hat, finde ich sehr gut. Schade ist, dass der vorhandene Standard (HTTP) so wenig Beachtung fand und die wenige Beachtung, die es gibt, (laut Google) keine brauchbaren Daten liefert. Für die Zukunft wäre wünschenswert, dass die kanonischen URIs sich weiter durchsetzen; z.B. für Bookmarks im Browser.
Wir werden die Konvention jedenfalls in der von uns entwickelten Software unterstützen.