1. Herfried K. Wagner’s VB.Any
  2. Web
  3. Artikel

Benutzerfreundliche URIs

Einleitung

Um das Gebiet der visuellen Gestaltung von Ressourcen für die Veröffentlichung im Web sind bereits eigene Berufsbilder entstanden. Vielfach bleibt jedoch unberücksichtigt, daß es sich bei den URIs der Ressourcen einer Website ebenfalls um eine Form der Benutzerschnittstelle handelt, deren Gestaltung bedachtsam erfolgen sollte. Es ist unzureichend, das Erstellen von Websites auf deren visuelle Gestaltung zu reduzieren. Folgende Liste zeigt Veröffentlichungen, die Hinweise und Leitlinien zur Wahl sinnvoller URIs enthalten:

Einige Negativbeispiele für die Gestaltung von URIs werden in „Bekloppte URIs“ vorgestellt. Die Syntax von URIs wird in Uniform Resource Identifiers (URI): Generic Syntax spezifiziert. Während URIs mit verschiedensten Schemata Einsatz finden, konzentriert sich dieser Artikel auf URIs für das Schema HTTP, wie sie im Web zum Einsatz gelangen und wo sie von den meisten Menschen wahrgenommen werden. Auf konkrete Implementierungshinweise wurde verzichtet, wo diese nicht unbedingt zur Erläuterung erforderlich sind.

In den folgenden Beispielen werden URIs der Form http://www.example.org/foo/ anstelle von http://www.example.org/foo gezeigt. Welcher der beiden Formen der Vorzug zu geben ist, ist letztlich Geschmackssache. Üblich ist eine serverseitige Weiterleitung von http://www.example.org/foo auf http://www.example.org/foo/, wenn die Datei foo auf dem Server nicht existiert. Der Schrägstrich am Ende des URIs zeigt an, daß der URI auf das Standarddokument eines Verzeichnisses zeigt.

Eigenschaften von URIs

Für das Verständnis der nachfolgend vorgestellten Leitlinien zur Gestaltung von URIs ist es notwendig, zwischen zwei Eigenschaften von URIs zu unterschieden:

Die Eigenschaften Persistenz und Kanonizität stehen nicht in direktem Zusammenhang zueinander. Dennoch kann die bedachtsame Wahl des kanonischen URIs es erleichtern, dessen Persistenz zu gewährleisten. Der Aufwand für die Konfiguration von URIs läßt sich verringern, indem eine Vielzahl an URIs zur Bezeichnung einer bestimmten Ressource vermieden wird. Zudem verbessert eine geschickte Auswahl von URIs deren Benutzbarkeit für den Menschen.

Der zur Garantie der beiden Eigenschaften erforderliche Aufwand ist im Vergleich zu jenem, der notwendig wird, wenn ungeeignete URIs gewählt wurden, gering. Berücksichtigt werden muß auch, daß URIs, wurden sie erst einmal bekannt gemacht, meist vielfach benutzt werden und selbst kleine Zeiteinsparungen bei der Benutzung in Summe eine wesentliche Verbesserung der Benutzbarkeit darstellen.

Leitlinien für den Entwurf von URIs

Es lassen sich folgende Entwurfsziele für URIs formulieren, die sich aus der Verwendung von URIs durch Mensch und Computer ergeben:

Auf Basis dieser Ziele wurde die folgende Liste von Leitlinien entwickelt, die für Entwurf und Analyse von URIs herangezogen werden können. Die einzelnen Leitlinien werden durch Beispiele aus der Praxis und die Betrachtung verschiedener Lösungsalternativen veranschaulicht.

URIs sollten bedeutungstragende Bezeichner sein und müssen nicht Pfadangaben in einem Dateisystem entsprechen.

URIs müssen und sollen vielfach nicht den Pfaden, also Verzeichnis- und Dateinamen, unter denen die Ressourcen auf dem Server physisch abgelegt sind, entsprechen. Gute Webserver bieten die Möglichkeit der freien Konfiguration von URIs, die deren beliebige Zuordnung zu Ressourcen auf dem Server einschließt.

Die Anordnung von Seiten in Ordnern und die Benennung von HTML-Dateien sollen nicht zum Ziel haben, deren Verwaltung durch den Webmaster zu erleichtern, sondern einziges Ziel sollte die Vereinfachung des Auffindens und die konsistente Benutzung durch den Besucher der Website sein. Schließlich wird weit mehr Zeit mit dem Besuchen von Websites verbracht, als mit deren Wartung.

