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. Google selbst empfiehlt dieses Vorgehen.
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:
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.
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.
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.
Dienste wie TinyURL schaden ebenfalls der Kanonizität von URLs. Und es gibt eine Reihe weiterer Argumente:
as long as possible gültig bleiben, aber das ist natürlich keine Garantie, und überleben kann die Kurz-URL das Original sowieso nicht, sofern sie nicht administrierbar ist. Außerdem lassen sich allein der Zeichenkette, die eine URL ausmacht, viele Informationen
entnehmen, die bei der weiteren Suche nach der Ressource helfen. Bei Kurz-URLs ist das nicht möglich.
#Textmarke) sind im HTTP-
Location-Header erst durch die
Errata erlaubt und angehängt an die Kurz-URL werden sie bspw. von Opera nach der Weiterleitung ignoriert.
Kurz-URLs sind deshalb
considered harmful
. Nichtsdestotrotz gibt es dutzende derartige Dienste. Wer braucht diesen Schwachsinn?
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ß.
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.
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.
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“.
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:
Original anzeigenbzw.
Show original.
Message-ID: beginnt, und kopieren die Zeichenfolge zwischen den spitzern Klammern in einen Texteditor.
% 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.
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.
Man muß natürlich zeigen, daß man ASP.NET verwendet. Klar, das ist viel wichtiger als stabile URLs.
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 unterstützt kompakte URLs, die eine ASIN enthalten:
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 gibt es bei der
IETF im
text/plain-Format:
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: