Die .htaccess-Datei: Weiterleitungen, HTTPS und Passwortschutz

Auf vielen Webhosting-Paketen hast du keinen Zugriff auf die Konfiguration des Webservers. Trotzdem willst du alte Adressen weiterleiten, HTTPS erzwingen oder einen Ordner mit einem Passwort schützen. Dafür gibt es auf Servern mit Apache die Datei .htaccess. Sie liegt in einem Verzeichnis deiner Website und enthält Anweisungen in derselben Schreibweise wie die Hauptkonfiguration. Diese Anweisungen gelten für das Verzeichnis und alle Unterverzeichnisse ^[1].

Was die .htaccess ist und wann sie wirkt

Apache nennt solche Dateien verteilte Konfigurationsdateien. Der Name .htaccess ist nur die Voreinstellung; ein Administrator kann ihn mit der Anweisung AccessFileName ändern ^[1]. Ob und was Apache aus der Datei liest, bestimmt die Hauptkonfiguration mit AllowOverride. Die Voreinstellung ist AllowOverride None, und dann ignoriert Apache .htaccess-Dateien vollständig ^{[1, 6]}. Bei Hostern ist das Lesen fast immer eingeschaltet, oft aber nur für bestimmte Gruppen von Anweisungen.

Steht in der Datei eine Anweisung, die der Server dort nicht erlaubt, antwortet er mit einem Serverfehler ^[1]. Ein Tippfehler in der .htaccess legt deshalb schnell die ganze Website lahm. Lade eine geänderte Datei nur hoch, wenn du die alte Fassung gesichert hast und sie sofort zurückspielen kannst.

Die Dokumentation von Apache rät klar dazu, alles in die Hauptkonfiguration zu schreiben, wenn man Zugriff darauf hat ^[1]. Der Grund ist die Leistung: Bei eingeschalteter .htaccess sucht Apache bei jedem Abruf in jedem Verzeichnis des Pfades nach einer solchen Datei und liest sie neu ein. Für eine Datei unter /www/htdocs/example sind das vier zusätzliche Zugriffe auf das Dateisystem, auch wenn gar keine .htaccess vorhanden ist ^[1]. Gedacht ist die Datei für Fälle, in denen Betreiber keinen Zugriff auf den Server haben, also für typisches Webhosting und für Programme wie Content-Management-Systeme, die ihre eigene .htaccess mitbringen ^[1]. Ein Vorteil folgt daraus: Weil die Datei bei jedem Abruf neu gelesen wird ^[1], wirkt eine Änderung ohne Neustart des Servers.

Andere Webserver wie nginx lesen keine .htaccess ^[9]. Läuft dein Paket nicht auf Apache, frag deinen Hoster, wo du Weiterleitungen einstellst.

Weiterleitungen mit Redirect

Für einfache Weiterleitungen empfiehlt Apache die Anweisung Redirect aus dem Modul mod_alias. Apache rät, einfache Weiterleitungen damit statt mit RewriteRule einzurichten, und nennt mod_rewrite einen letzten Ausweg ^[5]. Der Aufbau ist "Redirect Status Alter-Pfad Ziel". Ohne Angabe des Status leitet Apache vorübergehend mit 302 weiter. Mit permanent wird daraus 301, mit gone meldest du 410 für eine bewusst entfernte Seite und lässt das Ziel weg ^[2].

Redirect permanent "/alte-seite.html" "https://www.example.com/neue-seite/"
Redirect permanent "/blog" "https://www.example.com/ratgeber"
Redirect gone "/aktion-2019.html"

Redirect vergleicht den Anfang des Pfades und hängt den Rest an das Ziel an ^[2]. Die zweite Zeile leitet also auch /blog/beitrag-1 auf /ratgeber/beitrag-1 weiter. Das ist praktisch, wenn ganze Bereiche umziehen, und überraschend, wenn du nur eine einzelne Seite meintest. Für Muster gibt es RedirectMatch mit regulären Ausdrücken. Dort setzt $1 den ersten eingeklammerten Teil ins Ziel ein ^[2].

RedirectMatch permanent "^/produkte/(.*)\.html$" "https://www.example.com/shop/$1/"