Obwohl es sich bei URIs nicht um Pfadangaben in einem Dateisystem handelt, besitzt der Schrägstrich („/“) die Funktion des Hierarchietrennzeichens. Ähnlich zu Pfadangaben kann über relative URIs aus Ressourcen zu anderen Ressourcen verwiesen werden. Ein Hyperlink mit Zieladresse ./../../ auf der Seite http://www.example.org/2006/articles/web/ würde beispielsweise in den URI http://www.example.org/2006/ aufgelöst.

Unterdomänen sollten logisch strukturieren und müssen nicht notwendigerweise der physischen Organisation der Server entsprechen.

Die Namen von Domänen und Unterdomänen sollten nicht vorwiegend die physische Organisation der Server wiedergeben, sondern die Bedeutung der Server. Domänen wie www.example.org und www2.example.org sind daher zu vermeiden. Die Lastverteilung auf mehrere Webserver kann immer noch für den Benutzer transparent auf der Serverseite erfolgen. Bei Einführung von Unterdomänen gilt zu beachten, daß damit die Möglichkeit des relativen Verweisens auf Ressourcen einer der anderen Unterdomänen verloren geht.

In URIs für das Web wird, historisch bedingt, HTTP-URIs häufig die Unterdomäne www dem Domänennamen vorangestellt. Dies ist technisch zwar nicht erforderlich, kann aber helfen, den URI in Angaben ohne Protokoll leichter als solchen erkennbar zu machen. Eine der beiden Varianten, also http://www.example.org/ oder http://example.org/, sollte als kanonische Form festgelegt und von anderen Formen auf diese weitergeleitet werden. Insbesondere im kommerziellen Umfeld ist die Nutzung der Unterdomäne www ratsam.

Serverseitige technische Details wie eingesetzte Technologien sollten nicht in URIs aufscheinen.

Im Laufe der Zeit können die am Webserver und auf Seiten des Benutzers eingesetzten Technologien gegen andere Technologien ausgetauscht werden. Bestehende URIs, die an bestimmte Technologien gebunden sind, verlieren damit ihre Gültigkeit und Umleitungen müssen eingerichtet werden. Dies kann dazu führen, daß URIs eine unzutreffende Bedeutung erlangen, etwa, wenn http://www.example.org/foo.html eine XPS-Datei zurückgeben würde, weil die Ressource nicht mehr im HTML-Format erhältlich ist.

Dateinamenserweiterungen wie .cgi, .php und .aspx sollten ebenfalls nicht in URIs aufscheinen. Dies gilt auch für serverseitige Skripte und Verzeichnisse, in denen enthaltene Skriptdateien zur Ausführung freigegeben wurden. Auch diese sind ein serverseitiges Detail, das für den Benutzer keine Bedeutung besitzt, sondern im Gegenteil, die Suche nach Sicherheitslücken des Servers erleichtert. Anstelle von http://www.example.org/cgi-bin/search.pl?q=Hello bietet sich ein URI wie http://www.example.org/search/?q=Hello an.

Selbst Anfrageparameter können in einigen Fällen versteckt werden, indem etwa anstelle von http://www.example.org/books/?isbn=3794602048 der URI http://www.example.org/books/3794602048/ benutzt wird. Einerseits wird dadurch der URI kompakter, andererseits wird das serverseitige Implementierungsdetail des Skripts, das die zur ISBN-Nummer gehörige Information zurückgibt, für den Benutzer transparent gemacht.

Der Dateiname von Verzeichnisstandarddokumenten sollte nicht in URIs aufscheinen.

Standarddokumente sind jene Dokumente, die für URIs, welche auf ein Verzeichnis verweisen, zurückgegeben werden. Eine Anfrage mit dem URI http://www.example.org/foo/ würde das Standarddokument des Verzeichnisses foo anfordern. Unter vielen Webservern wird das Standarddokument eines Verzeichnisses als Datei gespeichert. Der Name dieser Datei richtet sich dabei oft nach der serverseitig eingesetzten Technologie, sodaß bei einem Technologiewechsel Dateien umbenannt oder die Konfiguration des Servers angepaßt werden müßten.

