URL-Rewriting: Umschreibung von URLs mit mod_rewrite

Sprechende URLs

Übersicht / Seite - Weiterleitungen:

1. per Meta-Tag (allgemeine Infos zur Benutzung)
2. per JavaScript (clientseitige Redirects mit JavaScript)
3. auf mobile Seiten (eine einfache Umleitung auf mobile Seiten)
4. mit Bestätigung (Pseudo-Weiterleitung auf mobile Seite mit Bestätigung)
5. mit PHP (serverseitige Redirects mit PHP)
6. per htaccess (mit mod_alias und mod_rewrite)
7. mit mod_rewrite (weitere Beispiele von Weiterleitungen per htaccess)
8. URL-Rewriting (Umschreibung von URLs mit oder ohne QueryStrings)
9. Weiterleitung statt 404 (... bei fehlerhaften Aufrufen oder von alten URLs)

Umschreibung von URLs mit mod_rewrite

Ob es sich um einen Shop, um einen Blog, um ein Forum, um ein Online-Magazin oder um ein anderes Projekt handelt, ohne die Übergabe von QueryStrings, in denen die erforderlichen Parameter-Wertepaare enthalten sind, geht es bei dynamischen Webseiten selten ab. Leider sehen QueryStrings alles andere als ansprechend aus. Doch URLs lassen sich durch URL-Rewriting mit mod_rewrite in sprechende URLs verwandeln. Sprechende URLs sehen nicht nur ansprechender aus, sondern weisen zusätzlich noch auf das Thema der Seite hin. Sie "sprechen" sozusagen ein wenig für sich und für den Besuch einer Seite.

Als erstes Beispiel soll eine aus einzelnen News bestehende Artikelserie dienen. Die einzelnen News wurden mit den jeweiligen Titeln, Anrissen und Texten sowie einer fortlaufenden id (AUTO_INCREMENT) in einer Datenbank abgespeichert. Über diese eindeutige id kann jeder Artikel nach dem Speichern abgerufen werden, wenn durch ein geeignetes Script eine Verbindung zur Datenbank aufgebaut wird. Voraussetzung ist, dass dem Script die jeweilige id übergeben wird. Oft erfolgt diese Übergabe per GET, wobei der URL hinter einem Fragezeichen ein Parameter folgt, dem die jeweilige id als Wert zugeordnet wird.

www.example.com/news/artikel.php?id=102

Da die URL durch den QueryString nicht besonders einladend aussieht, soll diese durch URL-Rewriting umgeschrieben werden, wobei als Seitenname der Titel des jeweiligen Artikels in der URL verwendet werden. Im Beispiel wurde ein Artikel mit dem Titel "Eisblumen am Fenster" unter der id 102 in der Datenbank gespeichert. Die gewünschte URL sollte wie folgt aussehen: 

www.example.com/news/eisblumen-am-fenster-102.html

Bei der Regel für dieses URL-Rewriting muss bedacht werden, dass es sich beim Titel und bei der id um veränderliche Werte handelt, wobei der Titel bzw. der zu verwendende Seitenname aus kleinen Buchstaben des lateinischen Alphabets bestehen kann und einzelne Worte durch einen Bindestrich zu trennen sind.
Für ein (Teil1-)Muster wäre die Zeichenklasse [a-z-] verwendbar. Der geklammerten Zeichenklasse sollte ein weiterer Bindestrich folgen, falls in der neuen URL der Seitenname durch einen Bindestrich von den Ziffern für die id getrennt wird. Die Zeichenklasse für die id bzw. für (Teil2-)Muster ist mit [0-9] wohl selbsterklärend. Benötigt für die Übernahme wird nur (Teil2-)Muster und da die von geklammerten Teilausdrücken gefundenen Werte in $ + Ziffer gespeichert werden, kann dieser Wert mit $2 übernommen werden.
Es sei angemerkt, es findet keine Weiterleitung statt, sondern es wird dem Server nur mitgeteilt, bei welcher aufgerufenen URL welche Seite auszuliefern ist, wobei die eigentliche URL unsichtbar bleibt.

Erstes Beispiel:

RewriteEngine on

RewriteRule ^news/([a-z-]+)-([0-9]+)\.html$ /news/artikel.php?id=$2 [L] 

Das erste Beispiel hat einen kleinen Nachteil, der darin besteht, dass sich sowohl eine URL wie www.example.com/news/eisblumen-am-fenster-102.html als auch eine URL wie www.example.com/news/artikel.php?id=102 aufrufen lässt. Dieser Nachteil lässt sich lösen, indem ein einfaches URL-Rewriting mit einer Weiterleitung kombiniert wird.

Das zweite Beispiel arbeitet in beiden Richtungen und schließt die Nachteile des ersten Beispiels aus. Würde unbeabsichtigter Weise ein Aufruf der URL www.example.com/themen.php?thema=142 erfolgen, so würde diese auf die URL www.example.com/themen-142.html weitergeleitet und der Server würde nur im Hintergrund die eigentliche Seite ausliefern, ohne das die URL .../themen.php?thema=142 im Browser sichtbar würde.
Um eine Endlosschleife zu verhindern, wird beim URL-Rewriting ein zusätzliches Parameter-Wertepaar benötigt, dessen einzige Aufgabe darin besteht, den QueryString so zu verändern, dass das Muster in der Kondition nicht mehr nach einer ersten Umschreibung mit dem QueryString übereinstimmt.

Zweites Beispiel:

RewriteEngine on

RewriteCond %{QUERY_STRING} ^thema=([0-9]+)$
RewriteRule ^themen\.php$ /themen-%1.html? [L,R=301]
RewriteRule ^themen-([0-9]+)\.html$ /themen.php?thema=$1&nur=so [QSA,L]

In begründeten Ausnahmefällen ließe sich diese Variante mit einer zusätzlichen Bedingung absichern, um das Parameter-Wertepaar nur=so explizit zu sperren. Der Bezeichner und Wert ist frei wählbar, ebenso wie die Bezeichner und Werte der restlichen in den Beispielen verwendeten Parameter-Wertepaare.

Es sei angemerkt, werden andere Werte als in den Beispielen verwendet, müssen gegebenenfalls die Zeichenklassen entsprechend den Bedingungen angepasst werden. Einfacher sieht hingegen die Angelegenheit im dritten Beispiel aus, wo keine zusätzlichen Werte in den Dateinamen aufgenommen werden sollen.

Drittes Beispiel (ohne Übernahme eines QueryStrings):

RewriteEngine on

RewriteCond %{QUERY_STRING} !^nur=so$
RewriteRule ^interne\.php$ /sichtbare.html? [L,R=301]
RewriteRule ^sichtbare\.html$ /interne.php?nur=so [QSA,L]

Mit Übernahme eines unveränderten QueryStrings:

RewriteEngine on

RewriteCond %{QUERY_STRING} !^nur=so.*$
RewriteRule ^interne\.php$ /sichtbare.html [L,R=301]
RewriteRule ^sichtbare\.html$ /interne.php?nur=so [QSA,L]

Alle möglichen Varianten hier aufzunehmen, ginge etwas zu weit, da die Konditionen und Regeln immer von den jeweiligen Erfordernissen abhängig sind. Das Prinzip bleibt hingegen gleich.

Auf mobile Seiten | Serverseitige | Weitere Beispiele « / » Weiterleitung in Masse