Benutzerfreundliche URIs

Gestaltungsleitlinien für benutzerfreundliche HTTP-URIs zur Gewährleistung von Persistenz und Kanonizität durch bewußte Konfiguration des Webservers.

Inhaltsverzeichnis

Einleitung

Bezüglich der visuellen Gestaltung von Webressourcen haben sich bereits spezialisierte Berufsbilder etabliert. Vielfach bleibt jedoch unberücksichtigt, daß die URIs der Ressourcen einer Website gleichfalls eine Benutzerschnittstelle darstellen, deren Gestaltung bewußt und mit Bedacht erfolgen muß.

Die Syntax von URIs ist in RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax spezifiziert. Während URIs mit verschiedensten Schemata Einsatz finden, beschränkt sich dieser Artikel auf HTTP/HTTPS-URIs, wie sie im Web Verwendung finden und von der Mehrheit der Benutzer wahrgenommen werden.

Leitlinien und Hinweise zur Wahl sinnvoller URIs

Eigenschaften von URIs

Zum Verständnis der nachfolgenden Gestaltungsleitlinien für URIs ist eine Differenzierung zwischen zwei Eigenschaften von URIs erforderlich:

Beide Eigenschaften stehen nicht in direktem Zusammenhang zueinander. Dennoch begünstigt die bedachtsame Wahl eines kanonischen URIs dessen langfristige Persistenz. Der administrative Konfigurationsaufwand sinkt, wenn eine Fragmentierung durch redundante URI-Aliase vermieden wird. Zudem optimiert eine strukturierte Gestaltung der URIs einer Website die menschliche Benutzbarkeit.

Der Aufwand zur Gewährleistung beider Eigenschaften ist marginal im Vergleich zu den Folgekosten ungeeigneter URI-Strukturen. Zudem muß berücksichtigt werden, daß einmal publizierte URIs eine hohe Nutzungsfrequenz aufweisen; minimale Zeiteinsparungen pro Aufruf summieren sich somit zu einer signifikanten Steigerung der Gesamtbenutzbarkeit.

Leitlinien für den Entwurf von URIs

Die nachfolgenden Beispiele verwenden URIs der Form https://example.org/ anstelle von https://example.org/foo. Welche dieser beiden Varianten bevorzugt wird, ist letztlich eine Ermessensfrage. Sofern das Dokument foo serverseitig nicht als Datei existiert, ist eine permanente Weiterleitung auf https://example.org/foo/ üblich. Der abschließende Schrägstrich signalisiert hierbei, daß der URI auf das Standarddokument eines Verzeichnisses verweist.

Auf konkrete Implementierungshinweise für spezifische Serverumgebungen wurde verzichtet, sofern diese nicht zwingend zur Erläuterung erforderlich sind.

Aus der Interaktion von Mensch und Computer mit URIs lassen sich folgende Entwurfsziele für URIs ableiten:

Auf Basis dieser Zielsetzungen wurden die nachfolgenden Leitlinien entwickelt, die sowohl für den Entwurf als auch für die Analyse von URIs herangezogen werden können. Die einzelnen Leitlinien werden durch praxisnahe Beispiele und die Evaluierung verschiedener Lösungsalternativen veranschaulicht.

URIs sollten Bedeutung tragen und müssen nicht Datei- und Verzeichnispfaden am Server entsprechen.

URIs müssen und sollen vielfach nicht mit den physischen Pfaden – sprich Verzeichnis- und Dateinamen – der Ressourcen auf dem Server übereinstimmen. Leistungsfähige Webserver erlauben eine freie Konfiguration von URIs, die eine beliebige Zuordnung zu den serverseitigen Ressourcen einschließt.

Die hierarchische Strukturierung und die Benennung von HTML-Dateien dürfen nicht primär die Administration durch den Webmaster erleichtern; das fundamentale Ziel muß die intuitive Orientierung und die konsistente Nutzung durch den Besucher der Website sein. Die kumulierte Nutzungszeit einer Website übersteigt deren Wartungsaufwand um ein Vielfaches.