Der Name der Dateien, in denen die Standarddokumente gespeichert sind, hat für den Benutzer keine Bedeutung. Anstelle von URIs wie http://www.example.org/articles/default.aspx sollte daher http://www.example.org/articles/ als kanonische Form benutzt werden. Durch Setzen eines passenden Statuscodes können Suchmaschinen angewiesen werden, URIs mit expliziter Angabe des Dateinamens wie http://www.example.org/articles/default.aspx nicht zu indizieren. Sofern URIs mit expliziter Dateiangabe in Umlauf geraten, wäre es notwendig, Weiterleitungen einzurichten, damit bestehende Hyperlinks weiterhin auf die Ressource verweisen.

URIs sollten für den Benutzer relevante Information enthalten, bedeutungslose Identifikationsnummern sollten vermieden werden.

Für den Benutzer bedeutungslose Information wie interne Identifikationsnummern, beispielsweise GUIDs oder Kennzahlen, sollten in URIs vermieden werden. URIs, die Identifikationsnummern enthalten, finden sich häufig bei Websites, deren Inhalte in Datenbanktabellen abgelegt sind. Dies ist bei einigen Inhaltsverwaltungssystemen der Fall. Die Folge davon sind meist unhandliche URIs wie http://www.example.org/index.php?article_id=982361. Geeigneter wäre der URI http://www.example.org/articles/982361/, wobei im Idealfall auch die Artikelkennzahl vermieden werden kann, sofern es sich dabei nicht um eine bekannte und bedeutungsvolle Artikelnummer handelt.

Ausnahmen bilden Identifikationsnummern wie ISBN und Angebotsnummern, die eine Bedeutung für den Benutzer besitzen und damit wichtige Information transportieren. So könnte eine Liste von Büchern unter URIs wie http://www.example.org/books/3794602048/ verfügbar gemacht werden, wobei die Nummer am Ende des URIs der ISBN eines Buches entspricht. Bei Angebot von Produkten auf einer Website bieten sich URIs wie http://www.example.org/shop/products/932457/ für die einzelnen Produktbeschreibungen an.

Die bei einigen Weblogs üblichen dauerhaften URIs wie http://www.example.org/PermaLink.aspx?guid=d57ace50-2762-4b19-b07d-39421829d410 sind ungeeignet, da Details der serverseitigen Implementierung offen gelegt und darüberhinaus die nicht auf die Lesbarkeit durch den Menschen hin optimierten GUIDs benutzt werden. Bei Weblogs geeigneter ist die Anordnung der Artikel nach dem Datum ihrer Erstellung, versehen mit einer laufenden Artikelnummer pro Tag oder einem sprechenden Titel wie http://www.example.org/blog/2006/01/22/1/ oder http://www.example.org/blog/implementing-web-services/.

Ausnahmen stellen beispielsweise Webforen dar, in denen den einzelnen Artikeln aufgrund mangelnder Struktur und hoher Zahl keine sinnvollen sprechenden URIs zugeordnet werden können. Dennoch ist auch hier darauf zu achten, daß die benutzten Identifikationsnummern minimal sind und nicht wie GUIDs immer eine feste Länge einnehmen, sondern etwa laufende Artikelnummern mit zufälligem Anteil darstellen. Auch die Sortierung nach dem Datum, wie sie zuvor am Beispiel von Weblogs beschrieben wurde, kann sinnvoll sein. Im URI http://www.example.org/forum/2006/05/t130140/ wird die laufende Threadnummer mit dem Erstellungsdatum in Zusammenhang gebracht.

Der Inhaltstyp von Ressourcen sollte nicht in deren URIs aufscheinen, wenn dies nicht unbedingt erforderlich ist.

Wenngleich zur Zeit Webseiten häufig im HTML-Format vorliegen, kann in Zukunft eine andere Technologie zur deren Codierung eingesetzt werden. Die konsequente Umstellung von HTML auf XHTML könnte bereits die Änderung der Dateinamenserweiterungen von .html in .xhtml erfordern. In Folge wäre es notwendig, eine dauerhafte Weiterleitung von http://www.example.org/joe/cv.html auf http://www.example.org/joe/cv.xthml einzurichten.

Daher empfiehlt es sich, den Inhaltstyp einer Ressource oder einer Gruppe von Ressourcen semantisch gleichbedeutenden Inhalts im URI nicht anzugeben. Ein URI wie http://www.example.org/joe/cv/ wäre nicht an einen bestimmten Inhaltstyp der Ressource gebunden und könnte den Inhalt mittels Content Negation in passender Form codiert zurückgeben. Daneben können URIs zu den verschiedenen zur Auswahl stehenden Inhaltstypen einer Ressource definiert werden, um deren spezifische Ansteuerung zu ermöglichen.

In URIs sollte zwischen Ländern und Sprachen unterschieden werden.

Bei der Gestaltung von URIs muß zwischen Ländern und Sprachen unterschieden werden. Ein Unternehmen kann in mehreren Ländern tätig sein. In einem Land können ein oder mehrere Sprachen und eine Sprache kann zugleich in mehreren Ländern gesprochen werden. So könnte ein Anbieter unterschiedliche Inhalte in Deutschland und Österreich anbieten, obwohl in beiden Ländern Deutsch gesprochen wird. Die Website eines Unternehmens in Polen könnte Inhalte sowohl in Polnisch als auch in Deutsch zur Verfügung stellen.

Domänen oberster Ebene wie .de, .at und .pl sind Staaten zugeordnet. Sie bezeichnen nicht bestimmte Sprachen, auch wenn die meisten Websites mit .de-Domäne in Deutsch verfaßt sind. Ist ein Anbieter sowohl in Deutschland als auch in Österreich aktiv, könnte er die Domänen example.de und example.at nutzen. Die beiden Websites sind in Deutsch gehalten, weisen aber länderspezifische Inhalte auf. Als Alternative zu mehreren Domänen oberster Ebene könnten für die Länder Unterdomänen wie de.example.org und at.example.org einer länderunabhängigen Domäne eingesetzt werden.

Werden Ressourcen in mehreren Sprachen unter einer Domäne angeboten, bestehen mehrere Möglichkeiten: Über Content Negotiation könnte bei Adressierung einer Ressource über einen URI wie http://www.example.org/angebote/ die Ressource in einer plausiblen Sprache zurückgegeben werden. Zudem könnte dem Benutzer die Möglichkeit der Sprachauswahl geboten werden, wobei die gewählte Sprache clientseitig in einem Cookie oder bei erforderlicher Anmeldung serverseitig in einem Profil gespeichert wird.

Alternativ oder zusätzlich kann eine bestimmte Sprachversion einer Ressource über einen eigenen URI bezeichnet werden. Üblich sind URIs wie http://www.example.org/de/artikel/, http://www.example.org/artikel.de, http://de.example.org/artikel/ und http://www.example.org/articles/?lang=de. Werden die Teile des URI hinter dem Domänennamen lokalisiert, sind die Namen zwar für Benutzer einer bestimmten Sprache leichter verständlich, der Wechsel zwischen verschiedenen Sprachversionen einer Ressource durch einfaches Austauschen des Sprachkürzels im URI wird jedoch erschwert.

Die Liste der Anfrageparameter in URIs sollte minimal sein.

Bei Verwendung von Anfragezeichenfolgen sollten serverseitig erstellte URIs immer eine minimale Anzahl an Parametern enthalten, um die Lesbarkeit zu verbessern und das Setzen von Hyperlinks auf die Seite zu vereinfachen. Insbesondere Sitzungskennzahlen und nicht gesetzte Optionen sollten in URIs nicht aufgeführt werden. Werden für in der Anfragezeichenfolge nicht aufgeführte Parameter Standardwerte definiert, können die Parameter weggelassen werden, wenn der Standardwert übergeben werden soll.

Zusätzlich sollte darauf geachtet werden, daß bei kanonischen URIs die Reihenfolge und Codierung der Parameter eindeutig festgelegt ist. Durch diese Maßnahme wird die Verarbeitung mehrerer URIs einer Domäne durch den Menschen erleichtert. Werden ungültige Parameter oder Parameterwerte angegeben, sollte durch Setzen des passenden Statuscodes angezeigt werden, daß die Ressource nicht existiert. Damit kann die Indizierung des URIs durch Suchmaschinen verhindert werden.

Das schrittweise Verkürzen der URIs durch den Benutzer sollte unterstützt werden.

Die aus dem URI http://www.example.org/web/articles/xhtml/ durch Verkürzen abgeleiteten URIs http://www.example.org/, http://www.example.org/web/, http://www.example.org/web/articles/ und http://www.example.org/web/articles/xhtml/ sollten zu Dokumenten führen. Von diesen Seiten aus kann auf die direkten Unterdokumente der jeweiligen Seite verwiesen werden. So könnte unter http://example.org/web/articles/ eine Übersicht der zum Thema Web verfügbaren Artikel bereitgestellt werden. Die URIs geben die Struktur der Website konsistent wieder.

Zugriffe über nicht-kanonische URIs sollten zum kanonischen URI weitergeleitet werden, um die Verbreitung nicht-kanonischer URIs zu verringern.

Jede Ressource besitzt zu jedem Zeitpunkt genau einen kanonischen URI. Ist die Ressource auch unter anderen URIs erreichbar, etwa aus Gründen der Kompatibilität zu bestehenden Hyperlinks oder um auf häufige Fehleingaben benutzerfreundlich reagieren zu können, so sollte eine dauerhafte Weiterleitung auf den kanonischen URI erfolgen, um zu vermeiden, daß die nicht-kanonischen URIs der Ressource weiter verbreitet werden.

Theoretisch ist es zwar nicht erforderlich, eine Ressource überhaupt unter mehr als einem URI bereitzustellen, in der Praxis existieren jedoch Fälle, in denen diese Vorgehensweise sinnvoll ist: Aus Gründen der Benutzbarkeit sollte es irrelevant sein, ob der Benutzer eine Seite über einen URI ansteuert, in dem Groß- und Kleinschreibung nicht mit der Schreibung des kanonischen URIs übereinstimmen. Weiterhin sollte es nicht relevant sein, ob der Benutzer abschließende Schrägstriche anführt oder wegläßt.

Fehleingaben in URIs bei Anfragen sollten tolerant verarbeitet werden.

Durch Analyse von Zugriffsprotokollen können häufige Fehleingaben von Verzeichnis- und Dokumentnamen in URIs ermittelt und dauerhafte serverseitige Weiterleitungen eingerichtet werden. Kann aufgrund der Zieladresse der Anfrage nicht eindeutig entschieden werden, welchen URI der Benutzer eingeben wollte, bietet sich an, in die zurückgegebene Seite die möglichen URIs in Form von Hyperlinks aufzuführen und dem Benutzer die Auswahl zu überlassen. Durch Zurückgebe eines passenden Statuscodes kann verhindert werden, daß Suchmaschinen den falsch geschriebenen URI indizieren.

Besteht die Gefahr, daß Benutzer Domänennamen falsch schreiben, empfiehlt es sich, Anfragen, die über diese Domänennamen eintreffen, auf die kanonische Domäne weiterzuleiten. So könnte von http://www.exmple.org/articles/ eine Weiterleitung auf http://www.example.org/articles/ eingerichtet werden. Dies betrifft auch die Verwendung von Unterdomänen. http://example.org/articles/ könnte auf das kanonische http://www.example.org/articles/ weitergeleitet werden oder umgekehrt. Auch die Weiterleitung von http://www.example.org/foo auf das kanonische http://www.example.org/foo/ oder umgekehrt ist sinnvoll.

URIs sollten das Wachstum der Website unverändert überdauern.

Bereits beim Entwurf von URIs sollte das mögliche Wachstum der Website berücksichtigt werden. Insbesondere eine Trennung zwischen aktuellen Ressourcen und Archiv, bei der nicht mehr aktuelle Inhalte in das Archiv verschoben werden, kann problematisch sein. Ist etwa die aktuelle Ausgabe einer Zeitschrift unter dem URI http://www.example.org/issues/current/ abrufbar, würde sich die durch den URI bezeichnete Ressource bei erscheinen jeder neuen Ausgabe ändern. Bestehende Hyperlinks mit dieser Zieladresse könnten zwar weiterhin aufgelöst werden, würden aber nicht auf jene Ressource verweisen, auf die ursprünglich verwiesen wurde.

Eine mögliche Lösung stellt das Einrichten einer dauerhaften Weiterleitung von http://www.example.org/issues/current/ auf den kanonischen URI der jeweils gerade aktuellen Ausgabe dar. So würde im März 2006 auf http://www.example.org/issues/2006/03/ weitergeleitet. Benutzer können dann über den URI http://www.example.org/issues/current/ auf die aktuelle Ausgabe zugreifen, ohne Datum und Nummer der Ausgabe kennen zu müssen. Zudem wird die Möglichkeit des direkten Verweisens auf eine bestimmte Ausgabe geboten.

Geeigneter als die Anordnung der Inhalte nach thematischen Kategorien direkt nach dem Domänennamen ist die Anordnung der Inhalte anhand ihres Veröffentlichungsjahres, etwa http://www.example.org/2006/articles/web/xhtml/ anstelle von http://www.example.org/articles/web/xhtml/. Die Angabe des Jahres direkt nach dem Domänennamen und noch vor dem Kategoriennamen hat den Vorteil, daß die Bedeutung der Kategorie aus der enthaltenen Jahreszahl erschlossen werden kann und Kategorien im Laufe der Jahre verschwinden können.