301, 302 oder 308?

Der Statuscode sagt Browsern und Suchmaschinen, wie sie die Weiterleitung verstehen sollen. Die Regeln dafür stehen in RFC 9110 ^[8]:

Antworten mit 301 und 308 dürfen Browser auch ohne ausdrückliche Angabe zwischenspeichern ^[8]. Eine falsch gesetzte dauerhafte Weiterleitung bleibt deshalb bei Besuchern hängen, auch wenn du sie längst entfernt hast. Teste neue Regeln zuerst ohne permanent und stelle erst um, wenn alles stimmt. Alle Codes im Überblick erklärt HTTP-Statuscodes von 200 bis 503. Wie Suchmaschinen mit 301, 302 und 410 umgehen, steht auf seo.domain-root.de unter Weiterleitungen und SEO.

HTTPS und www erzwingen mit mod_rewrite

Für Bedingungen, die Redirect nicht prüfen kann, gibt es mod_rewrite. Apache selbst nennt es das Mittel für Fälle, in denen nur eine .htaccess zur Verfügung steht ^{[4, 5]}. Das häufigste Beispiel ist die Umleitung von HTTP auf HTTPS. Eine Regel dafür steht in der Dokumentation ^[4]. In einer .htaccess schneidet Apache den führenden Schrägstrich des Pfades ab, deshalb steht hier vor $1 ein Schrägstrich:

RewriteEngine On
RewriteCond "%{HTTPS}" !=on
RewriteRule "^(.*)" "https://%{SERVER_NAME}/$1" [R=301,L]

RewriteCond prüft, ob die Verbindung noch nicht verschlüsselt ist. Nur dann greift die RewriteRule und leitet mit dem Status 301 auf dieselbe Adresse mit https um. Läuft die Verschlüsselung bei deinem Hoster über einen vorgeschalteten Lastverteiler, sieht Apache jede Anfrage als unverschlüsselt an, und die Regel erzeugt eine Endlosschleife. Die Dokumentation nennt für diesen Fall die Kopfzeile X-Forwarded-Proto, aber nur, wenn der vorgeschaltete Server sie bei jeder Anfrage selbst setzt ^[4]. Die übrigen Schritte der Umstellung beschreibt Von HTTP auf HTTPS umstellen.

Nach demselben Muster legst du fest, dass deine Website nur unter einem Namen erreichbar ist, etwa mit www. Die Apache-Dokumentation zeigt dafür diese Regel, die in der .htaccess im Hauptverzeichnis funktioniert ^[4]:

RewriteCond "%{HTTP_HOST}" "!^www\.example\.com" [NC]
RewriteCond "%{HTTP_HOST}" "!^$"
RewriteRule "^/?(.*)" "http://www.example.com/$1" [L,R,NE]

Für eine Website mit HTTPS ersetzt du im Ziel http durch https und R durch R=301. Die Zeichen in eckigen Klammern sind Schalter: R leitet weiter, standardmäßig mit 302, L beendet die Bearbeitung der Regeln, NC macht den Vergleich unabhängig von Groß- und Kleinschreibung, und NE verhindert, dass Zeichen wie # umcodiert werden ^[3].

Schleifen vermeiden

In der .htaccess verhält sich mod_rewrite anders als in der Hauptkonfiguration. Nach einer erfolgreichen Umschreibung kann Apache die neue Adresse noch einmal von oben durch alle Regeln schicken. L beendet nur den aktuellen Durchgang, der Schalter END beendet die Bearbeitung ganz und ist laut Dokumentation für die meisten Regeln in Verzeichnissen die bessere Wahl ^[3]. Außerdem sind die Pfade in RewriteRule hier relativ zum Verzeichnis: Der führende Schrägstrich fehlt ^[1]. Mischst du Redirect und RewriteRule in einer .htaccess, bestimmt nicht die Reihenfolge in der Datei, welche Anweisung zuerst greift. Ein Redirect kann dann von einer passenden RewriteRule überholt werden. Am übersichtlichsten bleibt die Datei, wenn du dich je Aufgabe für eines der beiden Module entscheidest.

