WordPress: .htaccess-Datei auf die Standardeinstellungen zurücksetzen

In die .htaccess-Datei schreiben sowohl WordPress als auch die Plugins und das Hosting-Kontrollpanel. Wenn ein Plugin eine fehlerhafte Zeile darin hinterlässt oder bei der manuellen Bearbeitung ein Tippfehler entsteht, gibt die Website einen 500er-Fehler aus oder die Unterseiten zeigen einen 404er-Fehler an. In diesem Fall ist die schnellste Lösung, die Datei auf den Ausgangszustand zurückzusetzen, da sich so innerhalb weniger Minuten herausstellt, ob dies tatsächlich die Ursache des Fehlers ist.

Wir haben die Schritte im Oktober 2026 auf einem aWh-cPanel-Hosting-Testkonto mit WordPress 7.1 getestet. Eine einzige fehlerhafte Zeile in der Datei führte dazu, dass die gesamte Website einen 500-Fehler anzeigte.

Wann ist dieser Artikel hilfreich?

Fehler 500 (Internal Server Error) nach der Installation oder Deinstallation eines Plugins oder nach der manuellen Bearbeitung der Datei.
Die Startseite funktioniert, doch die Unterseiten geben einen 404-Fehler aus.
Eine Weiterleitungsschleife („zu viele Weiterleitungen“), die durch ein Plugin oder eine manuell festgelegte Regel verursacht wird.

Falls der Fehler durch ein Update verursacht wurde, lesen Sie bitte zunächst den Artikel „Fehler 500 nach einem Plugin-Update“, da die Ursache des Fehlers in solchen Fällen meist nicht in der Datei „.htaccess“ liegt.

Was geht verloren, wenn Sie das System auf die Werkseinstellungen zurücksetzen?

Die Datei enthält nicht nur die WordPress-Regeln. Auf einem cPanel-Hosting-Account finden Sie folgende Abschnitte:

# BEGIN cPanel-generated php ini directives: Diese werden von cPanel generiert und legen unter anderem den Speicherort des PHP-Fehlerprotokolls fest. Ohne diese Einstellung wurde das Fehlerprotokoll in unserem Test nicht in „~/logs/php.error.log“, sondern in die Datei „error_log“ im Verzeichnis der ausgeführten PHP-Datei geschrieben. Die PHP-Version hat sich nicht geändert: Diese wird über die Oberfläche „Select PHP Version“ verwaltet.
RewriteCond-/RewriteRule-Zeilen außerhalb des WordPress-Blocks: beispielsweise Weiterleitungen, die auf der Seite „Weiterleitungen“ in cPanel eingerichtet wurden.
Plugin-Blöcke: Regeln für Caching- und Sicherheits-Plugins, in der Regel mit der eigenen Kennzeichnung „# BEGIN“. Bitte beachten Sie den Block „# Wordfence WAF“: Ohne diesen funktioniert die Website zwar, doch die Wordfence-Firewall ist in unserem Test unbemerkt ausgefallen.
Eigene Regeln: Zeilen, die beispielsweise zum Blockieren von Bots oder zum Sperren von IP-Adressen hinzugefügt wurden.

Löschen Sie die alte Datei daher nicht, sondern benennen Sie sie um: Die nützlichen Teile können Sie später wieder kopieren.

1. Benennen Sie die alte Datei um

Öffnen Sie die Seite „Dateimanager“ in cPanel und wechseln Sie in das Stammverzeichnis von WordPress. Bei der Hauptdomain ist dies „public_html“, bei den übrigen Domains finden Sie es auf der Seite „Domains“ unter „Dokumentenstammverzeichnis“ (Was ist das Stammverzeichnis meiner Website?).
Sollten Sie die Datei „.htaccess“ nicht sehen, aktivieren Sie bitte die Anzeige versteckter Dateien.
Wählen Sie die Datei aus, klicken Sie auf die Schaltfläche „Umbenennen“ und vergeben Sie einen Namen mit Datumsangabe, beispielsweise „.htaccess-2026-10-30.bak“.

Mit SSH gilt dasselbe:

cd ~/public_html
mv .htaccess .htaccess-$(date +%F).bak

Auf dem Webhosting-Konto können Sie dies über den Menüpunkt „Dateimanager“ oder per FTP vornehmen.

Öffnen Sie anschließend die Website. Wenn die Startseite und der Admin-Bereich geladen werden, lag der Fehler in der alten Datei. Die Unterseiten können in diesem Fall weiterhin einen 404-Fehler anzeigen, bis Sie die neue Datei erstellt haben.

2. Erstellen Sie eine neue Datei

Am einfachsten geht dies über das Admin-Panel: Gehen Sie auf die Seite „Einstellungen“ › „Direktlinks“ und klicken Sie, ohne Änderungen vorzunehmen, auf die Schaltfläche „Änderungen speichern“. WordPress erstellt daraufhin die Datei „.htaccess“ mit Ihrem eigenen Block. Dies geschieht nur, wenn Sie nicht die „Einfache Struktur“ verwenden; in diesem Fall wird die Datei nicht benötigt.

Sie können diese Datei auch manuell erstellen, falls der Admin-Bereich nicht erreichbar ist. Erstellen Sie im Dateimanager über die Schaltfläche „Datei“ eine Datei mit dem exakten Namen „.htaccess“, öffnen Sie diese über die Schaltfläche „Bearbeiten“ und fügen Sie den Standardinhalt von WordPress ein:

# 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

Befindet sich WordPress in einem Unterverzeichnis (z. B. pelda.hu/blog), geben Sie in die Zeile „RewriteBase /“ den Eintrag „RewriteBase /blog/“ ein und in die letzte Zeile „RewriteRule“ den Eintrag „/blog/index.php“.

Mit WP-CLI lässt sich die Datei auch ohne Admin-Oberfläche neu generieren, doch der Befehl „wp rewrite flush --hard“ gibt lediglich folgende Warnung aus: „Regenerating a .htaccess file requires special configuration“ und erstellt die Datei nicht. Dazu muss vorübergehend eine Datei namens „wp-cli.yml“ im WordPress-Verzeichnis abgelegt werden:

printf 'apache_modules:\n  - mod_rewrite\n' > wp-cli.yml
wp rewrite flush --hard
rm wp-cli.yml

Bei der Änderung der Struktur über WP-CLI führt der Befehl „wp rewrite structure“ auf den aWh-cPanel-Servern aufgrund der Deaktivierung von „proc_open“ zu einem Fehler, die Einstellung wird jedoch gespeichert; über diesen Fehler wird im Artikel zur Verwendung von WP-CLI berichtet.

3. Überprüfen Sie die Website

Öffnen Sie die Startseite, einen Beitrag, eine Seite und den Admin-Bereich. Wenn der Fehler behoben ist, können Sie die Regeln wiederherstellen. Falls nicht, war die alte Datei nicht schuld: Benennen Sie sie wieder um und suchen Sie weiter (siehe Ende des Artikels).

4. Setzen Sie die erforderlichen Regeln wieder ein

Öffnen Sie die Datei „.bak“ und kopieren Sie nur die Teile, die Sie benötigen – jeweils einen Abschnitt nach dem anderen –, und laden Sie die Website nach jedem Schritt neu. Fügen Sie die Blöcke vor der Zeile „# BEGIN WordPress“ ein, da WordPress seinen eigenen Block überschreiben könnte.

Der PHP-Block in cPanel: Kopieren Sie den Abschnitt zwischen „# BEGIN cPanel-generated php ini directives“ und „# END cPanel-generated php ini directives“ einschließlich der beiden Markierungszeilen zurück.
Weiterleitungen: Kopieren Sie die Zeilen zurück oder fügen Sie sie auf der Seite „Weiterleitungen“ erneut ein.
Die eigene Regel lautet: Wenn der Fehler nach einer Zeile erneut auftritt, ist dies die fehlerhafte Zeile.
Regeln für Plugins: Kopieren Sie diese nicht manuell. Deaktivieren Sie das betreffende Plugin und aktivieren Sie es anschließend wieder oder speichern Sie die Einstellungen erneut, damit der entsprechende Block neu generiert wird. Tritt der Fehler nach der Aktivierung eines Plugins erneut auf, wird er durch dieses Plugin verursacht. Für die Wordfence-Firewall müssen Sie den Assistenten erneut ausführen.

Löschen Sie abschließend die Datei „.bak“ oder laden Sie sie herunter, da sie nicht in dem über das Internet zugänglichen Ordner verbleiben muss.

Wiederherstellung einer alten Datei

Sollten Sie die alte Datei dennoch benötigen, benennen Sie die neue Datei um (beispielsweise in „.htaccess-uj.bak“) und benennen Sie die mit dem Datum versehene Datei wieder in „.htaccess“ um.

Falls die Wiederherstellung nicht geholfen hat

Sehen Sie sich das Fehlerprotokoll an: die Seite „Fehler“ in der Gruppe „cPanel-Anleitung“ oder die Datei „~/logs/php.error.log“.
Lesen Sie die Artikel zum Fehler 500, zum weißen Bildschirm und zur PHP-Speichergrenze.
Aktivieren Sie den Debug-Modus.

Die allgemeinen Bearbeitungsregeln für diese Datei werden im Artikel über die .htaccess-Datei erläutert, die Beispiele für Weiterleitungen finden Sie in unserem Blogbeitrag über .htaccess-Weiterleitungen.