Genutzte Domänen sollten nicht abgegeben werden.

Während mittels Weiterleitungen alle Szenarien des Umzugs von Ressourcen innerhalb einer oder mehrerer kontrollierter Domänen gelöst werden können, kann der Verlust der Kontrolle über einen Domänennamen dazu führen, daß URIs dauerhaft ungültig werden, weil keine Weiterleitungen eingerichtet werden können. Eine mögliche Lösung dieses Problems stellen PURLs dar. In der Praxis sollte es jedoch ausreichen, sicherzustellen, daß Domänen nicht irrtümlich in fremde Hände gelangen.

Bei Fusion mehrerer Unternehmen oder Aufkauf eines anderen Unternehmens sollten die Domänennamen der ursprünglichen Unternehmen nicht aufgegeben werden. Stattdessen können Weiterleitungen von den alten Domänen zu der neuen Domäne eingerichtet werden. Soweit sinnvoll sollten auch die URIs zu einzelnen Ressourcen einer bestimmten Domäne des alten Unternehmens weiterhin auf diese Ressourcen verweisen, selbst wenn sie mit neuen kanonischen URIs versehen und physisch auf dem neuen Server abgelegt wurden.

URIs sollten sich für die Verwendung und Übertragung abseits des Computers eignen.

URIs werden in zunehmendem Maße in Medien abseits des Computers wiedergegeben, etwa auf Werbeplakaten, als Beschriftung auf Fahrzeugen und Schaufenstern, auf Visitenkarten, in Zeitungen, Zeitschriften und Büchern sowie in Radio und Fernsehen. Im direkten Gespräch oder am Telefon werden URIs in gesprochener Form übermittelt. Daher empfiehlt es sich, bei der Gestaltung von URIs diese Arten der Verwendung zu berücksichtigen. URIs sollten in den Zielsprachen des Angebots leicht auszusprechen und einzugeben sein. Durch Verzicht auf Groß- und Kleinschreibung kann die Komplexität der URIs verringert werden.

Anstelle des URIs http://www.example.org/ findet man häufig die verkürzte Form www.example.org, bei der Protokoll und abschließender Schrägstrich der besseren Lesbarkeit wegen weggelassen werden. Die Angabe der Unterdomäne www bei in mehreren Medien eingesetzten URIs ist ratsam, da www.example.org eher als URI erkannt wird als example.org. Ressourcen mit langem kanonischem URI können kurze URIs zugewiesen werden, die zum kanonischen URI weiterleiten.

Falls der Domänenname www.example.org die kanonische Form darstellt, sollte eine dauerhafte Weiterleitung von http://example.org/ auf http://www.example.org/ eingerichtet werden. Andernfalls kann es vorkommen, daß Benutzer den Domänennamen ohne www. eingeben und die Anfrage nicht aufgelöst werden kann, da die Unterdomäne www nicht existiert. Wird die Form ohne www. als kanonischer Domänenname benutzt, ist eine Weiterleitung auf die Form mit www. ebenfalls ratsam.

Schlußwort

Die wichtigste Regel beim Entwurf von URIs ist, sich die Website einzig und alleine aus Sicht der Benutzer zu vergegenwärtigen und auf Basis dieser Sicht die Struktur des Angebots unter Berücksichtigung der zuvor genannten Punkte zu entwerfen. Werden URIs zur Steigerung der Benutzbarkeit einer bestehenden Website neu entworfen, sollten dauerhafte Weiterleitungen von den bestehenden URIs hin zu den neuen, kanonischen URIs eingerichtet werden, damit bereits in Hyperlinks, Lesezeichen und Veröffentlichungen genannte URIs weiterhin aufgelöst werden können.

Bei der Auswahl der auf dem Server eingesetzten Technologien und des Webhostingangebots empfiehlt es sich, auf die gebotenen Konfigurationsmöglichkeiten zu achten. Die Websites vieler Internetdienstanbieter, die Webhosting anbieten, führen zwar plakativ die auf dem Server installierten Technologien auf, verschweigen aber, welche Einstellungen durch den Kunden am Webserver vorgenommen werden können.

Schlechte URIs bekannter Unternehmen