Kanonische Adressen

Als Webmaster sollten Sie stets bemüht sein, daß jede Web-Ressource in Ihrem Verantwortungsbereich durch ihre „kanonische“ oder offizielle URL adressiert wird. Und Sie sollten versuchen, auf andere Web-Ressourcen mit ihrer kanonischen URL zu verweisen, die leider nicht immer mit der identisch ist, die in der Adreßzeile des Browsers angezeigt wird. Verwenden Sie also eine URL für eine Ressource.

Diversifikation

Browser, Suchmaschinen und Proxy-Server können im allgemeinen nicht feststellen, daß die URLs

auf dieselbe Ressource verweisen. Wenn Sie mehr als eine URL für eine Ressource verwenden, führt dies zu ineffizientem Caching und verwirrt Besucher, weil ihnen Links auf bereits besuchte Ressourcen als unbesucht präsentiert werden. Wahrscheinlich verschlechtert sich dadurch auch Ihr Google-Ranking, denn der PageRank einer Ressource teilt sich so auf zwei oder mehr URLs auf.

Unnötige Diversifikation kann mehrere Ursachen haben:

Nicht-kanonische Hostnamen

Viele Websites sind mit und ohne www.-Präfix zu erreichen. Das ist gut. Schlecht ist es, wenn sich daraus doppelte URLs ergeben. Sie sollten sich für einen Hostnamen entscheiden. Ob das nun www.example.org oder example.org ist, ist weitgehend Ihrem persönlichen Geschmack überlassen. Ich selbst bevorzuge die Form ohne www., denn man spart sich etwas Tipparbeit, und solch ein Domainname läßt sich viel eleganter durch Subdomains erweitern. Kanonisch sind bspw. www.google.com und groups.google.com – warum heißt es dann nicht www.groups.google.com oder groups.www.google.com? Neuerdings sind www.-lose URLs auch bei Google Groups anklickbar.

Sorgen Sie in jedem Fall dafür, daß alle Anfragen, die nicht über den kanonischen Hostnamen eingehen, mit Statuscode 301 Moved Permanently an den kanonischen weitergeleitet werden.

Mit mod_rewrite gibt es für dieses Problem unter Apache eine elegante Lösung; die Konfiguration wird im URL Rewriting Guide im Abschnitt Canonical Hostnames beschrieben, mit <VirtualHost>- und Redirect-Direktiven sollte es aber auch gehen. Mit CGI analysieren Sie einfach die Umgebungsvariable HTTP_HOST. Einige Provider bieten diesen Service standardmäßig an.

Standard-Dokumente

Die Namen von Standard-Dokumenten wie index.html, Default.aspx, welcome.htm oder start.php haben in URLs nichts verloren. Verlinken Sie einfach das Verzeichnis, die URL endet also mit /.

Häufig werden URLs erst durch Site-interne Links verschandelt. Schreiben Sie nicht <a href="index.html">Home</a>, sondern <a href="./">Home</a> bzw. <a href="../">Home</a>, um auf das aktuelle bzw. das übergeordnete Verzeichnis zu verweisen. Mit <a href="../../"> geht es zwei Ebenen nach oben usw. Absolute Pfade wie <a href="/"> schaden der Kanonizität nicht.

Völlig blödsinnig sind Weiterleitungen wie <meta http-equiv="refresh" content="0; URL=index.php">. Konfigurieren Sie Ihren Server vernünftig, unter Apache etwa mit der DirectoryIndex-Direktive, dann brauchen Sie diesen Quatsch nicht. In IE und Opera läßt sich die Unterstützung für derartige Weiterleitungen übrigens ausschalten, solche Besucher sehen bei Ihnen dann nur eine leere Seite.

Existieren bereits Verweise, die das Standard-Dokument enthalten, können Sie diese unter Apache leicht mit mod_rewrite auf die kanonische Adresse umleiten, also „kanonisieren“:

