Bei einer Rewrite-Engine (rewrite = um­schrei­ben, engine = Maschine) handelt es sich um eine Kom­po­nen­te der Webserver-Software, die es er­mög­licht, Uniform Resource Locators (URLs) um­zu­schrei­ben oder wei­ter­zu­lei­ten. Die be­kann­tes­te Rewrite-Engine ist mod_rewrite des Apache HTTP Servers. Aber auch al­ter­na­ti­ve Webserver wie nginx oder lighttpd stellen ent­spre­chen­de Funk­tio­nen bereit.

Die Software-Kom­po­nen­te kommt z. B. dann zum Einsatz, wenn un­hand­li­che dy­na­mi­sche URLs, wie sie mitunter von Content-Ma­nage­ment-Systemen erzeugt werden, in nut­zer­freund­li­che URLs um­ge­schrie­ben werden sollen. Die Gründe dafür liegen auf der Hand: Technisch bedingte URLs wie

"http://beispiel.com/a/index.php?title=sei­ten­ti­tel"

lassen sich von mensch­li­chen Nutzern nur schwer erfassen; eine Rewrite-Engine erlaubt es, dieselbe Ressource parallel über eine deutlich ein­gän­gi­ge­re URL verfügbar zu machen:

"http://beispiel.com/artikel/sei­ten­ti­tel"

Ein In­ter­net­nut­zer kann somit auch diese URL verwenden, um die ent­spre­chen­de Webseite auf­zu­ru­fen. Kommt eine solche Anfrage beim Webserver an, schreibt die Rewrite-Engine die URL au­to­ma­tisch in das intern vom Server ver­wen­de­te Schema "http://beispiel.com/a/index.php?title=sei­ten­ti­tel" um.

Somit erzeugt die Rewrite-Engine eine Art Abs­trak­ti­ons­schicht zwischen den URLs, die das Web­pro­jekt intern verwendet, und den URLs, die im Netz öf­fent­lich dar­ge­stellt werden. Dies er­mög­licht es, un­ab­hän­gig von internen tech­ni­schen An­for­de­run­gen nach außen hin ein nut­zer­freund­li­ches ein­heit­li­ches Adress­sche­ma zur Verfügung stellen.

Intern kann so weiterhin die dy­na­mi­sche, pa­ra­me­tri­sier­te Adresse genutzt werden, während Nutzer aus dem Internet über eine scheinbar statische Adresse auf das Web­pro­jekt zugreifen. Dies hat den Vorteil, dass die nach außen prä­sen­tier­ten URLs auch dann gültig bleiben, wenn intern Än­de­run­gen an der Da­tei­hier­ar­chie vor­ge­nom­men werden.

Darüber hinaus können Web­sei­ten­be­trei­ber mit der Rewrite-Engine Adres­s­um­lei­tun­gen rea­li­sie­ren, die sich an bestimmte Be­din­gun­gen knüpfen lassen. So ist es bei­spiels­wei­se möglich, Um­lei­tun­gen basierend auf User-Agent-Kennung oder IP-Adresse des an­fra­gen­den Clients ein­zu­rich­ten, um ein Geo­tar­ge­ting um­zu­set­zen oder für ver­schie­de­ne Devices gezielt op­ti­mier­te Websites aus­zu­spie­len. In der Regel kommt dabei ein 301-Redirect zum Einsatz, der si­cher­stellt, dass trotz des Par­al­lel­be­triebs zu­sätz­li­cher mobiler Webseiten oder ver­schie­de­ner Sprach­ver­sio­nen immer nur eine Website-Version im Index der Such­ma­schi­ne ge­spei­chert wird.

Abstand nehmen sollten Web­sei­ten­be­trei­ber hingegen von Cloaking-Praktiken, bei denen speziell op­ti­mier­te Seiten aus­schließ­lich an Such­ma­schi­nen-Crawler aus­ge­spielt werden, um das Ranking zu ver­bes­sern.

An­wen­dungs­bei­spie­le

Für die Ma­ni­pu­la­ti­on von URLs stellt die Rewrite-Engine diverse Befehle zur Verfügung, die sich als Regeln an ver­schie­de­nen Stellen der Webserver-Software notieren lassen. So kann mod_rewrite, die Rewrite-Engine des Apache-Web­ser­vers, in einem Directory-Container innerhalb der httpd.conf, in einem Vir­tu­al­Host-Abschnitt oder innerhalb der .htaccess-Datei verwendet werden. Unter nginx wird URL-Rewriting in der Kon­fi­gu­ra­ti­ons­da­tei /etc/nginx/nginx.conf notiert. Unter lighttpd steht dazu in der vHost-Kon­fi­gu­ra­ti­on die Datei /etc/lighttpd.conf zur Verfügung. Um die dy­na­mi­sche URL "http://example.com/a/index.php?title=sei­ten­ti­tel" via Rewrite-Engine in die statische URL "http://example.com/artikel/sei­ten­ti­tel" um­zu­schrei­ben, kommen bei den Web­ser­vern Apache, nginx und lighttpd un­ter­schied­li­che Befehle zum Einsatz.

