Die .htaccess-Datei: Einstellungen für Ihren Webspace

Die Datei .htaccess steuert, wie der Webserver mit Ihrem Webspace umgeht, ohne dass Sie Zugriff auf seine Konfiguration brauchen. Mit ein paar Zeilen leiten Sie alle Besucher auf HTTPS um, schützen einen Ordner mit Passwort oder sperren den Zugriff auf Dateien, die niemand sehen soll. Die htaccess wirkt sofort nach dem Speichern, und genau das macht sie auch gefährlich: Ein Tippfehler legt die ganze Website mit einem Fehler 500 lahm. Mit den Beispielen in diesem Ratgeber und einer Sicherungskopie passiert das nicht.

Was die htaccess ist und wo sie wirkt

Der Name steht für „hypertext access“. Es ist eine reine Textdatei, deren Name mit einem Punkt beginnt. Auf Linux-Servern sind solche Dateien versteckt, im FTP-Programm müssen Sie deshalb oft erst „versteckte Dateien anzeigen“ einschalten.

Die Datei wirkt für den Ordner, in dem sie liegt, und für alle Unterordner. Eine htaccess im Hauptverzeichnis gilt für die ganze Website. Eine weitere im Ordner /intern/ gilt zusätzlich nur dort und kann Regeln von oben ergänzen oder überschreiben.

Wichtig: Die Datei funktioniert nur mit Apache und mit Servern, die dessen Regeln verstehen, etwa LiteSpeed. Die meisten Webhosting-Tarife in Deutschland nutzen einen davon. Läuft Ihre Seite auf Nginx, ignoriert der Server die Datei einfach. Dort gehören die Regeln in die Serverkonfiguration, die Ihr Anbieter oder Sie selbst auf einem vServer pflegen. Welcher Server läuft, verrät oft die Zeile Server in den Antwort-Headern, die Sie im Browser unter Entwicklerwerkzeuge und Netzwerk sehen.

Vor der ersten Änderung: Sicherung

Laden Sie die vorhandene Datei herunter und speichern Sie eine Kopie, bevor Sie etwas ändern. Ändern Sie dann immer nur einen Block und prüfen Sie die Seite sofort im Browser. Zeigt sie einen Fehler 500, spielen Sie die Kopie zurück. So wissen Sie genau, welche Zeile schuld war.

Bearbeiten Sie die Datei mit einem einfachen Texteditor, nicht mit Word. Speichern Sie im Format UTF-8 ohne Byte-Order-Mark und mit Zeilenenden im Unix-Format. Viele Editoren wie Notepad++ oder Visual Studio Code zeigen beides unten in der Statusleiste an. Auch der Dateimanager im Kundenmenü eignet sich gut, weil er direkt auf dem Server speichert.

Nutzen Sie WordPress, finden Sie in der Datei bereits einen Block zwischen # BEGIN WordPress und # END WordPress. Diesen Teil schreibt WordPress selbst neu, wenn Sie die Permalinks speichern. Eigene Regeln setzen Sie deshalb darüber, nie dazwischen.

Auf HTTPS weiterleiten mit der htaccess

Das ist die häufigste Aufgabe. Liegt ein Zertifikat für die Domain vor, leiten diese Zeilen jede Anfrage über HTTP dauerhaft auf HTTPS um:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Die Bedingung prüft, ob die Verbindung schon verschlüsselt ist. Wenn nicht, schickt die Regel den Besucher mit dem Code 301 auf dieselbe Adresse mit https. Liegt Ihre Seite hinter einem Proxy oder CDN, meldet der Server manchmal fälschlich „kein HTTPS“, und es entsteht eine Endlosschleife. Dann fragen Sie Ihren Anbieter, welche Variable dort gilt, häufig ist es %{HTTP:X-Forwarded-Proto}. Wie Sie ein kostenloses Zertifikat bekommen, erklärt der Ratgeber zu Let's Encrypt.

Was die Zeichen in den Regeln bedeuten

Die Regeln sehen auf den ersten Blick kryptisch aus, folgen aber einem einfachen Muster. RewriteCond ist eine Bedingung, RewriteRule die Aktion, die folgt, wenn alle Bedingungen davor zutreffen. Am Ende stehen in eckigen Klammern die sogenannten Flags:

• R=301: eine dauerhafte Weiterleitung. Mit R=302 wäre sie vorübergehend.
• L: „last“, nach dieser Regel hört der Server für diesen Durchlauf auf.
• NC: „no case“, Groß- und Kleinschreibung spielt keine Rolle.

Das Zeichen ^ steht für den Anfang, $ für das Ende, (.*) für „beliebig viel“, und $1 setzt das, was in der Klammer gefunden wurde, an anderer Stelle wieder ein. Die Reihenfolge zählt: Der Server arbeitet die Regeln von oben nach unten ab. Setzen Sie deshalb Weiterleitungen nach HTTPS und auf die Hauptadresse ganz nach oben und spezielle Regeln für einzelne Seiten darunter. Die Zeile RewriteEngine On reicht einmal am Anfang der Datei.

Mit oder ohne www

Ihre Seite sollte nur unter einer Adresse erreichbar sein, entweder mit oder ohne www. Sonst sieht eine Suchmaschine zwei Kopien derselben Seite. Diese Regel leitet alles ohne www auf die Variante mit www um:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^beispiel\.de$ [NC]
RewriteRule ^ https://www.beispiel.de%{REQUEST_URI} [L,R=301]

Für den umgekehrten Weg tauschen Sie die beiden Domainnamen. Den Punkt im Domainnamen schreiben Sie in der Bedingung mit einem Backslash davor, weil ein Punkt sonst für jedes beliebige Zeichen steht. Setzen Sie diese Regel direkt unter die HTTPS-Regel, dann bekommt ein Besucher höchstens zwei Weiterleitungen hintereinander.

Einzelne Seiten weiterleiten

Haben Sie eine Seite umbenannt, leiten Sie die alte Adresse auf die neue um. So bleiben Links und Rankings erhalten:

Redirect 301 /leistungen-alt.html https://www.beispiel.de/leistungen/
RedirectMatch 301 ^/blog/(.*)$ https://www.beispiel.de/ratgeber/$1

Die erste Zeile leitet genau eine Adresse um, die zweite einen ganzen Ordner mit allem, was darin liegt. Welche Arten von Weiterleitungen es gibt und wann 301 oder 302 passt, beschreibt der Ratgeber zur Domain-Weiterleitung.

Ordner mit Passwort schützen

Für einen Testbereich oder einen internen Ordner reicht oft ein einfacher Passwortschutz. Er besteht aus zwei Dateien. Die htaccess im geschützten Ordner sagt dem Server, dass er nach einem Passwort fragen soll:

AuthType Basic
AuthName "Interner Bereich"
AuthUserFile /home/kunde/.htpasswd
Require valid-user

Die Datei .htpasswd enthält Benutzernamen und verschlüsselte Passwörter. Legen Sie sie außerhalb des öffentlichen Ordners ab und nennen Sie den vollen Pfad. Den genauen Pfad zeigt Ihr Kundenmenü, oft gibt es dort auch eine Funktion „Verzeichnisschutz“, die beide Dateien für Sie anlegt. Auf der Konsole erstellen Sie die Datei mit htpasswd -c -B /home/kunde/.htpasswd anna. Der Passwortschutz ist nur über HTTPS sicher, sonst geht das Passwort im Klartext über die Leitung.

Zugriff auf Dateien sperren

Manche Dateien liegen im Webordner, sollen aber nie im Browser abrufbar sein, etwa Konfigurationen, Sicherungen oder Protokolle. Diese Regel sperrt typische Dateiendungen:

<FilesMatch "\.(env|ini|log|sql|bak|zip)$">
    Require all denied
</FilesMatch>

Ein Ordner mit Uploads sollte keine PHP-Dateien ausführen. Legen Sie dort eine eigene htaccess mit diesem Inhalt an:

<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

Das verhindert, dass ein eingeschleustes Skript im Upload-Ordner läuft. Weitere Maßnahmen dieser Art sammelt der Ratgeber zur WordPress-Sicherheit. Die Schreibweise Require gilt ab Apache 2.4. Ältere Anleitungen nutzen noch Order deny,allow, das ist veraltet.

Browser-Cache und eigene Fehlerseiten

Bilder, Schriften, CSS und JavaScript ändern sich selten. Mit dem Modul mod_expires sagen Sie dem Browser, wie lange er sie behalten darf. Das spart bei wiederholten Besuchen viel Ladezeit:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Die Klammer IfModule sorgt dafür, dass nichts passiert, wenn das Modul fehlt, statt dass die Seite ausfällt. Wenn Sie CSS-Dateien mit langer Laufzeit ausliefern, hängen Sie bei Änderungen eine Versionsnummer an den Dateinamen, sonst sehen Besucher die alte Fassung. Mehr dazu steht im Ratgeber zu Caching-Strategien.

Eigene Fehlerseiten legen Sie mit einer Zeile fest, zum Beispiel ErrorDocument 404 /404.html. Eine freundliche Seite mit Suchfeld und Link zur Startseite hält Besucher eher als die nackte Standardmeldung.

Weiterleitungen testen

Der Browser merkt sich dauerhafte Weiterleitungen und zeigt Ihnen deshalb nicht immer, was der Server gerade tut. Testen Sie deshalb in einem privaten Fenster oder auf der Konsole mit curl:

curl -sI http://beispiel.de/leistungen-alt.html | grep -iE "^(HTTP|location)"

Die Antwort zeigt den Statuscode und das Ziel. Erwartet ist eine einzige Zeile mit 301 und dem Ziel mit https und www. Sehen Sie mehrere Weiterleitungen hintereinander, wenn Sie mit curl -sIL allen folgen, fassen Sie die Regeln zusammen.

Neben den Weiterleitungen eignet sich die Datei auch für Sicherheitsangaben an den Browser, etwa HSTS und Schutz vor fremden Rahmen. Welche das sind und wie Sie sie in der htaccess setzen, beschreibt der Ratgeber zu HTTP Security Headern.

PHP-Einstellungen: nicht immer per htaccess

Viele Anleitungen empfehlen Zeilen wie php_value upload_max_filesize 64M. Das funktioniert nur, wenn PHP als Apache-Modul läuft. Bei den meisten Hostern läuft PHP heute aber über PHP-FPM oder FastCGI, und dann führt genau diese Zeile zum Fehler 500. Stellen Sie solche Werte im Kundenmenü ein oder in einer Datei .user.ini im Webordner, wenn Ihr Anbieter das erlaubt. Die Schreibweise dort ist einfach: upload_max_filesize = 64M.

Die Gegenstücke bei Nginx

Ziehen Sie auf einen Server mit Nginx um, müssen die Regeln übersetzt werden. Die wichtigsten Entsprechungen:

• Weiterleitung auf HTTPS: ein eigener server-Block für Port 80 mit return 301 https://$host$request_uri;
• einzelne Adresse umleiten: location = /alt.html { return 301 /neu/; }
• Passwortschutz: auth_basic und auth_basic_user_file
• Dateien sperren: location ~ \.(env|sql|bak)$ { deny all; }
• Browser-Cache: expires 1y; in einem location-Block für Bilder

Nginx liest diese Regeln nur beim Neuladen, nicht bei jeder Anfrage. Deshalb ist es bei vielen Regeln schneller als Apache mit htaccess.

Wenn die htaccess die Seite lahmlegt

Zeigt die Seite nach einer Änderung einen Fehler 500, liegt es fast immer an einem Tippfehler oder an einem Befehl, den der Server nicht kennt. Gehen Sie so vor:

1. Sicherungskopie zurückspielen oder die Datei kurz umbenennen, etwa in htaccess.aus.
2. Im Fehlerprotokoll des Kundenmenüs nachsehen. Dort steht meist die genaue Zeile und der Grund, etwa „Invalid command“.
3. Den Block einzeln wieder einfügen und testen.

Halten Sie die Datei schlank. Der Server liest sie bei jeder Anfrage neu, auch in allen übergeordneten Ordnern. Hunderte Weiterleitungen aus alten Zeiten bremsen messbar. Lange Listen gehören besser in die Serverkonfiguration oder in ein Weiterleitungs-Plugin des CMS. Die vollständige Beschreibung aller Befehle finden Sie in der Dokumentation von Apache.