RewriteEngine On
RewriteCond %{THE_REQUEST} index\.html [NC]
RewriteRule (.*)index\.html http://www.example.org/$1 [NC,R=301]

Für IIS bzw. ASP und ASP.NET ist mir – mal von einem ISAPI-Filter abgesehen – keine entsprechende Methode bekannt, notfalls kann man sich mit JavaScript helfen:

<script type="text/javascript">
indexDocument = /(index|default)\..*/i
if (location.pathname.match(indexDocument)) {
  location.href = location.href.replace(indexDocument, "");
}
</script>

Suchmaschinen interpretieren JavaScript natürlich nicht. Ein HTTP-Modul kann unter ASP.NET aber mit anderen nicht kanonischen URLs aufräumen.

Abfrage-Parameter

Die meisten Webserver ignorieren unbekannte Abfrage-Parameter völlig. Das ist allerdings ungünstig, denn http://www.example.org/, http://www.example.org/?foo und http://www.example.org/?bar sind für Browser und Proxies völlig verschiedene Ressourcen, die nicht mehr miteinander zu tun haben als http://www.example.org/, http://www.example.org/foo und http://www.example.org/bar.

Die Ansicht scheint verbreitet zu sein, ein Webserver müsse Anfragen, die sich nur in den Abfrage-Parametern unterscheiden, auf jeden Fall mit demselben Statuscode beantworten. Das ist natürlich Quatsch. Die Errata zu HTTP 1.1 stellen klar, daß die Abfrage-Parameter mit zur URL gehören.

Mein ASP.NET-Modul kann Anfragen mit unbekannten Abfrage-Parametern mit 404 Not Found beantworten.

TinyURL und Konsorten

Dienste wie TinyURL schaden ebenfalls der Kanonizität von URLs. Und es gibt eine Reihe weiterer Argumente:

Kurz-URLs sind deshalb considered harmful. Nichtsdestotrotz gibt es dutzende derartige Dienste. Wer braucht diesen Schwachsinn, von Twitter mal abgesehen?

Äquivalente URLs

http://www.example.org und HTTP://WWW.EXAMPLE.ORG:80/ sind „äquivalente“ URLs. Äquivalente URLs adressieren immer dieselbe Ressource. Der Entwurf How to Compare Uniform Resource Identifiers von Tim Bray erörtert dieses Thema im Detail. Viele Software-Systeme sind allerdings nicht in der Lage, äquivalente URLs als solche zu erkennen, daher sollten Sie immer exakt dieselbe Schreibweise verwenden. Insbesondere empfiehlt Bray, den Schema-Bezeichner http: kleinzuschreiben, die Buchstaben A bis F in %HH-Sequenzen hingegen groß.

Wie findet Google Duplikate?

Nicht alle Hyperlink-Verweise verwenden also kanonische URLs. Google bemüht sich aber offensichtlich, auch nicht-kanonische Verweise für die PageRank-Berechnung zu berücksichtigen. Dazu muß Google „Duplikate“ erkennen, d.h. nicht äquivalente URLs, die auf dieselbe Ressource verweisen. Ich nehme an, daß Google URLs, die als Duplikate erkannt wurden, einen gemeinsamen PageRank zuweist. Nicht erkannte Duplikate erhalten jeweils einen separaten PageRank, was für das Ranking natürlich von Nachteil ist.

Deshalb läßt sich mit der Google Toolbar feststellen, ob URLs nicht als Duplikate erkannt wurden. Das ist nämlich mindestens dann der Fall, wenn die Toolbar nicht stets denselben PageRank anzeigt.

Eine genauere Analyse ermöglicht der Operator info:. In der Antwort auf eine Anfrage http://www.google.com/search?q=info:http://example.org/ gibt Google u.a. einen Verweis http://www.google.com/search?q=link:1BugCJM-BP4J:example.org/ zurück, der insbesondere die URL enthält, die Google als kanonisch zu der in der ursprünglichen Anfrage übermittelten URL ansieht. Für http://www.google.com/search?q=info:http://www.example.org/ erhält man ebenfalls den o.g. Verweis, die URLs http://www.example.org/ und http://example.org/ betrachtet Google demnach als äquivalent. Die Toolbar bestätigt dies.

info:-URLVon Google erzeugte link:-URLArt der DiversifikationAls Duplikate erkannt
info:http://cdu.de/link:0bb1mgl8--UJ:cdu.de/www.-PräfixNein
info:http://www.cdu.de/link:ICyQoJs7riMJ:www.cdu.de/
info:http://asv.de/link:n_9l_mSCKwgJ:asv.de/www.-PräfixNein
info:http://www.asv.de/link:_HecIpv0bkkJ:www.asv.de/
info:http://t-online.de/link:QVMqNZjgbMIJ:t-online.de/www.-PräfixNein
info:http://www.t-online.de/link:b-wfSs2u4OgJ:www.t-online.de/
info:http://www.bundesgerichtshof.de/link:CLoQqeqVNgoJ:www.bundesgerichtshof.de/Explizite Angabe eines existenten Standard-DokumentsNein
info:http://www.bundesgerichtshof.de/index.phplink:EreUSNpcefsJ:www.bundesgerichtshof.de/index.php
info:http://www.heise.de/link:4t4qfPokyvMJ:www.heise.de/Explizite Angabe eines existenten Standard-DokumentsNein
info:http://www.heise.de/default.shtmllink:yCghO_na5t8J:www.heise.de/default.shtml
info:http://support.microsoft.com/link:jZt5LPPCHnYJ:support.microsoft.com/Explizite Angabe eines nicht existenten Standard-DokumentsJa, aber kein Duplikat
info:http://support.microsoft.com/index.html
info:http://support.microsoft.com/index.htm
info:http://www.google.com/link:zhool8dxBV4J:www.google.com/Keine, URLs sind äquivalentJa
info:HTTP://WWW.GOOGLE.COM/
info:http://www.google.com:80/
info:HTTP://WWW.GOOGLE.COM:80/
info:http://dmoz.org/World/Deutsch/link:v80DVW5UGkMJ:dmoz.org/World/Deutsch/WeiterleitungJa
info:http://dmoz.org/World/Deutsch
info:http://jendryschik.de/wsdev/link:XMSb-XHvP2kJ:jendryschik.de/wsdev/WeiterleitungNein
info:http://jendryschik.de/wsdev-
info:http://www.aspfaq.de/index.asp?OPID=20&FID=108...link:_jaZlpB6nqQJ:www.aspfaq.de/index.asp?RID=4&FID=108...Reihenfolge der ParameterJa
info:http://www.aspfaq.de/index.asp?OPID=20&ELE=9400...
info:http://www.aspfaq.de/index.asp?OSFI=0&FID=108...
info:http://www.aspfaq.de/index.asp?RID=4&ELE=9400...

Basierend auf der Analyse etlicher URLs habe ich folgende Thesen entwickelt:

Man kann sich also nicht darauf verlassen, daß Google nicht äquivalente URLs zuverlässig als Duplikate erkennt. Sie müssen selbst für kanonische URLs sorgen.

Bei MSN Search ist die Situation ähnlich, der Bundesgerichtshof ist auch hier zweimal im Index vertreten:

Abfrage mit Schlüsselwort url:Trefferliste„Zwischengespeicherte Seite“
url:http://www.bundesgerichtshof.de/http://www.bundesgerichtshof.de/q=1893514699709
url:http://www.bundesgerichtshof.de/index.phphttp://www.bundesgerichtshof.de/index.phpq=1900164207331

Eine Suche nach url:http://schneegans.de/index.aspx liefert hingegen keine Treffer, kanonische URLs werden offenbar auch von MSN Search honoriert!

