Was ist eine Rewrite-Engine?
Bei einer Rewrite-Engine (rewrite = umschreiben, engine = Maschine) handelt es sich um eine Komponente der Webserver-Software, die es ermöglicht, Uniform Resource Locators (URLs) umzuschreiben oder weiterzuleiten. Die bekannteste Rewrite-Engine ist mod_rewrite des Apache HTTP Servers. Aber auch alternative Webserver wie nginx oder lighttpd stellen entsprechende Funktionen bereit.
Die Software-Komponente kommt z. B. dann zum Einsatz, wenn unhandliche dynamische URLs, wie sie mitunter von Content-Management-Systemen erzeugt werden, in nutzerfreundliche URLs umgeschrieben werden sollen. Die Gründe dafür liegen auf der Hand: Technisch bedingte URLs wie
"http://beispiel.com/a/index.php?title=seitentitel"
lassen sich von menschlichen Nutzern nur schwer erfassen; eine Rewrite-Engine erlaubt es, dieselbe Ressource parallel über eine deutlich eingängigere URL verfügbar zu machen:
"http://beispiel.com/artikel/seitentitel"
Ein Internetnutzer kann somit auch diese URL verwenden, um die entsprechende Webseite aufzurufen. Kommt eine solche Anfrage beim Webserver an, schreibt die Rewrite-Engine die URL automatisch in das intern vom Server verwendete Schema "http://beispiel.com/a/index.php?title=seitentitel" um.
Somit erzeugt die Rewrite-Engine eine Art Abstraktionsschicht zwischen den URLs, die das Webprojekt intern verwendet, und den URLs, die im Netz öffentlich dargestellt werden. Dies ermöglicht es, unabhängig von internen technischen Anforderungen nach außen hin ein nutzerfreundliches einheitliches Adressschema zur Verfügung stellen.
Intern kann so weiterhin die dynamische, parametrisierte Adresse genutzt werden, während Nutzer aus dem Internet über eine scheinbar statische Adresse auf das Webprojekt zugreifen. Dies hat den Vorteil, dass die nach außen präsentierten URLs auch dann gültig bleiben, wenn intern Änderungen an der Dateihierarchie vorgenommen werden.
Darüber hinaus können Webseitenbetreiber mit der Rewrite-Engine Adressumleitungen realisieren, die sich an bestimmte Bedingungen knüpfen lassen. So ist es beispielsweise möglich, Umleitungen basierend auf User-Agent-Kennung oder IP-Adresse des anfragenden Clients einzurichten, um ein Geotargeting umzusetzen oder für verschiedene Devices gezielt optimierte Websites auszuspielen. In der Regel kommt dabei ein 301-Redirect zum Einsatz, der sicherstellt, dass trotz des Parallelbetriebs zusätzlicher mobiler Webseiten oder verschiedener Sprachversionen immer nur eine Website-Version im Index der Suchmaschine gespeichert wird.
Abstand nehmen sollten Webseitenbetreiber hingegen von Cloaking-Praktiken, bei denen speziell optimierte Seiten ausschließlich an Suchmaschinen-Crawler ausgespielt werden, um das Ranking zu verbessern.
Anwendungsbeispiele
Für die Manipulation von URLs stellt die Rewrite-Engine diverse Befehle zur Verfügung, die sich als Regeln an verschiedenen Stellen der Webserver-Software notieren lassen. So kann mod_rewrite, die Rewrite-Engine des Apache-Webservers, in einem Directory-Container innerhalb der httpd.conf, in einem VirtualHost-Abschnitt oder innerhalb der .htaccess-Datei verwendet werden. Unter nginx wird URL-Rewriting in der Konfigurationsdatei /etc/nginx/nginx.conf notiert. Unter lighttpd steht dazu in der vHost-Konfiguration die Datei /etc/lighttpd.conf zur Verfügung. Um die dynamische URL "http://example.com/a/index.php?title=seitentitel" via Rewrite-Engine in die statische URL "http://example.com/artikel/seitentitel" umzuschreiben, kommen bei den Webservern Apache, nginx und lighttpd unterschiedliche Befehle zum Einsatz.
Rewrite-Engine unter Apache
Um mod_rewrite unter Apache zu nutzen, muss die Rewrite-Engine mit der Direktive RewriteEngine on aktiviert werden. Darauf folgt die RewriteRule, in der die Anweisungen für das URL-Rewriting mithilfe sogenannter regulärer Ausdrücke („regular expressions“, Regex) definiert werden:
RewriteEngine on
RewriteRule ^/artikel/(.*)$ /a/index.php?title=$1
Soll durch die RewriteRule eine Umleitung definiert werden, beinhaltet diese grundsätzlich zwei Parameter: das Suchmuster und das Zielmuster.
- Suchmuster: Dieser Parameter beschreibt die URLs, die umgeleitet werden sollen. Dabei wird eine bestimmte Bedingung in Form einer Zeichenfolge definiert. Ist diese Bedingung erfüllt, kommt es zur Umleitung auf eine URL nach dem Zielmuster. Im aktuellen Beispiel wäre das Suchmuster folgender Abschnitt der RewriteRule: ^/artikel/(.*
- Zielmuster: Dieser Parameter beschreibt die URL, auf die umgeleitet werden soll. Wird die Umleitung auf Server-Ebene konfiguriert, erfolgt eine Ersetzung der kompletten URL. Auf Verzeichnisebene in der .htaccess-Datei oder innerhalb der httpd.conf wird lediglich der Pfad ab dem aktuellen Verzeichnis ersetzt. Im Beispiel umfasst das Zielmuster diesen Abschnitt der RewriteRule: /a/index.php?title=$1.
Eine Erklärung der im Beispiel verwendeten regulären Ausdrücke zeigt die nachstehende Tabelle:
Reguläre Ausdrücke | Erklärung |
---|---|
^ | Bezeichnet den Anfang eines Strings. |
$ | Markiert das Ende eines Strings. |
(.*) | Ein Platzhalter für eine beliebige Zeichenfolge innerhalb einer URL. Die Klammern speichern die Zeichenfolge in einer Variablen. |
$1 | Eine Variable, die es ermöglicht, auf zwischengespeicherte Werte zuzugreifen, die durch die Klammern gespeichert wurden. |
Die RewriteRule ^/artikel/(.*)$ /a/index.php?title=$1 definiert somit die Regel, dass bei allen URLs, die mit dem String /artikel/(.*) beginnen, dieser Abschnitt in das dynamische URL-Schema /a/index.php?title=$1 umgeschrieben wird, wobei $1 für die Zeichenfolge steht, die dem Platzhalter (.*) entspricht. Gibt ein Internetnutzer die statische URL "http://beispiel.com/artikel/Seitentitel" in den Webbrowser ein, schreibt der Webserver diese basierend auf mod_rewrite intern und für den Nutzer unsichtbar in die dynamische URL "http://beispiel.com/a/index.php?title=Seitentitel" um. Der Platzhalter (.*) und die Variable $1 entsprechen in diesem Fall der Zeichenfolge „Seitentitel“. Soll das URL-Rewriting mit bestimmten Optionen verknüpft werden, die das Verhalten von mod_rewrite steuern, werden diese in eckigen Klammern hinter der RewriteRule notiert und – bei mehreren Optionen – durch Kommata getrennt. Auf diese Weise lassen sich auch externe Weiterleitungen via HTTP-Statuscode realisieren. Nachstehende Tabelle zeigt eine Auswahl an Optionen für die RewriteRule. Eine vollständige Liste findet sich auf der offiziellen Website der Apache Software Foundation.
Option | Flag | Funktion |
---|---|---|
Redirect | R | Das Flag [R] weist den Webserver an, eine externe Weiterleitung via HTTP-Statuscode 302 durchzuführen. Soll ein anderer Statuscode gesendet werden, wird dieser mit einem Gleichheitszeichen an das Flag angefügt. (z. B. [R=301)]. |
Forbidden | F | Weist den Webserver an, dem Webbrowser den HTTP-Statuscode 403 (Forbidden) zu senden. |
Gone | G | Weist den Webserver an, dem Webbrowser den HTTP-Statuscode 410 (Gone) zu senden und markiert die angeforderte Website als nicht mehr |
Last | L | Weist den Webserver an, nach der aktuellen RewriteRule keine weitere auszuführen. |
Nocase | NC | Bei der Überprüfung, ob eine URL die Bedingung für das Rewriting erfüllt, wird nicht auf Groß- und Kleinschreibung geachtet. |
Chain | C | Die nächste RewriteRule wird nur beachtet, wenn die aktuelle Bedingung zutrifft. |
Basierend auf einer solchen Option ließe sich eine externe Weiterleitung via HTTP-Statuscode folgendermaßen realisieren:
RewriteEngine On
RewriteRule ^alteseite.html$ /neueseite.html [R=301]
Neben RewriteRules lassen sich mit mod_rewrite zudem sogenannte RewriteConds definieren, mit denen Webseitenbetreiber Zusatzbedingungen festlegen, die erfüllt sein müssen, damit es zum URL-Rewriting kommt.
Die Syntax einer RewriteCond entspricht folgendem Aufbau und wird vor der RewriteRule notiert:
RewriteCond TESTSTRING CONDITION
Der Teststring enthält in der Regel sogenannte Servervariablen, die durch ein Prozentzeichen und geschweifte Klammern definiert sind, z. B. %{HTTP_HOST}. Nachstehende Tabelle zeigt eine Auswahl an Servervariablen.
Servervariable | Erklärung |
---|---|
HTTP_USER_AGENT | Bezieht sich auf den Client, der für den Serverzugriff genutzt wird. Die Variable wird in der Regel genutzt, um unterschiedlichen Webbrowsern jeweils eine optimierte 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 beinhalten. |
SERVER_PORT | Bezieht sich auf den angesprochenen Port (z. B. 80 für HTTP oder 443 für HTTPS). Die Variable ermöglicht es Webseitenbetreiber, Besucher auf eine sichere Verbindung umzuleiten. |
REMOTE_ADDR | Bezieht sich auf die IP-Adresse eines auf den Webserver zugreifenden Nutzers. Diese Variable wird mitunter genutzt, um Spamzugriffe zu blockieren. |
Folgendes Beispiel zeigt eine RewriteCond, die eine nachfolgende RewriteRule an die IP-Adresse eines zugreifenden Nutzers bindet:
RewriteCond %{REMOTE_ADDR} 173.45.68.79
URL-Rewriting unter nginx
Auch der Webserver nginx unterstützt URL-Rewriting nativ. Realisiert wird dies ebenfalls mithilfe regulärer Ausdrücke. Um URLs umzuschreiben, wird der Rewriting-Befehl lediglich entsprechend der nginx-Syntax in einem { [...] }-Block in die Webserver-Konfigurationsdatei /etc/nginx/nginx.conf eingefügt:
location /artikel {
rewrite ^/artikel/(.*)$ /index.php?title=$1 last;
}
Mit location /artikel geben Webseitenbetreiber an, dass sich das URL-Rewriting auf das Unterverzeichnis artikel bezieht. Die regulären Ausdrücke fürs Rewriting entsprechen denen, die auch beim Apache-Webserver zum Einsatz kommen, und werden mit dem Befehl rewrite eingeleitet. Das Flag last gibt an, dass das Rewriting intern und somit ohne Weiterleitung erfolgen soll. Alternativ stehen Flags für eine temporäre oder dauerhafte Weiterleitung zur Verfügung:
Flag | Erklärung |
---|---|
ast | URLs werden intern umgeschrieben. Es erfolgt keine Weiterleitung. |
redirect | Der Nutzer wird per 302-Redirect temporär auf die neue URL umgeleitet. |
permanent | Der Nutzer wird per 301-Redirect dauerhaft auf die neue URL umgeleitet. |
Wird kein Flag gesetzt, gibt nginx automatisch den HTTP-Fehlercode 500 aus.
Rewrite unter lighttpd
Unter lighttpd wird URL-Rewriting auf Basis der Funktion url.rewrite-TYP realisiert. Wobei der Platzhalter TYP für verschiedene Rewriting-Konfigurationsmöglichkeiten steht:
Rewriting-Konfigurationsmöglichkeit | Erklärung |
---|---|
url.rewrite-once | Einmaliges URL-Rewriting. Wurde das Suchmuster gefunden und die URL entsprechend dem Zielmuster umgeschrieben, erfolgen keine weiteren Umschreibungen. |
url.rewrite-repeat | Im Gegensatz zu url.rewrite-once können bei url.rewrite-repeat auf die erste Umschreibung weitere Umschreibungen folgen. |
Da beim URL-Rewriting unter lighttpd dieselben regulären Ausdrücke zum Einsatz kommen wie unter Apache, entspricht die Syntax im Wesentlichen dem bekannten Muster:
url.rewrite-once = (
"^/artikel/(.*)$" => "/index.php?title=$1"
)
Soll statt einer internen Umschreibung eine externe Weiterleitung 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 Information Services (IIS) besitzt nativ keine Rewrite-Engine. Sie lässt sich dem Webserver jedoch mit dem Modul IIS URL Rewrite 2.0 nachträglich hinzufügen. So können auch Microsoft-Nutzer ihren Webseitenbesuchern sprechende URLs zur Verfügung stellen, ohne in die interne Dateiverwaltung eingreifen zu müssen. Die URL-Rewriting-Erweiterung integriert sich nach dem Download direkt ins IIS-Manager-Interface, wo RewritingRules über eine grafische Benutzeroberfläche eingegeben werden. Auch IIS URL Rewrite 2.0 verwendet reguläre Ausdrücke, um URL-Such- und Zielmuster zu definieren.
URL-Rewriting und Suchmaschinenoptimierung
Da sich durch Rewriting parametrisierte URLs in sprechende und somit nutzerfreundliche URLs umschreiben lassen, werden die Funktionen von mod_rewrite und entsprechende Realisationen in anderen Webserver-Systemen auch im Zusammenhang mit Suchmaschinenoptimierung diskutiert. Dabei steht zur Diskussion, ob nutzerfreundliche URLs als Rankingfaktor gewertet werden können. Eindeutige Belege für eine direkte Relation gibt es nicht. Dennoch profitieren Webseitenbetreiber voraussichtlich von indirekten Effekten. Im Gegensatz zu kryptischen Parametern erlauben es umgeschriebene URLs Internetnutzern, nachzuvollziehen, wohin ein Link führt. Rewriting kann somit zur Vertrauensbildung genutzt werden und unter Umständen die Klickzahlen erhöhen. Zudem werden Suchbegriffe in URLs auf den Suchergebnisseiten gefettet dargestellt, was einen zusätzlichen Anreiz für einen Klick bieten kann.
- Kostengünstig: Google-Ranking verbessern ohne teure Agentur
- Effizient: Rezensionen beantworten, Posts für Social Media erstellen
- Einfach: Keine SEO- oder Marketing-Kenntnisse nötig