Rewrite-Engine unter Apache

Um mod_rewrite unter Apache zu nutzen, muss die Rewrite-Engine mit der Direktive Re­wri­teEn­gi­ne on aktiviert werden. Darauf folgt die Re­wri­te­Rule, in der die An­wei­sun­gen für das URL-Rewriting mithilfe so­ge­nann­ter regulärer Ausdrücke („regular ex­pres­si­ons“, Regex) definiert werden: 

RewriteEngine on
RewriteRule ^/artikel/(.*)$ /a/index.php?title=$1

Soll durch die Re­wri­te­Rule eine Umleitung definiert werden, be­inhal­tet diese grund­sätz­lich zwei Parameter: das Such­mus­ter und das Ziel­mus­ter.

  • Such­mus­ter: Dieser Parameter be­schreibt die URLs, die um­ge­lei­tet werden sollen. Dabei wird eine bestimmte Bedingung in Form einer Zei­chen­fol­ge definiert. Ist diese Bedingung erfüllt, kommt es zur Umleitung auf eine URL nach dem Ziel­mus­ter. Im aktuellen Beispiel wäre das Such­mus­ter folgender Abschnitt der Re­wri­te­Rule: ^/artikel/(.*
  • Ziel­mus­ter: Dieser Parameter be­schreibt die URL, auf die um­ge­lei­tet werden soll. Wird die Umleitung auf Server-Ebene kon­fi­gu­riert, erfolgt eine Ersetzung der kom­plet­ten URL. Auf Ver­zeich­nis­ebe­ne in der .htaccess-Datei oder innerhalb der httpd.conf wird lediglich der Pfad ab dem aktuellen Ver­zeich­nis ersetzt. Im Beispiel umfasst das Ziel­mus­ter diesen Abschnitt der Re­wri­te­Rule: /a/index.php?title=$1.

Eine Erklärung der im Beispiel ver­wen­de­ten regulären Ausdrücke zeigt die nach­ste­hen­de Tabelle:

Reguläre Ausdrücke Erklärung
^ Be­zeich­net den Anfang eines Strings.
$ Markiert das Ende eines Strings.
(.*) Ein Platz­hal­ter für eine beliebige Zei­chen­fol­ge innerhalb einer URL. Die Klammern speichern die Zei­chen­fol­ge in einer Variablen.
$1 Eine Variable, die es er­mög­licht, auf zwi­schen­ge­spei­cher­te Werte zu­zu­grei­fen, die durch die Klammern ge­spei­chert wurden.

Die Re­wri­te­Rule ^/artikel/(.*)$ /a/index.php?title=$1 definiert somit die Regel, dass bei allen URLs, die mit dem String /artikel/(.*) beginnen, dieser Abschnitt in das dy­na­mi­sche URL-Schema /a/index.php?title=$1 um­ge­schrie­ben wird, wobei $1 für die Zei­chen­fol­ge steht, die dem Platz­hal­ter (.*) ent­spricht. Gibt ein In­ter­net­nut­zer die statische URL "http://beispiel.com/artikel/Sei­ten­ti­tel" in den Web­brow­ser ein, schreibt der Webserver diese basierend auf mod_rewrite intern und für den Nutzer un­sicht­bar in die dy­na­mi­sche URL "http://beispiel.com/a/index.php?title=Sei­ten­ti­tel" um. Der Platz­hal­ter (.*) und die Variable $1 ent­spre­chen in diesem Fall der Zei­chen­fol­ge „Sei­ten­ti­tel“. Soll das URL-Rewriting mit be­stimm­ten Optionen verknüpft werden, die das Verhalten von mod_rewrite steuern, werden diese in eckigen Klammern hinter der Re­wri­te­Rule notiert und – bei mehreren Optionen – durch Kommata getrennt. Auf diese Weise lassen sich auch externe Wei­ter­lei­tun­gen via HTTP-Sta­tus­code rea­li­sie­ren. Nach­ste­hen­de Tabelle zeigt eine Auswahl an Optionen für die Re­wri­te­Rule. Eine voll­stän­di­ge Liste findet sich auf der of­fi­zi­el­len Website der Apache Software Foun­da­ti­on.

Option Flag Funktion
Redirect R Das Flag [R] weist den Webserver an, eine externe Wei­ter­lei­tung via HTTP-Sta­tus­code 302 durch­zu­füh­ren. Soll ein anderer Sta­tus­code gesendet werden, wird dieser mit einem Gleich­heits­zei­chen an das Flag angefügt. (z. B. [R=301)].
Forbidden F Weist den Webserver an, dem Web­brow­ser den HTTP-Sta­tus­code 403 (Forbidden) zu senden.
Gone G Weist den Webserver an, dem Web­brow­ser den HTTP-Sta­tus­code 410 (Gone) zu senden und markiert die an­ge­for­der­te Website als nicht mehr
Last L Weist den Webserver an, nach der aktuellen Re­wri­te­Rule keine weitere aus­zu­füh­ren.
Nocase NC Bei der Über­prü­fung, ob eine URL die Bedingung für das Rewriting erfüllt, wird nicht auf Groß- und Klein­schrei­bung geachtet.
Chain C Die nächste Re­wri­te­Rule wird nur beachtet, wenn die aktuelle Bedingung zutrifft.

Basierend auf einer solchen Option ließe sich eine externe Wei­ter­lei­tung via HTTP-Sta­tus­code fol­gen­der­ma­ßen rea­li­sie­ren: 

RewriteEngine On
RewriteRule ^alteseite.html$ /neueseite.html [R=301]

Neben Re­wri­te­Rules lassen sich mit mod_rewrite zudem so­ge­nann­te Re­wri­te­Conds de­fi­nie­ren, mit denen Web­sei­ten­be­trei­ber Zu­satz­be­din­gun­gen festlegen, die erfüllt sein müssen, damit es zum URL-Rewriting kommt.

Die Syntax einer Re­wri­te­Cond ent­spricht folgendem Aufbau und wird vor der Re­wri­te­Rule notiert: 

RewriteCond TESTSTRING CONDITION

Der Test­string enthält in der Regel so­ge­nann­te Ser­ver­va­ria­blen, die durch ein Pro­zent­zei­chen und ge­schweif­te Klammern definiert sind, z. B. %{HTTP_HOST}. Nach­ste­hen­de Tabelle zeigt eine Auswahl an Ser­ver­va­ria­blen.

Ser­ver­va­ria­ble Erklärung
HTTP_USER_AGENT Bezieht sich auf den Client, der für den Ser­ver­zu­griff genutzt wird. Die Variable wird in der Regel genutzt, um un­ter­schied­li­chen Web­brow­sern jeweils eine op­ti­mier­te Website zur Verfügung zu stellen.
HTTP_HOST Bezieht sich auf den Hostnamen. Dieser kann Werte wie domain.com, subdomain.domain.com oder die IP-Adresse be­inhal­ten.
SERVER_PORT Bezieht sich auf den an­ge­spro­che­nen Port (z. B. 80 für HTTP oder 443 für HTTPS). Die Variable er­mög­licht es Web­sei­ten­be­trei­ber, Besucher auf eine sichere Ver­bin­dung um­zu­lei­ten.
REMOTE_ADDR Bezieht sich auf die IP-Adresse eines auf den Webserver zu­grei­fen­den Nutzers. Diese Variable wird mitunter genutzt, um Spam­zu­grif­fe zu blo­ckie­ren.

Folgendes Beispiel zeigt eine Re­wri­te­Cond, die eine nach­fol­gen­de Re­wri­te­Rule an die IP-Adresse eines zu­grei­fen­den Nutzers bindet: 

RewriteCond %{REMOTE_ADDR} 173.45.68.79

URL-Rewriting unter nginx

Auch der Webserver nginx un­ter­stützt URL-Rewriting nativ. Rea­li­siert wird dies ebenfalls mithilfe regulärer Ausdrücke. Um URLs um­zu­schrei­ben, wird der Rewriting-Befehl lediglich ent­spre­chend der nginx-Syntax in einem { [...] }-Block in die Webserver-Kon­fi­gu­ra­ti­ons­da­tei /etc/nginx/nginx.conf eingefügt:

location /artikel {
 rewrite ^/artikel/(.*)$ /index.php?title=$1 last;
}

Mit location /artikel geben Web­sei­ten­be­trei­ber an, dass sich das URL-Rewriting auf das Un­ter­ver­zeich­nis artikel bezieht. Die regulären Ausdrücke fürs Rewriting ent­spre­chen denen, die auch beim Apache-Webserver zum Einsatz kommen, und werden mit dem Befehl rewrite ein­ge­lei­tet. Das Flag last gibt an, dass das Rewriting intern und somit ohne Wei­ter­lei­tung erfolgen soll. Al­ter­na­tiv stehen Flags für eine temporäre oder dau­er­haf­te Wei­ter­lei­tung zur Verfügung:

Flag Erklärung
ast URLs werden intern um­ge­schrie­ben. Es erfolgt keine Wei­ter­lei­tung.
redirect Der Nutzer wird per 302-Redirect temporär auf die neue URL um­ge­lei­tet.
permanent Der Nutzer wird per 301-Redirect dauerhaft auf die neue URL um­ge­lei­tet.

Wird kein Flag gesetzt, gibt nginx au­to­ma­tisch den HTTP-Feh­ler­code 500 aus.

Rewrite unter lighttpd

Unter lighttpd wird URL-Rewriting auf Basis der Funktion url.rewrite-TYP rea­li­siert. Wobei der Platz­hal­ter TYP für ver­schie­de­ne Rewriting-Kon­fi­gu­ra­ti­ons­mög­lich­kei­ten steht:

Rewriting-Kon­fi­gu­ra­ti­ons­mög­lich­keit Erklärung
url.rewrite-once Ein­ma­li­ges URL-Rewriting. Wurde das Such­mus­ter gefunden und die URL ent­spre­chend dem Ziel­mus­ter um­ge­schrie­ben, erfolgen keine weiteren Um­schrei­bun­gen.
url.rewrite-repeat Im Gegensatz zu url.rewrite-once können bei url.rewrite-repeat auf die erste Um­schrei­bung weitere Um­schrei­bun­gen folgen.

Da beim URL-Rewriting unter lighttpd dieselben regulären Ausdrücke zum Einsatz kommen wie unter Apache, ent­spricht die Syntax im We­sent­li­chen dem bekannten Muster: 

url.rewrite-once = (
 "^/artikel/(.*)$" => "/index.php?title=$1"
)

Soll statt einer internen Um­schrei­bung eine externe Wei­ter­lei­tung erfolgen, wird unter lighttpd nicht das Rewriting-Modul verwendet, sondern ein Redirect-Modul, wobei URLs erst das Rewrite- und dann das Redirect-Modul passieren

Rewrite unter Microsoft IIS

Die Plattform Microsoft Internet In­for­ma­ti­on Services (IIS) besitzt nativ keine Rewrite-Engine. Sie lässt sich dem Webserver jedoch mit dem Modul IIS URL Rewrite 2.0 nach­träg­lich hin­zu­fü­gen. So können auch Microsoft-Nutzer ihren Web­sei­ten­be­su­chern spre­chen­de URLs zur Verfügung stellen, ohne in die interne Da­tei­ver­wal­tung ein­grei­fen zu müssen. Die URL-Rewriting-Er­wei­te­rung in­te­griert sich nach dem Download direkt ins IIS-Manager-Interface, wo Re­wri­tin­gRu­les über eine grafische Be­nut­zer­ober­flä­che ein­ge­ge­ben werden. Auch IIS URL Rewrite 2.0 verwendet reguläre Ausdrücke, um URL-Such- und Ziel­mus­ter zu de­fi­nie­ren.

URL-Rewriting und Such­ma­schi­nen­op­ti­mie­rung

Da sich durch Rewriting pa­ra­me­tri­sier­te URLs in spre­chen­de und somit nut­zer­freund­li­che URLs um­schrei­ben lassen, werden die Funk­tio­nen von mod_rewrite und ent­spre­chen­de Rea­li­sa­tio­nen in anderen Webserver-Systemen auch im Zu­sam­men­hang mit Such­ma­schi­nen­op­ti­mie­rung dis­ku­tiert. Dabei steht zur Dis­kus­si­on, ob nut­zer­freund­li­che URLs als Ran­king­fak­tor gewertet werden können. Ein­deu­ti­ge Belege für eine direkte Relation gibt es nicht. Dennoch pro­fi­tie­ren Web­sei­ten­be­trei­ber vor­aus­sicht­lich von in­di­rek­ten Effekten. Im Gegensatz zu kryp­ti­schen Pa­ra­me­tern erlauben es um­ge­schrie­be­ne URLs In­ter­net­nut­zern, nach­zu­voll­zie­hen, wohin ein Link führt. Rewriting kann somit zur Ver­trau­ens­bil­dung genutzt werden und unter Umständen die Klick­zah­len erhöhen. Zudem werden Such­be­grif­fe in URLs auf den Such­ergeb­nis­sei­ten gefettet dar­ge­stellt, was einen zu­sätz­li­chen Anreiz für einen Klick bieten kann.

ran­king­Coach
Er­folg­rei­ches Online-Marketing mit KI
  • Kos­ten­güns­tig: Google-Ranking ver­bes­sern ohne teure Agentur
  • Effizient: Re­zen­sio­nen be­ant­wor­ten, Posts für Social Media erstellen
  • Einfach: Keine SEO- oder Marketing-Kennt­nis­se nötig
Zum Hauptmenü