Persistenz

PURLs haben eine viel bessere Persistenz als gewöhnliche URLs. Sie bleiben sogar nach dem Wechsel der Domain gültig. Ich benutze sie allerdings nicht, denn sie haben leider einen großen Nachteil – die URL, die der Browser in der Adreßleiste anzeigt, ist nicht die kanonische. Das (korrekte) Setzen von Links und Lesezeichen wird so deutlich komplizierter. Wenn Sie PURLs verwenden, weisen Sie Ihre Besucher immer auf die kanonische URL, also die PURL, hin, aber erwarten Sie nicht, daß alle Links und Lesezeichen die PURL verwenden.

Ich bin der Auffassung, daß sich die kanonische URL einer Ressource gelegentlich ändern darf. Sie müssen natürlich dafür sorgen, daß die alte URL nicht stirbt, indem Sie eine passende Weiterleitung einrichten. Man spart sich freilich eine Menge Arbeit, wenn man von vornherein auf persistente URLs achtet.

Ich halte es allerdings für wichtig, deutlich zwischen Persistenz und Kanonizität zu unterscheiden. Diese beiden Eigenschaften sind oft korreliert, hängen aber nicht kausal voneinander ab.

Kurze URLs für wichtige Inhaltsanbieter

Wichtiger als Kanonizität ist hier die möglichst kompakte Darstellung. Lange URLs werden in E-Mails und Usenet-Postings häufig umbrochen und sind dann nicht mehr anklickbar.

Google

Im allgemeinen benötigen Links auf Google-Suchergebnisse nur den q-Parameter:

Wenn der Suchbegriff Nicht-ASCII-Zeichen enthält, müssen Sie den ie-Parameter beibehalten, in dem die Eingabecodierung („input encoding“) spezifiziert wird:

Andernfalls entscheidet Google idiotischerweise anhand des User-Agent-Headers, wie die URL decodiert wird. Das führt dazu, daß

mit User-Agent: Mozilla/4.76 [en] (Windows NT 5.0; U) nach „paul cézanne“ sucht, mit User-Agent: Opera/8.52 (Windows NT 5.1; U; en) aber nach „paul cézanne“.

Usenet-Postings

Auf Usenet-Postings kann über eine URL des in RFC 1738 definierten news:-Schemas verwiesen werden. Einige Newsreader unterstützen news:-URLs besser als „rohe“ Message-IDs. Enthält die Message-ID das Zeichen %, muß dieses durch %25 maskiert werden. Anschließend wird einfach news: vor die Message-ID gesetzt:

Die Angabe eines Servers ist in einer news-URL zwar nicht RFC-konform, wird aber trotzdem von vielen Newsreadern unterstützt. Diese Variante ist sinnvoll, wenn der Artikel nicht im Usenet steht:

Gelegentlich findet man Software, die ungültige URLs wie bspw.

generiert. Lassen Sie sich davon nicht irritieren und vertrauen Sie im Zweifelsfall nur RFC 1738. Für ungeeignet halte ich allerdings das RFC-konforme nntp-Schema, weil solche URLs nicht die Message-ID des Artikels enthalten:

Die Artikelnummer ist völlig nutzlos, wenn der Artikel auf dem angegebenen Server abgelaufen ist. Mit der Message-ID kann man hingegen auf anderen Servern und auch bei Google Groups suchen.

Eine bessere Persistenz und Usability erreichen Sie, wenn Sie auf Googles Usenet-Archiv verweisen. Sie sollten auch hier stets eine URL angeben, aus der sich die Message-ID unmittelbar ableiten läßt. Für ein einzelnes Posting verwenden Sie den selm-Parameter:

Auf einen kompletten Thread verweisen Sie mit dem threadm-Parameter:

Der Artikel braucht nicht der erste in einem Thread zu sein:

Bedauerlicherweise verwendet Google selbst folgende Form:

