WordPress Standard-.htaccess-Datei: Code, Wiederherstellung

Die Standard-.htaccess-Datei von WordPress ist der kurze RewriteEngine-Block, den die Software in die .htaccess im Root deiner Website schreibt, damit Permalinks wie /2026/10/post-name/ funktionieren und keinen 404 liefern. Er 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

Diese Regeln stammen aus dem Code, mit dem WordPress den Block erzeugt, und sie entsprechen WordPress’ eigenem .htaccess-Leitfaden. Direkt nach # BEGIN WordPress schreibt WordPress außerdem drei Kommentarzeilen, die warnen, dass Änderungen zwischen den Markierungen überschrieben werden. An der Funktion der Regeln ändern sie nichts.

Bei einer Installation im Unterordner setzt WordPress den Pfad des Unterordners in RewriteBase und in die letzte Regel ein, zum Beispiel RewriteBase /blog/ und RewriteRule . /blog/index.php [L]. Multisite-Netzwerke verwenden einen anderen Block, und WordPress schreibt diese Datei für sie nicht automatisch.

Das Wichtigste zuerst

• WordPress erzeugt diesen Block auf Apache und LiteSpeed, wenn es Schreibzugriff hat und Pretty Permalinks aktiv sind. Es reicht, Einstellungen > Permalinks zu öffnen.
• Fehlt die Datei oder ist sie beschädigt, liefern Permalinks einen 404, während die Startseite weiter lädt, weil sie die Rewrite-Regeln nicht braucht.
• Alles, was du oder ein Plugin ergänzt, gehört oberhalb von # BEGIN WordPress, nie zwischen die Markierungen. WordPress ersetzt beim Aktualisieren der Datei alles dazwischen.

Was jede Zeile tut

RewriteEngine On schaltet Apaches mod_rewrite-Modul für dieses Verzeichnis ein; ohne diese Zeile sind die Rewrite-Regeln darunter wirkungslos.

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] lässt die URL unverändert (das bedeutet das -) und kopiert den Authorization-Header der Anfrage in eine Servervariable. WordPress liest diese Variable, um einen im Header gesendeten Benutzernamen und ein Passwort zu erhalten, etwa ein Anwendungspasswort.

RewriteBase / legt das Pfadpräfix fest, das Apache für umgeschriebene URLs verwendet. WordPress setzt es auf den Ort, an dem die Website liegt, eine Installation im Unterordner bekommt also RewriteBase /blog/.

RewriteRule ^index\.php$ - [L] ist eine Schutzregel: Ist die Anfrage bereits index.php, wird das Rewriting gestoppt und die Anfrage unverändert durchgelassen.

Die beiden RewriteCond-Zeilen sind die eigentliche Logik. %{REQUEST_FILENAME} !-f und !-d fragen: “Passt diese Anfrage NICHT zu einer echten Datei und NICHT zu einem echten Verzeichnis?” Beides muss zutreffen, damit die letzte Regel greift. Ein echtes Bild, eine CSS-Datei oder ein hochgeladenes PDF wird also direkt ausgeliefert und kommt nie mit dem WordPress-Routing in Kontakt.

RewriteRule . /index.php [L] lässt die Permalinks funktionieren. Alles, was die beiden Bedingungen erfüllt, geht an index.php, und WordPress entscheidet, welchen Beitrag, welche Seite oder welches Archiv die URL meint.

Wann WordPress diese Datei neu erzeugt und wann nicht

WordPress leert seine Rewrite-Regeln jedes Mal, wenn die Seite Einstellungen > Permalinks geladen wird. Das Öffnen reicht also, du musst nicht auf Änderungen speichern klicken. Fehlt die .htaccess, legt WordPress sie an, solange der Ordner beschreibbar ist und Pretty Permalinks aktiv sind. Existiert die Datei und ist beschreibbar, ersetzt WordPress den Block zwischen den Markierungen.

In diesen Fällen löst das das Problem nicht:

• Die Datei oder ihr Ordner ist nicht beschreibbar für den Benutzer, unter dem PHP läuft. Die Seite zeigt dann einen Fehler, dass deine .htaccess-Datei nicht beschreibbar ist, zusammen mit den Regeln zum Einfügen. Bei manchen Hostern läuft PHP unter einem anderen Systembenutzer als dem, dem deine FTP-Uploads gehören. Rechte, die im FTP-Programm korrekt aussehen, können WordPress also trotzdem blockieren.
• Du nutzt nginx. Der nginx-Leitfaden von WordPress sagt, dass nginx keine verzeichnisbezogene Konfigurationsdatei wie .htaccess hat und WordPress die Serverkonfiguration nicht ändern kann. Das entsprechende Routing ist eine try_files-Direktive in der Serverkonfiguration, die ein Administrator bearbeiten muss.
• AllowOverride steht auf None für das Verzeichnis deiner Website in der zentralen Apache-Konfiguration. Die Apache-Dokumentation sagt: “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” Auf Deutsch: .htaccess-Dateien werden vollständig ignoriert, solange du sie nicht ausdrücklich für ein Verzeichnis aktivierst. WordPress kann also eine perfekte Datei schreiben, und sie bewirkt trotzdem nichts. Rewrite-Regeln brauchen AllowOverride FileInfo (oder All), was unter Umständen dein Hoster ändern muss.
• Deine Permalinks stehen auf Einfach (Plain). Einfache URLs brauchen keine Rewrite-Regeln, deshalb legt WordPress die Datei dafür nicht an.

So stellst du sie von Hand wieder her

Zeigen Beiträge und Seiten 404, während die Startseite funktioniert, prüfst du zuerst, ob die .htaccess fehlt oder kaputt ist. Behebe es in zwei Schritten.

1. Erst die Ein-Klick-Lösung versuchen. Öffne im wp-admin Einstellungen > Permalinks und klicke auf Änderungen speichern, ohne etwas zu ändern. Kann WordPress die Datei schreiben, erzeugt das sie neu. Kann es das nicht, zeigt die Seite den Fehler und die Regeln, die du brauchst.

2. Hilft das nicht, lege die Datei von Hand an. Verbinde dich per FTP/SFTP oder über den Dateimanager deines Hosters und gehe in den Root-Ordner deiner Website, normalerweise der Ordner, der wp-admin enthält. Prüfe, ob .htaccess existiert. Es ist eine Datei mit Punkt am Anfang, manche Dateimanager blenden sie deshalb standardmäßig aus; schalte “versteckte Dateien anzeigen” ein.

• Fehlt sie, lege eine neue Datei mit exakt dem Namen .htaccess an (kein .txt, nichts vor dem Punkt).
• Füge die Regeln ein, die WordPress dir gezeigt hat, oder den Standard-Block vom Anfang dieser Anleitung. Bei einer Installation im Unterordner passt du RewriteBase und die letzte Regel an.
• Speichere und lade einen Beitrags-Permalink neu, um zu prüfen, ob es funktioniert.

Zeigt sich immer noch ein 404, wird die .htaccess womöglich ignoriert. Frag deinen Hoster nach AllowOverride, denn wenn es deaktiviert ist, ignoriert Apache auch eine korrekte Datei.

Eigene Regeln vs. der Block von WordPress

Ein Plugin oder eine manuelle Bearbeitung kann eigene Regeln ergänzen, etwa Redirects, Hotlink-Schutz oder Caching-Header. Halte sie außerhalb des WordPress-Blocks, und zwar darüber, damit sie vor seiner Auffangregel laufen:

# Regeln, die du oder ein Plugin ergänzt hast: OBERHALB der WordPress-Markierungen
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # Beispiel: Hotlink-Schutz, Caching-Regeln usw.
</FilesMatch>

# 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

Alles, was zwischen # BEGIN WordPress und # END WordPress steht, geht verloren, sobald WordPress die Datei das nächste Mal aktualisiert, und dafür reicht schon das Laden der Permalink-Seite. Zeilen vor und nach den Markierungen bleiben erhalten. Für Redirects speziell siehe WordPress .htaccess-Redirect-Regeln richtig gemacht, wo sie hingehören und wie man Schleifen vermeidet.