Eigene Fehlerseiten

Mit ErrorDocument legst du fest, was Besucher bei einem Fehler sehen ^[6]:

ErrorDocument 404 /fehler/nicht-gefunden.html
ErrorDocument 500 "Der Server hat gerade ein Problem. Bitte versuche es später noch einmal."

Pfade mit führendem Schrägstrich beziehen sich auf das Hauptverzeichnis der Website. Gib dabei keine vollständige Adresse mit http oder https an. Dann schickt Apache eine Weiterleitung, und der Besucher bekommt den eigentlichen Fehlercode nicht mehr zu sehen ^[6]. Für Suchmaschinen sieht eine fehlende Seite dann wie eine Weiterleitung auf eine vorhandene Seite aus.

Verzeichnis mit Passwort schützen

Für einen einfachen Zugangsschutz brauchst du zwei Dinge: eine Passwortdatei, die du mit dem Programm htpasswd erzeugst, und ein paar Zeilen in der .htaccess des zu schützenden Ordners ^[7]. Die Passwortdatei gehört an einen Ort, der aus dem Web nicht erreichbar ist, damit niemand sie herunterladen kann ^[7].

AuthType Basic
AuthName "Interner Bereich"
AuthUserFile "/pfad/ausserhalb/des/webroots/.htpasswd"
Require valid-user

Require valid-user lässt jeden Nutzer aus der Passwortdatei herein, Require user mit einem Namen nur diesen einen ^[7]. Damit die Zeilen wirken, muss der Hoster AllowOverride AuthConfig erlauben ^[7]. Bei diesem Verfahren schickt der Browser das Passwort unverschlüsselt an den Server. Apache rät deshalb, es bei sensiblen Daten nur zusammen mit mod_ssl einzusetzen ^[7]. Ohne HTTPS kann jeder, der die Verbindung mitliest, das Passwort lesen.

Typische Fehler

• Fehler 500 nach dem Hochladen: eine Anweisung, die der Server in der .htaccess nicht erlaubt, oder ein Tippfehler.
• Die Datei wirkt gar nicht: Der Server liest keine .htaccess, oder es läuft ein anderer Webserver als Apache.
• Endlose Weiterleitung: Die Bedingung für HTTPS oder www trifft auch auf die neue Adresse zu, etwa hinter einem Lastverteiler.
• Eine Weiterleitung bleibt im Browser hängen, weil sie als 301 zwischengespeichert wurde.
• Ein Redirect trifft mehr Seiten als gedacht, weil der Pfadanfang auch Unterseiten erfasst.

Ist deine Website nach einer Änderung gar nicht mehr erreichbar, hilft die Schritt-für-Schritt-Anleitung unter Website nicht erreichbar. Nutzt dein Hoster Plesk, kannst du manche dieser Regeln auch dort einstellen; mehr dazu unter Plesk: Domains, Subdomains und Zertifikate verwalten.

1. Organisation Apache HTTP Server Tutorial: .htaccess files. The Apache Software Foundation. Stand 2026. abgerufen am 29.10.2026
2. Organisation Apache Module mod_alias. The Apache Software Foundation. Stand 2026. abgerufen am 29.10.2026
3. Organisation RewriteRule Flags. The Apache Software Foundation. Stand 2026. abgerufen am 29.10.2026
4. Organisation Redirecting and Remapping with mod_rewrite. The Apache Software Foundation. Stand 2026. abgerufen am 29.10.2026
5. Organisation When not to use mod_rewrite. The Apache Software Foundation. Stand 2026. abgerufen am 29.10.2026
6. Organisation Apache Core Features: ErrorDocument, AllowOverride. The Apache Software Foundation. Stand 2026. abgerufen am 29.10.2026
7. Organisation Authentication and Authorization. The Apache Software Foundation. Stand 2026. abgerufen am 29.10.2026
8. Gesetz RFC 9110: HTTP Semantics, Abschnitte 15.4 und 15.5. IETF. Stand Juni 2022. abgerufen am 29.10.2026
9. Organisation 9 Tips for Improving WordPress Performance with NGINX. NGINX Blog. Stand ohne Datum. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.