Diese URL erlaubt keine Rückschlüsse auf die Message-ID, und Sie sollten sie daher nicht weitergeben. Um eine URL mit Message-ID zu erhalten, können Sie folgendermaßen vorgehen:

  1. Klicken Sie auf den Link Original anzeigen bzw. Show original.
  2. Suchen Sie die Zeile, die mit Message-ID: beginnt, und kopieren die Zeichenfolge zwischen den spitzern Klammern in einen Texteditor.
  3. Ersetzen Sie alle Vorkommen des Zeichens % durch %25 und anschließend alle Vorkommen des Zeichen # durch %23. Es ist möglicherweise sinnvoll, ferner das Zeichen @ durch %40 zu ersetzen, sonst ist der Link ausgerechnet in Google nur nach manueller Freigabe erreichbar.
  4. Setzen Sie http://groups.google.com/groups?threadm= bzw. http://groups.google.com/groups?selm= vor die Message-ID.

Viel bequemer finde ich allerdings dieses .NET-Programm, dessen Quelltext ebenfalls verfügbar ist. Das Programm sollte jede beliebige Google-Groups-URL in der Zwischenablage verarbeiten und die kanonisierte Fassung wieder in der Zwischenablage abgelegen. Wenn man bspw. in der Schnellstartleiste eine Verknüpfung anlegt, geht das ziemlich flott. Sie benötigen .NET Framework Version 2.0.

MSN Suche

Man muß natürlich zeigen, daß man ASP.NET verwendet. Klar, das ist viel wichtiger als stabile URLs.

Microsoft Knowledge Base

KB-Artikel erhält man mit URLs der Form http://support.microsoft.com/kb/325047/ in der im Browser eingestellten Sprache. Dummerweise wird die Mehrzahl der Artikel maschinell übersetzt, und die Qualität der Übersetzung ist größtenteils so erbärmlich, daß man den Inhalt nur noch mit Mühe versteht. Es empfiehlt sich deshalb meistens, explizit auf das englische Original zu verweisen. Dies geschieht mit einer URL der Form http://support.microsoft.com/kb/325047/en-US.

Leider gibt es weiterhin etliche nicht-kanonische Formen, die auf Microsofts Website selbst verlinkt werden und von Google bereits indiziert wurden:

Amazon

URLs bei Amazon sind oft umständlich lang. Eine kompakte Darstellung sieht folgendermaßen aus:

Sie müssen die URL, die Ihnen beim Durchstöbern des Angebots präsentiert wird, manuell kürzen, die Vorgehensweise sollte aber klar geworden sein.

Wenn es noch kürzer sein soll, kann man die Zeichenfolge exec/obidos durch o ersetzen und das www.-Präfix und den abschließenden / weglassen:

Bugzilla

Einzelne Bugs werden natürlich so verlinkt:

Hingegen ist bei Links auf Suchergebnisse stets eine manuelle Nachbearbeitung erforderlich, die vom System erzeugten URLs sind ausgesprochen unhandlich und erreichen schnell Längen von über 400 Zeichen.

Üblicherweise ist es zweckmäßig, Suchbegriffe in der „summary“ des Bugs zu suchen; diese geben Sie in jedem Fall im short_desc-Parameter an. Benutzen Sie

für einen Vergleich contains all of the words, und

für einen Vergleich contains all of the words/strings.

Vermeiden Sie unbedingt diese Variante:

Dadurch wird das Suchergebnis überraschenderweise überhaupt nicht eingeschränkt, und Sie erhalten eine Liste aller Bugs in der Bugzilla-Datenbank. Und das können durchaus ein paar Megabyte sein…

RFCs

RFCs gibt es bei der IETF im text/plain-Format:

Heise-Newsticker

Die URLs im Heise-Newsticker sind recht länglich:

Sie lassen sich aber glücklicherweise kürzen, und der bevorzugte Permalink wird auf der Seite auch gleich angezeigt: