Clean URL
Ein Clean URL oder Pretty URL (deutsch sauberer URL bzw. hübscher URL) ist ein Uniform Resource Locator (URL), der lesbare Wörter anstelle von technischen Kürzeln oder Datenbank-IDs enthält. So sind im Pfad weder searchpart-[1] oder query-Komponenten[2] noch Dateinamenserweiterungen wie z. B. .html, .php oder andere Informationen zur verwendeten Servertechnik wie cgi-bin oder cgi enthalten. Stattdessen werden lesbare und beschreibende Titel oder lexikografische Lemmata, Kalenderdaten (meist der Erscheinung) und auch die Sprache des Inhalts (meist abgekürzt nach ISO 639) im URL verwendet.
In der Web-Entwicklung spricht man von "slug" und meint dabei den letzten Teil des URL-Pfads.
Es können auch Mischungen aus beiden Methoden auftreten, indem die ID zwar behalten wird, aber lesbare Worte hinzugefügt werden. In diesem Fall ist die ID das entscheidende Merkmal des URL und die Worte können verändert oder weggelassen werden.
In der Praxis ist es in der Regel gewollt, dass sich URLs aus dem Webbrowser als Lesezeichen ablegen und zu einem beliebigen späteren Zeitpunkt wieder aufrufen lassen können. Sie sollen auch an Dritte weitergegeben werden und von diesen aufgerufen werden können und dieselbe Aktion auslösen bzw. denselben Zustand erzeugen (etwa eine Suche durchführen).[3]
Beispiele
Ein Beispiel für sowohl saubere als auch sprechende URLs ist Wikipedia, deren URLs nach folgendem Schema aufgebaut sind:
<Protokoll><Sprachcode>.wiki.li/<Artikelbezeichnung>
So sieht der URL für den Begriff Sonnenblume beispielsweise wie folgt aus
https://de.wiki.li/Sonnenblume
anstatt eines URL, der Rückschlüsse zur Technik gestattet
https://de.wikipedia.org/w/index.php?title=Sonnenblume
oder eines URL, die keinen Hinweis zum Inhalt gibt
https://de.wikipedia.org/?curid=112763
(alle angegebenen URL haben das gleiche Ergebnis)
Technik
Clean URLs lassen sich auf Webserver- und auf Webanwendungsebene umsetzen. Auf Webanwendungsebene muss jedoch auch der Webserver entsprechend konfiguriert sein.
Webserverebene
Die meisten Webserver wie Apache HTTP Server oder nginx können „saubere“ URLs mithilfe von .htaccess oder auch mit Rewrite-Engines realisieren.
Diese Module erlauben es, Anfragen anhand vorher definierter Regeln mithilfe von regulären Ausdrücken intern umzuschreiben, beziehungsweise umzuinterpretieren. So könnte beispielsweise die Anfrage von foo/bar
dasselbe Ergebnis erzielen wie die Anfrage von /index.php?q=/foo/bar
. Das CGI-Protokoll bietet eine weitere Technik, dabei sieht ein Skript aufgerufen als /index.php/foo/bar
/foo/bar
als PATH_INFO.[4]
Webanwendungsebene
Manche Web-Content-Management-Systeme beinhalten bereits passende Rewrite-Regeln, wodurch deren Aktivierung sehr einfach ist.
Vorteile
- Benutzer können die Relevanz von sprechenden URLs schneller bewerten (ein aussagekräftiger URL wird in der Regel eher angeklickt als ein kryptischer).
- Benutzer können sich die URLs leichter merken (und ähnliche Dateiendungen wie html oder htm müssen nicht mehr geraten werden).
- Externe Links und Lesezeichen auf eine Seite sind wesentlich länger gültig, da sie von internen technischen Änderungen unabhängig sind.[5]
- Bei der Suchmaschinen-Optimierung (dort auch sefURL für search engine friendly) werden im Suchmaschinenranking von Keywords neben dem Seiteninhalt auch Domain- und Dateinamen einzelner Seiten bewertet.[6]
Weblinks
- Tim Berners-Lee: Cool URIs don’t change. World Wide Web Consortium, 1998, abgerufen am 10. April 2013 (englisch).
- Manual:Short URL – MediaWiki (englisch)
Einzelnachweise
- RFC1738: Uniform Resource Locators (URL). 3.3. HTTP (englisch)
- RFC3986: Uniform Resource Identifier (URI): Generic Syntax. 3. Syntax Components (englisch)
- Jakob Nielsen: URL as UI. Nielsen Norman Group, 21. März 1999, abgerufen am 6. April 2013 (englisch).
- RFC 3875 – The Common Gateway Interface (CGI) Version 1.1. (englisch)
- Tim Berners-Lee: Cool URIs don’t change. World Wide Web Consortium, 1998, abgerufen am 10. April 2013 (englisch).
- Sefurl – Search Engine Friendly Uniform Resource Locator. Warum Sefurl? In: sefurl.de. Abgerufen am 12. Juni 2011: „Stichwörter werden aber ebenso im Domainnamen und im Dateinamen der einzelnen Seiten bewertet.“