500 Error nach .htaccess-Änderung: So reparieren Sie Ihre Website

Die .htaccess ist eine Konfigurationsdatei für den Apache-Webserver, die laut offizieller Apache-Dokumentation bei jedem einzelnen Seitenaufruf neu eingelesen wird. Enthält sie auch nur einen kleinen Fehler, bricht der Server die Verarbeitung ab und antwortet mit einem 500 Internal Server Error. Im Gegensatz zu einem 404-Fehler (Seite nicht gefunden) oder einem 403-Fehler (Zugriff verweigert) bedeutet der 500 Error, dass der Server selbst an einer fehlerhaften Konfiguration scheitert.

Ein Detail, das bei der Diagnose viel Zeit spart: Dieses Verhalten gilt für Apache und für LiteSpeed-Server, die die .htaccess ebenfalls auswerten. Läuft Ihre Website dagegen hinter einem NGINX-Server, ignoriert dieser die Datei komplett – der 500 Error hat dann eine andere Ursache. Welcher Server bei Ihnen läuft, steht im Hosting-Panel oder in der Antwort Ihres Hosting-Supports.

Das Problem tritt häufiger auf, als Sie denken. Typische Situationen, in denen die .htaccess zum Stolperstein wird:

• Redirect-Regel eingerichtet: Sie wollten eine Weiterleitung einrichten und haben dabei einen Syntaxfehler eingebaut.
• Code aus dem Internet kopiert: Eine Anleitung aus einem Forum befolgt, aber der Code passt nicht zu Ihrer Server-Konfiguration.
• Passwortschutz aktiviert: Die Pfadangabe zum Passwort-File stimmt nicht oder die Direktive ist falsch geschrieben.
• Plugin hat die Datei verändert: Ein Sicherheits- oder Caching-Plugin hat automatisch Regeln eingefügt, die Ihr Server nicht unterstützt.

Die fünf häufigsten Auslöser sind Tippfehler in Direktiven, ein falsches Dateiformat, nicht unterstützte PHP-Direktiven, falsche Pfadangaben und Redirect-Endlosschleifen. In meiner Reparatur-Praxis führen zwei davon die Liste mit Abstand an: simple Tippfehler und veraltete php_flag-Befehle aus alten Anleitungen, die auf modernem Hosting nicht mehr laufen.

• Syntaxfehler: Tippfehler in Direktiven wie RewriteRul statt RewriteRule, fehlendes Leerzeichen zwischen Parametern oder vergessene Anführungszeichen. Schon ein einziges falsches Zeichen reicht. Im Error-Log erscheint dann eine Meldung wie Invalid command 'RewriteRul', perhaps misspelled – zusammen mit dem Pfad zur .htaccess. Nach dem genannten Befehl suchen Sie in der Datei und finden so die fehlerhafte Zeile.
• Falsches Dateiformat: Die .htaccess wurde mit Word oder einem Textverarbeitungsprogramm gespeichert, das unsichtbare BOM-Zeichen (Byte Order Mark) einfügt. Die Datei muss im reinen ASCII- oder UTF-8-Format ohne BOM vorliegen.
• Nicht unterstützte oder gesperrte Direktiven: Befehle wie php_flag oder php_value funktionieren nur bei Apache mit mod_php. Bei FastCGI- oder PHP-FPM-Konfigurationen (die heute Standard sind) lösen sie sofort einen htaccess Internal Server Error aus – dieses Fehlerbild sehe ich am häufigsten, wenn ältere Anleitungen aus Foren kopiert wurden. Zusätzlich legt der Hoster über die Einstellung AllowOverride fest, welche Direktiven in der .htaccess überhaupt erlaubt sind. Verwenden Sie eine gesperrte, antwortet Apache mit einem 500 Error und protokolliert not allowed here.
• Falsche Pfadangaben: Bei AuthUserFile muss der absolute Serverpfad angegeben werden, nicht der relative. Auch eine falsche RewriteBase führt zu Problemen.
• Redirect-Endlosschleifen: Zwei Regeln, die sich gegenseitig weiterleiten, erzeugen eine Endlosschleife. Der Server erkennt das und bricht mit einem 500 Error ab.

Der schnellste Weg: Benennen Sie die .htaccess um, grenzen Sie die fehlerhafte Zeile blockweise ein und prüfen Sie das Error-Log – in genau dieser Reihenfolge. Mit diesem Dreischritt finden Sie praktisch jeden .htaccess-Fehler ohne Spezialwerkzeug, in den meisten Fällen innerhalb weniger Minuten:

Schritt 1: .htaccess per FTP umbenennen

Verbinden Sie sich per FTP mit Ihrem Server und navigieren Sie zum Hauptverzeichnis Ihrer Website. Benennen Sie die Datei .htaccess in .htaccess_backup um. Rufen Sie danach Ihre Website auf. Lädt sie wieder? Dann liegt der Fehler definitiv in der .htaccess-Datei. Zeigt sie weiterhin einen Fehler, ist die Ursache woanders, und Sie sollten im umfassenden Ratgeber zum 500 Error die weiteren Möglichkeiten prüfen.