Ein 500 Internal Server Error direkt nach dem Bearbeiten der Datei deutet auf das hin, was du gerade geändert hast. Laut Apache-Dokumentation nennt das Fehlerprotokoll wahrscheinlich eine nicht erlaubte Direktive oder einen Syntaxfehler. Regeln aus einem alten Tutorial können das auslösen: Order ist auf Apache 2.4 ein ungültiger Befehl, solange mod_access_compat nicht geladen ist. Mach die Änderung rückgängig, damit die Website wieder läuft, und lies dann das Fehlerprotokoll.

Mehr als der Standard-Block

Der Standard-Block kümmert sich nur um das Permalink-Routing und den Authorization-Header. Willst du den Zugriff auf sensible Dateien absichern, etwa die PHP-Ausführung in /uploads blockieren oder direkte Anfragen an wp-config.php verweigern, sieh dir WordPress .htaccess-Sicherheitsregeln, die wirklich etwas bringen an. Liefern Permalinks aus einem anderen Grund einen 404, etwa wegen einer falschen Permalink-Struktur, einer Caching-Schicht mit veralteten Regeln oder eines Multisite-Konflikts in Unterverzeichnissen, geht WordPress-Permalinks funktionieren nicht die anderen Ursachen durch.

Häufig gestellte Fragen

Was ist die Standard-.htaccess-Datei von WordPress? Es ist der RewriteEngine-Block, den WordPress zwischen # BEGIN WordPress und # END WordPress in die .htaccess im Root-Ordner deiner Website schreibt. Er gibt den Authorization-Header an PHP weiter und schickt jede Anfrage, die keine echte Datei und kein echter Ordner ist, an index.php.

Wie lautet der genaue Standard-.htaccess-Code von WordPress? RewriteEngine On, eine Regel, die den Authorization-Header an PHP weitergibt, RewriteBase /, eine Durchlassregel für index.php, zwei Bedingungen, die prüfen, dass die Anfrage keine echte Datei und kein echter Ordner ist, und eine letzte Regel, die alles andere an index.php schickt. Der vollständige Block steht am Anfang dieser Anleitung.

Warum zeigen alle meine Beiträge 404 außer der Startseite? Eine fehlende oder beschädigte .htaccess auf Apache erzeugt dieses Muster. Der Server findet die Startseite ohne Rewrite-Regeln. Jeder andere Permalink braucht diese Regeln, um index.php zu erreichen. Ohne sie sucht Apache nach einer Datei, die es nicht gibt, und liefert einen 404.

Erzeugt WordPress die .htaccess automatisch neu? Ja, auf Apache oder LiteSpeed mit mod_rewrite, wenn Pretty Permalinks aktiv sind und WordPress dort schreiben kann. Es reicht, Einstellungen > Permalinks zu öffnen. Fehlt die Datei, muss der Ordner beschreibbar sein. Eine vorhandene Datei muss selbst beschreibbar sein. Sonst zeigt die Seite einen Fehler und die Regeln, die du von Hand einfügen musst.

Warum hat nginx keine WordPress-.htaccess-Datei? nginx hat keine verzeichnisbezogene Konfigurationsdatei wie Apaches .htaccess. Dasselbe Routing wird als try_files-Regel in der nginx-Serverkonfiguration geschrieben. Diese muss ein Administrator bearbeiten, weil WordPress sie nicht ändern kann.

Warum ist meine .htaccess nach dem Speichern der Permalinks kaputtgegangen? Prüfe, ob eine eigene Regel innerhalb der Markierungen # BEGIN WordPress und # END WordPress stand. WordPress ersetzt beim Aktualisieren der Datei alles dazwischen, die Regel geht also verloren. Eigene Regeln gehören über die Markierungen.

Quellen

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• WordPress-Quellcode: class-wp-rewrite.php, options-permalink.php, misc.php, load.php, user.php, vars.php
• Apache HTTP Server 2.4: .htaccess files, mod_rewrite, Upgrading to 2.4

---

Baue eine saubere, korrekte .htaccess mit dem Standard-Permalink-Block und den Sicherheits- oder Redirect-Regeln, die du wirklich brauchst, mit dem kostenlosen WordPress .htaccess-Generator.