Mit Mod_Rewrite können Webserver Anfragen intern umgeschrieben bzw. extern umgeleitet werden. Insbesondere zur Vermeidung von doppelten Inhalten, Domain- & URL Umstellungen (Backlinkübertragung via 301 Redirect, Indexaktualisierung, Besucherweiterleitung auf die neue Seite), www. Umleitungen, Errichtung einer Wartungsseite und vielen weiteren Anliegen kommt Mod_Rewrite im Online-Marketing zum Einsatz. In diesem Artikel listen wir einige Snippets für die häufigsten Anwendungsfälle auf. Anhand der Beispiele können Sie mit geringen Modifikation schnell die passenden eigenen RewriteRules schreiben. Möchten Sie eine Reihe von alten URLs auf die jeweils passende neue URL umleiten, empfehlen wir als Agentur für Webentwicklung Ihnen unseren kostenlosen Mod_Rewrite Generator, der URI & Query URLs korrekt behandelt, um Corporate Websites und E-Commerce Shops auf das nächste Level zu bringen.
Damit die Mod_Rewrite Regeln greifen, muss auf dem Apache Webserver das Mod_Rewrite Modul aktiviert sein. Dies ist vermutlich bei über 95 % der Webhoster mittlerweile standardmäßig der Fall. Hierzu wird im sogenannten Document Root der Domain (Rootverzeichnis der Domain - meist ein Verzeichnis namens html, htdocs, o.ä.) eine .htaccess Datei angelegt, die in der ersten Zeile die RewriteEngine aktiviert.
RewriteEngine On
Um eine Regel auszukommentieren, nutzt man das Raute Zeichen (#):
#RewriteRule .* /index.php [L]
Hier wird über eine Rewrite Condition abgefragt, ob der Hostname am Anfang ein www. enthält. Ist dies nicht der Fall, wird per 301 Redirect (HTTP Status permanente Weiterleitung) auf die www. Variante umgeleitet. Das L bedeutet, dass hiernach keine weiteren Mod_Rewrite Rules berücksichtigt werden. Sprich, die Umleitung direkt durchgeführt wird. Das Hochdach (^) und das Dollarzeichen am Ende ($) definieren den Anfang und Ende der Zeichenkette.
RewriteCond %{HTTP_HOST} !^www\.(.+)$
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://www.%{HTTP_HOST}/$1 [R=301,L]
Bei der Trailing-Slash-Umleitung wird geschaut, ob am Ende der URL ein Slash (/) gesetzt ist. Ist dies nicht der Fall, wird die URL auf die Variante mit Trailing Slash umgeleitet. Hierbei sichert die erste Rewrite Condition, dass die Regel nicht greift, wenn auf eine Datei, z.B CSS, JS oder Image Files, verwiesen wird. Hinweis: In Apache Apache 2.2 gibt es ein Escape Parameter Fehler in Verbindung mit den Query Parametern bei einer Umleitung. Daher muss hier ein NE Flag (no escape) gesetzt werden. Ab Apache 2.4 besteht das Problem nicht mehr.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI} !(.*)/$
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://%{HTTP_HOST}/$1/ [R=301,L,NE]
Hierbei wird geprüft ob der Hostname der alten Domain entspricht und bei Zutreffen auf die neue Domain inkl. aktuell aufgerufenen Pfad per 301 Redirect umgeleitet. Durch das ausbleibende vorangestellte Hochdach (^) im Vergleich zur WWW Umleitung trifft diese Regel sowohl bei www., als auch bei jeglichen Subdomains des alten Hostnames zu.
RewriteCond %{HTTP_HOST} old\-example\.com$
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://www.new-example.com/$1 [R=301,L]
RewriteRule ^alte-seite.php$ http://www.example.com/neue-seite.php [L,R=301]
Alternativ kann man hier ebenso mit einer URI Condition arbeiten:
RewriteCond %{REQUEST_URI} alte-seite.php$
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://%{HTTP_HOST}/neue-seite.php [L,R=301]
Um auf einer Domain einen Ordner zu ändern, also von https://www.example.com/verzeichnis/datei.html zu https://www.example.com/anderes-verzeichnis/datei.html muss folgende Zeile verwendet werden:
RewriteRule ^verzeichnis/(.*)$ /anderes-verzeichnis/$1 [R=301,L]
Möchte man GET Parameter umleiten, müssen diese über %{QUERY_STRING} abgefragt werden:
RewriteCond %{QUERY_STRING} ^site=index$
RewriteRule index.php$ %{REQUEST_SCHEME}://%{HTTP_HOST}/index.php? [L,R=301]
Das Fragezeichen hinter der neuen URL sorgt dafür, dass die GET Parameter nicht erneut hinter der neuen URL angefügt werden.
Möchte man auf die in Query Strings eingeklammerten Werte zugreifen, nutzt man %1, %2 und so weiter:
RewriteCond %{QUERY_STRING} ^site=(.+)$
RewriteRule index.php$ %{REQUEST_SCHEME}://%{HTTP_HOST}/%1.php? [L,R=301]
Sollen die Rewrites nicht nur für Query Parameter gelten, die an die index.php übergeben werden, kann man Folgendes nutzen:
RewriteCond %{QUERY_STRING} ^site=(.+)$
RewriteRule .* %{REQUEST_SCHEME}://%{HTTP_HOST}/%1.php? [L,R=301]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
Wenn der Server Port nicht 443 (SSL) entspricht, wird auf die https Variante umgeleitet:
RewriteCond %{SERVER_PORT} !443$
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
Möchte man nur bestimmte Seiten, z.B. die Loginseite, auf die HTTPS Variante umleiten, so kann man folgendes Snippet nutzen:
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !login/
RewriteRule ^(.*)$ %{REQUEST_SCHEME}://%{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} login/
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
Hierbei werden alle anderen Seiten auf die HTTP Variante umgeleitet und die Loginseite auf die HTTPS Version.
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ %{REQUEST_SCHEME}://%{HTTP_HOST}/maintenance.html [R=307,L]
Der 307 Redirect steht für einen Temporary Redirect und besagt, dass die angeforderte Ressource vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit steht, die alte Adresse jedoch Gültigkeit behält. Auf der Wartungsseite selbst, sollte dann der Status Code 503 Service Temporarily Unavailable ausgegeben werden:
header('HTTP/1.1 503 Service Temporarily Unavailable');
header('Status: 503 Service Temporarily Unavailable');
Durch das [F] Flag wird ein 403 Forbidden Status zurückgegeben:
RewriteCond %{REMOTE_ADDR} ^89\.123\.321\.123$
RewriteRule .* - [F]
Möchte man mehrere IP Adresse sperren, können diese mit einem OR verknüpft werden. Standardmäßig werden mehrere Rewrite Conditions via UND verknüpft.
RewriteCond %{REMOTE_ADDR} ^89\.123\.321\.123$ [OR]
RewriteCond %{REMOTE_ADDR} ^89\.124\.421\.124$
RewriteRule .* - [F]
Gerade wenn man bestimmte Spam Zugriffe Seitenweit aus allen Analysewerkzeugen fernhalten möchte, ist ein Sperrung bestimmter Referrer sinnvoll. Siehe auch den Artikel zum Thema Semalt Referrer Spam in Google Analytics. Der NC Parameter besagt hier, dass nicht auf Groß- und Kleinschreibung geachtet wird.
RewriteCond %{HTTP_REFERER} semalt\.com [NC]
RewriteRule .* - [F]
Diese Methode kommt häufig in PHP MVC Frameworks zum Einsatz um die Controller und Action Verwaltung abzubilden. Hierbei erfolgt keine Weiterleitung der Nutzer auf die index.php. Die Anfragen laufen intern, aber immer auf die index.php:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* index.php [L]
Kurze Erklärung der gängigsten RewriteCond %{REQUEST_FILENAME} Parameter:
RewriteRule ^(.*).html$ $1.php
RewriteRule ^site_([0-9]+).html$ site.php?id=$1
RewriteCond %{HTTP_COOKIE} !^.*cookiename=cookievalue.*$ [NC]
RewriteRule .* intern/index.php [L]
Eine multidomain Joomla Landingpage ist gar keine so große Herausforderung im Webdesign, wie man vielleicht zuerst vermutet. Für diese Situation muss nur eine eigenständige PHP Datei erstellt werden, die losgelöst von Joomla funktioniert, aber nicht auf das Joomla Framework verzichtet. Damit könnte man auch Inhalte wie Module darstellen oder aber auch die Landingpage. Multidomain Joomla Landingpage als Fallbeispiel In […]
Weiterlesen
Es kommt auch heutzutage noch immer vor, dass viele eigen programmierte Webseiten in einem erhöhtem Sicherheitsrisiko existieren, da sich die Programmierer nicht ausreichend um die Sicherheit gekümmert haben. Die Folgen solcher Programmierung können verheerend hoch sein, daher möchten wir nun einige Sicherheitsmethoden vorstellen, wie man sich effektiv gegen die bekanntesten Angriffe schützen kann.
Weiterlesen
Während so langsam auch das letzte Unternehmen von der Wichtigkeit der mobilfreundlichen Webseite z.B. mittels responsive Design erfahren hat und entsprechende Schritte plant, baut Google nun noch mehr Druck auf. Am 15. November gab Google im Webmaster Zentrale Blog bekannt einen Mobile-first Index einführen zu wollen (in den USA bereits am 13. Oktober auf der […]
Weiterlesen