Schritt 2: Fehlerhafte Zeile finden

Erstellen Sie eine neue, leere .htaccess-Datei und fügen Sie die Zeilen aus Ihrem Backup einzeln oder blockweise wieder ein. Testen Sie nach jeder Ergänzung, ob die Website noch funktioniert. Alternativ können Sie in der Backup-Datei einzelne Zeilen mit einem #-Zeichen auskommentieren und die Website jeweils neu laden. So isolieren Sie die fehlerhafte Direktive.

Schritt 3: Error-Log prüfen und Fehler korrigieren

Prüfen Sie das Error-Log Ihres Servers. Dort finden Sie die genaue Fehlermeldung mit dem Pfad zur .htaccess und der beanstandeten Direktive. In meinem Artikel WordPress Error-Logs finden und verstehen erkläre ich Ihnen, wo Sie diese Logdateien finden und wie Sie die Einträge lesen. Korrigieren Sie die fehlerhafte Direktive oder entfernen Sie sie.

WordPress kann seine .htaccess selbst neu erstellen: Benennen Sie die defekte Datei um und klicken Sie im Backend auf Einstellungen > Permalinks > Änderungen speichern – WordPress schreibt daraufhin den Standard-Block neu. Nur Ihre eigenen Regeln (Redirects, Sicherheitseinstellungen) müssen Sie danach manuell wieder einfügen.

Der Standard-Block, den WordPress generiert, ist in der offiziellen WordPress-Dokumentation festgelegt und sieht so aus:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Wichtig: Wenn Sie eigene Regeln hinzufügen (Redirects, Sicherheitseinstellungen, Caching-Regeln), platzieren Sie diese immer vor dem Block # BEGIN WordPress. Regeln, die nach # END WordPress stehen, werden von WordPress beim nächsten Permalink-Speichern möglicherweise überschrieben.

Achten Sie auch darauf, welche Plugins Ihre .htaccess verändern. Sicherheits-Plugins, Caching-Plugins und Redirect-Plugins schreiben häufig eigene Regeln in die Datei. Wenn Sie nach der Aktivierung eines solchen Plugins einen 500 Error erhalten, deaktivieren Sie das Plugin per FTP (benennen Sie den Plugin-Ordner um) und prüfen Sie die .htaccess. In meinem Artikel über die weiße Seite nach Plugin-Updates finden Sie weitere Tipps zur Plugin-Fehlersuche.

Ein Hinweis aus der Entwickler-Praxis: Der WordPress-Debug-Modus hilft Ihnen bei diesem Fehler nicht weiter. Ein .htaccess-Fehler stoppt die Anfrage bereits auf Server-Ebene, bevor PHP überhaupt startet – das WordPress-Debug-Log bleibt also leer, und die Antwort steht ausschließlich im Error-Log des Servers. Bei Plugin-Konflikten und PHP-Fehlern ist der Debug-Modus dagegen das richtige Werkzeug; wie Sie ihn aktivieren, zeige ich im Artikel zum WP-Debug-Modus.

Einige Gewohnheiten verhindern nach meiner Erfahrung fast alle .htaccess-Unfälle: ein Backup vor jeder Änderung, ein echter Code-Editor statt Textverarbeitung, kleine Änderungsschritte mit sofortigem Test und ein Blick ins Error-Log. Diese Punkte kosten zusammen keine fünf Minuten – und ersparen Ihnen die stundenlange Fehlersuche:

• Backup vor jeder Änderung: Laden Sie die aktuelle Datei herunter, bevor Sie etwas ändern. Im Ernstfall sind Sie in Sekunden wieder online.
• Richtigen Texteditor verwenden: Nutzen Sie Notepad++, VS Code oder einen anderen Code-Editor. Verwenden Sie niemals Word, LibreOffice Writer oder andere Textverarbeitungsprogramme, die unsichtbare Formatierungen einfügen.
• Änderungen einzeln vornehmen: Fügen Sie neue Regeln nacheinander ein und testen Sie nach jeder Ergänzung. So finden Sie Fehler sofort, statt in einem Block aus 20 neuen Zeilen suchen zu müssen.
• Error-Log nach jeder Änderung prüfen: Das Error-Log verrät Ihnen sofort, ob eine Direktive Probleme verursacht, auch wenn die Seite noch funktioniert.
• PHP-Version aktuell halten: Nutzen Sie PHP 8.4 oder 8.5 – nur diese beiden Versionen erhalten laut php.net derzeit noch aktiven Support (Stand: Juli 2026). Veraltete PHP-Versionen sind nicht nur langsamer, sondern auch ein Sicherheitsrisiko. Prüfen Sie die Version in Ihrem Hosting-Panel.
• Bei Unsicherheit: Profi fragen: Wenn Sie sich bei einer Konfiguration nicht sicher sind, lassen Sie sich beraten, bevor Sie experimentieren.

Zuletzt aktualisiert: 6. Juli 2026  ·  Lesezeit: ca. 8 Minuten