Obwohl URIs keine Dateisystempfade abbilden, fungiert der Schrägstrich (»/«) als inhärentes Hierarchietrennzeichen. Analog zu Pfadangaben erlaubt diese Struktur die Referenzierung über relative URIs. Ein Hyperlink mit der Zieladresse ../../ auf der Seite https://www.example.org/2006/articles/web/ wird beispielsweise zu dem URI https://www.example.org/2006/ aufgelöst.

Subdomains sollten logisch strukturieren und müssen nicht der Servertopologie entsprechen.

Die Auswahl der Namen von Domains und Subdomains sollte nicht die physische Servertopologie abbilden, sondern sich an der Bedeutung der Server orientieren. Bezeichnungen wie www.example.org und www2.example.org zur Lastverteilung sind daher zu vermeiden. Ein Load-Balancing kann für den Benutzer transparent auf der Serverseite realisiert werden. Bei der Einführung von Subdomains ist zudem zu beachten, daß die Möglichkeit zur relativen Referenzierung zwischen den unterschiedlichen Subdomains verlorengeht.

In HTTP-URIs wird der eigentlichen Domain historisch bedingt häufig die Subdomain www vorangestellt. Dies ist technisch zwar obsolet, erhöht jedoch die Erkennbarkeit des URIs in Kontexten ohne Protokollangabe (z. B. in Printmedien). Insbesondere im kommerziellen Umfeld ist dher die Beibehaltung der Subdomain www ratsam.

Die Entscheidung für oder gegen eine Subdomain beeinflußt maßgeblich den Gültigkeitsbereich von HTTP-Cookies. Während Cookies auf der Stammdomain (example.org) unweigerlich an sämtliche Subdomains vererbt werden, isoliert die www-Variante diese Daten. Dies unterbindet unbefugte Cross-Subdomain-Zugriffe und ermöglicht die Einrichtung cookiefreier Subdomains zur Reduzierung des HTTP-Overheads bei statischen Ressourcen.

Eine der beiden Optionen – entweder mit Subdomain (https://www.example.org/) oder ohne Subdomain (https://example.org/) – sollte als kanonische Form definiert werden, gekoppelt mit einer permanenten Weiterleitung aller alternativen Varianten.

Serverseitige technische Details sollten nicht in URIs abgebildet werden.

Im Laufe der Zeit können die auf dem Webserver eingesetzten Technologien gegen andere ausgetauscht werden. Bestehende URIs, die an spezifische Technologien gebunden sind, können damit ihre Gültigkeit verlieren, was aufwendige Umleitungen erforderlich macht. Zudem können URIs dadurch eine irreführende Bedeutung erlangen – etwa, wenn unter https://www.example.org/foo.html eine PDF-Datei ausgeliefert wird, weil die Ressource nicht mehr im HTML-Format vorliegt.

Dateinamenserweiterungen wie .cgi, .php und .aspx sollten ebenfalls nicht in URIs enthalten sein. Dies gilt gleichermaßen für serverseitige Skripte und Verzeichnisse, da diese ein rein internes Implementierungsdetail darstellen. Für den Benutzer besitzen sie keinerlei Relevanz; potenziellen Angreifern erleichtern sie hingegen die gezielte Suche nach Sicherheitslücken. Anstelle von https://www.example.org/cgi-bin/search.pl?q=Hello ist ein URI wie https://www.example.org/search/?q=Hello vorzuziehen.

Selbst Anfrageparameter lassen sich in vielen Fällen verbergen, indem etwa anstelle von https://www.example.org/books/?isbn=9783161484100 der URI https://www.example.org/books/9783161484100/ verwendet wird. Dies macht den URI kompakter und kapselt das serverseitige Skript, welches die zur ISBN gehörigen Informationen ausgibt, vollkommen transparent für den Benutzer.

Der Dateiname von Verzeichnisstandarddokumenten sollte nicht in URIs aufscheinen.

Standarddokumente werden automatisch aufgerufen, wenn eine URI auf ein Verzeichnis verweist. Eine Anfrage an https://example.org/foo/ fordert beispielsweise das Standarddokument des Verzeichnisses foo an. Bei vielen Webservern ist dieses Dokument als Datei hinterlegt. Der Name dieser Datei hängt oft von der eingesetzten Servertechnologie ab. Ein Technologiewechsel macht daher ein Umbenennen der Dateien oder Anpassen der Serverkonfiguration erforderlich.

Da der technische Dateiname für Nutzende keine Bedeutung hat, sollte immer die verzeichnisbasierte URI als kanonische Form dienen (z. B. https://example.org/articles/ statt https://example.org/articles/default.aspx). Suchmaschinen lassen sich über passende HTTP-Statuscodes so steuern, daß sie URIs mit expliziten Dateinamen nicht indizieren. Sollten solche URIs dennoch in Umlauf geraten, sichern serverseitige Weiterleitungen die Erreichbarkeit bestehender Hyperlinks.

URIs sollten nur für den Benutzer relevante Informationen enthalten, keine bedeutungslosen Identifikationsnummern.

Für den Benutzer bedeutungslose Angaben wie interne Identifikationsnummern – beispielsweise GUIDs oder Datensatz-IDs – sollten in URIs vermieden werden. Solche Nummern finden sich häufig bei Websites, deren Inhalte in Datenbanktabellen abgelegt sind, was bei vielen Inhaltsverwaltungssystemen der Fall ist. Die Folge sind meist unhandliche URIs wie https://www.example.org/index.php?article_id=982361. Geeigneter wäre der URI https://www.example.org/articles/982361/. Im Idealfall wird auch diese ID weggelassen, sofern es sich nicht um eine dem Benutzer bekannte und bedeutungsvolle Artikelnummer handelt.

Ausnahmen bilden Identifikationsnummern wie die ISBN oder spezifische Angebotsnummern, da diese für den Benutzer eine Bedeutung besitzen und somit wichtige Informationen transportieren. So könnten Bücher unter URIs wie https://www.example.org/books/9783161484100/ verfügbar gemacht werden, wobei die Nummer am Ende der ISBN des Buches entspricht. Beim Angebot von Produkten auf einer Website bieten sich URIs wie https://www.example.org/shop/products/932457/ als kanonische URIs für die einzelnen Produktseiten an.

Die bei einigen Weblogs üblichen dauerhaften URIs wie https://www.example.org/PermaLink.aspx?guid=d57ace50-2762-4b19-b07d-39421829d410 sind ungeeignet, da sie Details der serverseitigen Implementierung offenlegen. Zudem nutzen sie GUIDs, die nicht auf die Lesbarkeit durch den Menschen hin optimiert sind. Bei Weblogs ist eine Anordnung der Artikel nach dem Erstellungsdatum besser geeignet – versehen mit einer laufenden Artikelnummer pro Tag (z. B. https://www.example.org/blog/2006/01/22/1/) oder einem sprechenden Titel (z. B. https://www.example.org/blog/implementing-web-services/).

Ausnahmen stellen beispielsweise Webforen dar, in denen den einzelnen Artikeln aufgrund mangelnder Struktur und hoher Beitragszahlen keine sinnvollen sprechenden URIs zugeordnet werden können. Dennoch ist auch hier darauf zu achten, daß die benutzten Identifikationsnummern minimal sind. Sie sollten nicht wie GUIDs eine feste Länge einnehmen, sondern etwa als laufende Artikelnummern mit zufälligem Anteil gestaltet sein. Auch die Sortierung nach dem Datum, wie zuvor am Beispiel von Weblogs beschrieben, kann sinnvoll sein: Im URI https://www.example.org/forum/2006/05/thread-130140/ wird die laufende Threadnummer direkt mit dem Erstellungsdatum verknüpft.

Der Inhaltstyp von Ressourcen sollte nach Möglichkeit nicht in deren URIs aufscheinen.

Wenngleich Webseiten zurzeit häufig im HTML-Format vorliegen, könnte in Zukunft eine andere Technologie zu deren Codierung eingesetzt werden. So könnte die einst geplante Umstellung von HTML auf XHTML bereits die Änderung der Dateinamenserweiterung von .html in .xhtml erfordern. Infolgedessen wäre es notwendig, eine dauerhafte Weiterleitung von https://www.example.org/joe/cv.html auf https://www.example.org/joe/cv.xhtml einzurichten.

Daher empfiehlt sich, den Inhaltstyp einer Ressource oder einer Gruppe von Ressourcen semantisch gleichbedeutenden Inhalts im URI nicht anzugeben. Ein URI wie https://www.example.org/joe/cv/ ist nicht an einen bestimmten Inhaltstyp gebunden und kann den Inhalt mittels Content Negotiation in der jeweils passenden Form codiert zurückgeben. Daneben können spezifische URIs für die verschiedenen zur Auswahl stehenden Inhaltstypen definiert werden, um deren direkten Abruf 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 eine oder mehrere Sprachen gesprochen werden, und eine Sprache kann zugleich in mehreren Ländern verwendet werden. So könnte ein Anbieter unterschiedliche Inhalte für Deutschland und Österreich bereitstellen, obwohl in beiden Ländern Deutsch gesprochen wird. Die Website eines Unternehmens in Polen wiederum könnte Inhalte sowohl auf Polnisch als auch auf Deutsch zur Verfügung stellen.

Top-Level-Domains wie .de, .at und .pl sind Staaten zugeordnet. Sie bezeichnen keine bestimmten Sprachen, auch wenn die meisten Websites unter der .de-Domain in deutscher Sprache verfaßt sind. Ist ein Anbieter sowohl in Deutschland als auch in Österreich aktiv, könnte er die Domains example.de und example.at nutzen. Beide Websites sind dann auf Deutsch gehalten, weisen aber länderspezifische Inhalte auf. Als Alternative zu mehreren Top-Level-Domains können für die einzelnen Länder auch Subdomains wie de.example.org und at.example.org einer länderunabhängigen Domain eingesetzt werden.

Werden Ressourcen in mehreren Sprachen unter einer einzigen Domain angeboten, bestehen verschiedene Möglichkeiten: Über Content Negotiation kann bei der Adressierung einer Ressource über einen URI wie https://www.example.org/angebote/ die Ressource direkt in einer passenden Sprache zurückgegeben werden. Zudem kann dem Benutzer die Möglichkeit zur Sprachauswahl geboten werden, wobei die gewählte Sprache clientseitig in einem Cookie oder in einem serverseitigen im Benutzerprofil gespeichert wird.

Alternativ oder zusätzlich kann eine bestimmte Sprachversion einer Ressource über einen eigenen URI adressiert werden. Üblich sind hierbei URIs wie https://www.example.org/de/artikel/, https://www.example.org/artikel.de, https://de.example.org/artikel/ und https://www.example.org/articles/?lang=de. Werden die Teile des URIs hinter dem Domainnamen lokalisiert, sind die Namen für Benutzer einer bestimmten Sprache zwar leichter verständlich; der Wechsel zwischen den Sprachversionen einer Ressource durch einfaches Austauschen des Sprachkürzels im URI wird dadurch 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 zu vereinfachen. Insbesondere Sitzungs-IDs (Session IDs) und nicht gesetzte Optionen sollten in URIs nicht aufgeführt werden. Werden für nicht angegebene Parameter Standardwerte definiert, können diese Parameter komplett entfallen, sofern der Standardwert zur Anwendung kommen soll.

Zusätzlich ist darauf zu achten, daß bei kanonischen URIs die Reihenfolge und die Codierung der Parameter eindeutig festgelegt sind. Diese Maßnahme erleichtert dem Benutzer die Übersicht und Verarbeitung mehrerer URIs einer Domain. Werden ungültige Parameter oder Parameterwerte übergeben, sollte durch Setzen des passenden HTTP-Statuscodes angezeigt werden, daß die Ressource unter dieser Adresse nicht existiert. Damit wird die Indizierung des fehlerhaften URIs durch Suchmaschinen wirksam unterbunden.

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

Die durch das Kürzen des URIs https://www.example.org/web/articles/xhtml/ entstehenden Adressen https://www.example.org/, https://www.example.org/web/ und https://www.example.org/web/articles/ sollten ebenfalls zu gültigen Dokumenten führen. Von diesen übergeordneten Seiten aus kann sinnvoll auf die jeweiligen Unterdokumente verwiesen werden. So könnte unter https://www.example.org/web/articles/ eine Übersicht der zum Thema „Web“ verfügbaren Artikel bereitgestellt werden. Auf diese Weise spiegeln die URIs die logische Struktur der Website konsistent wider.

Zugriffe über nicht-kanonische URIs sollten zum kanonischen URI weitergeleitet werden.

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 zu reagieren –, so sollte eine dauerhafte Weiterleitung auf den kanonischen URI erfolgen. Dadurch wird vermieden, daß sich die nicht-kanonischen Adressen der Ressource weiter verbreiten.

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 unerheblich sein, ob der Benutzer eine Seite über einen URI ansteuert, dessen Groß- und Kleinschreibung nicht mit der Schreibung des kanonischen URIs übereinstimmt. Ebenso sollte es keine Rolle spielen, ob der Benutzer abschließende Schrägstriche angibt oder wegläßt.

Fehleingaben in URIs sollten tolerant verarbeitet werden.

Durch die Analyse von Zugriffsprotokollen lassen sich häufige Fehleingaben von Verzeichnis- und Dokumentnamen in URIs ermitteln, um anschließend dauerhafte serverseitige Weiterleitungen einzurichten. Kann aufgrund einer fehlerhaften Zieladresse nicht eindeutig entschieden werden, welchen URI der Benutzer ansteuern wollte, bietet es sich an, auf der zurückgegebenen Fehlerseite die potenziell gemeinten URIs als Hyperlinks aufzuführen und dem Benutzer die Auswahl zu überlassen. Durch das Übermitteln eines passenden HTTP-Statuscodes wird verhindert, daß Suchmaschinen den falsch geschriebenen URI indizieren.

Besteht die Gefahr, daß Benutzer den Domainnamen falsch schreiben, empfiehlt es sich, alle über diese Fehlschreibungen eintreffenden Anfragen direkt auf die kanonische Domain weiterzuleiten. So könnte von https://www.exmple.org/articles/ eine Weiterleitung auf https://www.example.org/articles/ führen. Dies betrifft auch den Verzicht auf Subdomains: https://example.org/articles/ könnte auf das kanonische https://www.example.org/articles/ umgeleitet werden (oder umgekehrt). Ebenso ist die automatische Weiterleitung von https://www.example.org/foo auf das kanonische https://www.example.org/foo/ (mit abschließendem Schrägstrich) sinnvoll.

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

Bereits beim Entwurf von URIs sollte das zukünftige Wachstum der Website berücksichtigt werden. Insbesondere eine strikte Trennung zwischen aktuellen Ressourcen und einem Archiv, bei der ältere Inhalte in ein anderes Verzeichnis verschoben werden, ist problematisch. Ist etwa die jeweils aktuelle Ausgabe einer Zeitschrift unter dem URI https://www.example.org/issues/current/ abrufbar, so ändert sich die durch diesen URI bezeichnete Ressource bei Erscheinen jeder neuen Ausgabe. Bestehende Hyperlinks auf diese Zieladresse blieben zwar weiterhin gültig, würden jedoch nicht mehr auf jene spezifische Ressource verweisen, die der Autor ursprünglich verlinken wollte.

Eine sinnvolle Lösung stellt das Einrichten einer Weiterleitung von https://www.example.org/issues/current/ auf den kanonischen URI der jeweils aktuellen Ausgabe dar. So würde im März 2006 eine automatische Weiterleitung auf https://www.example.org/issues/2006/03/ erfolgen. Benutzer können so über den permanenten URI immer auf das aktuelle Heft zugreifen, ohne dessen genaue Nummer kennen zu müssen. Gleichzeitig bleibt die Möglichkeit bestehen, direkt auf eine bestimmte historische Ausgabe zu verweisen.

Besser als eine rein thematische Sortierung direkt hinter dem Domainnamen ist die Strukturierung der Inhalte anhand ihres Veröffentlichungsjahres – etwa https://www.example.org/2006/articles/web/xhtml/ anstelle von https://www.example.org/articles/web/xhtml/. Die Angabe des Jahres vor den Kategoriennamen hat den Vorteil, daß die Relevanz der Kategorie zeitlich eingeordnet werden kann. Zudem können alte Kategorien im Laufe der Jahre entfallen oder archiviert werden, ohne die bestehende URI-Struktur neuerer Jahrgänge zu beeinflussen.

Einmal genutzte Domains sollten nicht abgegeben werden.

Während sich mittels Weiterleitungen alle Szenarien eines Umzugs von Ressourcen innerhalb kontrollierter Domains lösen lassen, führt der Verlust der Kontrolle über einen Domainnamen zwangsläufig dazu, daß URIs dauerhaft ungültig werden. Ohne Domainkontrolle können keine serverseitigen Weiterleitungen mehr eingerichtet werden. Eine theoretische Lösung dieses Problems stellen Persistent Uniform Resource Locators (PURLs) dar. In der Praxis reicht es jedoch meist aus, organisatorisch sicherzustellen, daß einmal registrierte Domains nicht irrtümlich in fremde Hände gelangen.

Bei der Fusion mehrerer Unternehmen oder dem Aufkauf einer Firma sollten die ursprünglichen Domainnamen nach Möglichkeit nicht aufgegeben werden. Stattdessen können dauerhafte Weiterleitungen von den alten Domains zur neuen Hauptdomain eingerichtet werden. Soweit sinnvoll, sollten auch die URIs zu einzelnen Ressourcen der alten Domains weiterhin direkt auf die entsprechenden Inhalte verweisen – selbst dann, wenn diese mittlerweile mit neuen kanonischen URIs versehen und physisch auf einen neuen Server verschoben 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. Auch im direkten Gespräch oder am Telefon werden URIs in gesprochener Form übermittelt. Daher ist es ratsam, 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 den Verzicht auf eine Unterscheidung von Groß- und Kleinschreibung kann die Komplexität der URIs erheblich verringert werden.

Anstelle des vollständigen URIs https://www.example.org/ findet man in Printmedien häufig die verkürzte Form www.example.org, bei der das Protokoll und der abschließende Schrägstrich der besseren Lesbarkeit wegen weggelassen werden. Die Angabe der Subdomain www ist bei solchen medienübergreifend eingesetzten URIs ratsam, da www.example.org vom Betrachter schneller als Website erkannt wird als das bloße example.org. Ressourcen mit einem langen kanonischen URI können zudem kurze Alias-URIs zugewiesen werden, die dauerhaft zum Haupt-URI weiterleiten.

Falls der Domainname www.example.org die kanonische Form darstellt, sollte eine dauerhafte Weiterleitung von https://example.org/ auf https://www.example.org/ eingerichtet werden. Andernfalls kann es vorkommen, daß Benutzer den Domainnamen ohne das Kürzel www. eingeben und die Anfrage fehlschlägt, weil der Server nicht entsprechend konfiguriert ist. Wird hingegen die Form ohne www. als kanonischer Domainname bevorzugt, ist eine umgekehrte Weiterleitung der Form mit www. auf die Stammdomain ebenfalls dringend ratsam.

Schlußwort

Die fundamentale Prämisse beim URI-Entwurf besteht darin, die Website ausschließlich aus der Perspektive der Benutzer zu konzipieren und hierbei die vorgenannten Kriterien zu berücksichtigen. Werden URIs zur Optimierung der Benutzbarkeit einer bestehenden Website modifiziert, sind permanente serverseitige Weiterleitungen auf die neuen kanonischen URIs einzurichten. Dies gewährleistet, daß bestehende Hyperlinks, Lesezeichen und externe Referenzen valide bleiben.

Bei der Evaluierung der auf dem Server eingesetzten Technologien und des Webhostingangebots ist auf ausreichende Konfigurationsoptionen zu achten. Viele Provider listen zwar die installierten Softwarekomponenten detailliert auf, verschweigen jedoch den Umfang der kundenseitig modifizierbaren Einstellungen des Webservers.