Kanonische Adressen
» schneegans.de » Web » Kanonische Adressen
| Danke, Akif! |
» schneegans.de » Web » 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.
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 Make A Shorter Link oder 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.200 OK. Man muß HTTP nicht vorsätzlich vergewaltigen.#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 über 20 derartige Dienste. Wer braucht diesen Schwachsinn, von Twitter mal abgesehen?
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ß.
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.
Basierend auf der Analyse etlicher URLs habe ich folgende Thesen entwickelt:
/index.htm und /index.html hält Google immer für Duplikate von /, auch wenn sie gar nicht existieren./index.php oder /Default.asp werden manchmal als Duplikate von / erkannt, in der Regel aber nicht.www.-Präfix im Hostnamen wird in der Regel als Duplikat erkannt, manchmal aber nicht./, /index.htm und /index.html verschiedene Ressourcen sind, indiziert Google ausschließlich /.dir und dir/ werden trotz korrekter HTTP-Weiterleitung mit Statuscode 301 nicht immer als Duplikate erkannt.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.php | http://www.bundesgerichtshof.de/index.php | q=1900164207331 |
Eine Suche nach url:http://schneegans.de/index.aspx liefert hingegen keine Treffer, kanonische URLs werden offenbar auch von MSN Search honoriert!
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:
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:
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: