WordPress Standard-.htaccess-Datei: Inhalt und 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/beitragsname/ aufgelöst werden statt auf 404 zu laufen. Er sieht so aus:

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

Das ist der genaue Block, übernommen aus WordPresss eigenem Leitfaden zum Apache HTTP Server und der Rewrite-Logik, die auf der HelpHub-Seite zu Pretty Permalinks dokumentiert ist. Ist deine RewriteBase nicht / — etwa weil WordPress in einem Unterordner installiert ist — matcht sie stattdessen diesen Pfad, und auch das ist korrekt und wird von WordPress selbst erzeugt.

Das Wichtigste zuerst

• WordPress erzeugt diesen Block automatisch, nur auf Apache und LiteSpeed, sobald die Datei beschreibbar ist und du Einstellungen > Permalinks speicherst.
• Fehlt die Datei oder ist sie beschädigt, liefern alle Permalinks außer der Startseite einen 404, weil nur die Startseite ohne die Rewrite-Regeln gefunden werden kann.
• Alles, was du oder ein Plugin ergänzt, muss oberhalb von # BEGIN WordPress stehen, nie innerhalb der Markierungen — WordPress überschreibt bei jedem Permalink-Speichern alles dazwischen.

Soll die Datei mit deinem echten Pfad und ein paar Extra-Regeln neu zusammengestellt werden? Der WordPress .htaccess-Generator baut dir eine korrekte direkt im Browser.

Was jede Zeile tut

RewriteEngine On schaltet Apaches mod_rewrite-Modul für dieses Verzeichnis ein; ohne diese Zeile ist alles darunter wirkungslos.

RewriteBase / sagt Apache, dass umgeschriebene Pfade relativ zum Website-Root sind. WordPress setzt das passend zum tatsächlichen Installationsort — eine Installation im Unterordner bekommt RewriteBase /blog/, nicht /.

RewriteRule ^index\.php$ - [L] ist eine wirkungslose 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: “Ist diese Anfrage KEINE echte Datei und KEIN echtes 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] ist das, was Permalinks funktionieren lässt: Alles, was die beiden Bedingungen überlebt hat — also keine echte Datei oder kein echter Ordner ist — wird an index.php geschickt, und WordPresss eigenes Routing (WP_Query, Rewrite-Tags) entscheidet, welchen Beitrag, welche Seite oder welches Archiv diese URL tatsächlich meint.

Wann WordPress diese Datei neu erzeugt — und wann nicht

WordPress versucht, die .htaccess selbst zu schreiben, sobald du Einstellungen > Permalinks öffnest und auf Änderungen speichern klickst, auch wenn sich auf dem Bildschirm nichts geändert hat. Dieses Speichern löst flush_rewrite_rules() aus, das versucht, die .htaccess zum Schreiben zu öffnen und den aktuellen Block zwischen den Markierungen einzusetzen.

Dieser Versuch schlägt still fehl — die Datei bleibt dann fehlend oder veraltet —, wenn:

• Die Datei oder ihr übergeordneter Ordner für den PHP-Benutzer nicht beschreibbar ist. Auf vielen Shared-Hosting-Umgebungen läuft PHP unter einem anderen Systembenutzer als dem, der Dateien per FTP hochgeladen hat, sodass Rechte, die im FTP-Client in Ordnung aussehen, WordPress trotzdem am Schreiben hindern.
• Du auf nginx läufst. .htaccess ist ausschließlich ein Apache- und LiteSpeed-Mechanismus (die Apache-Dokumentation zu AllowOverride erklärt, warum: nginx hat keine verzeichnisbezogene Konfigurationsdatei, die es pro Anfrage neu einliest). Das Äquivalent auf nginx ist eine try_files-Direktive im server-Block, die nur jemand mit Serverzugang bearbeiten kann — WordPress kann sie niemals für dich schreiben.
• AllowOverride auf None für das Verzeichnis deiner Website in der zentralen Apache-Konfiguration steht. Das ist die Einstellung, die einer .htaccess überhaupt erlaubt, etwas zu überschreiben; die Apache-Doku sagt es klar: Bei AllowOverride None “werden .htaccess-Dateien vollständig ignoriert” — WordPress kann eine perfekte Datei schreiben, und sie bleibt wirkungslos, bis diese Einstellung auf Server-Ebene geändert wird.
• Die Datei gelöscht wurde oder nie existierte und irgendetwas am Speichern keine Neuerzeugung ausgelöst hat — am häufigsten, weil die Permalink-Struktur schon dieselbe war und WordPress keine Änderung zum Durchschreiben gesehen hat.

So stellst du sie von Hand wieder her

404s bei Beiträgen und Seiten, während die Startseite weiterhin funktioniert, sind das typische Zeichen einer fehlenden oder kaputten .htaccess. Behebe es in zwei Schritten.

1. Erst die Ein-Klick-Lösung versuchen. Geh im wp-admin zu Einstellungen > Permalinks und klicke auf Änderungen speichern, ohne irgendetwas zu ändern. Ist die Datei beschreibbar, erzeugt das allein sie neu — fertig.

2. Hilft das nicht, lege die Datei von Hand an. Verbinde dich per FTP/SFTP oder dem Dateimanager deines Hosters, gehe in den Ordner, in dem WordPress installiert ist (der, der wp-config.php enthält), und prüfe, ob .htaccess überhaupt existiert — es ist eine versteckte Datei, manche Dateimanager blenden sie 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 den Standard-Block von oben ein und passe RewriteBase an, falls WordPress in einem Unterordner liegt.
• Speichern und einen Beitrags-Permalink neu laden, um zu bestätigen, dass es funktioniert.

Zeigt sich danach immer noch ein 404, hat sich die Ursache von “.htaccess fehlt” zu “.htaccess wird ignoriert” verschoben — frag deinen Hoster nach AllowOverride, denn eine korrekte Datei in einem Verzeichnis, in dem Apache angewiesen ist, sie zu ignorieren, verhält sich identisch zu gar keiner Datei.

Eigene Regeln vs. der Block von WordPress

Ein Plugin oder eine manuelle Bearbeitung kann eigene Regeln ergänzen — Redirects, Hotlink-Schutz, Caching-Header. Das ist ein eigener, getrennter Block von dem, den WordPress erzeugt, und beide sollten sich nie überschneiden:

# 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
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, wird beim nächsten Speichern der Permalink-Einstellungen kommentarlos gelöscht, weil WordPress diesen gesamten Abschnitt als sein eigenes Hoheitsgebiet behandelt und komplett neu schreibt. Das ist die häufigste Ursache für “meine eigene Regel ist verschwunden” — sie wurde nie absichtlich entfernt, sie stand nur in einem Block, den WordPress als seinen eigenen verwaltet. Für Redirects speziell siehe WordPress .htaccess-Redirect-Regeln richtig gemacht, wo sie hingehören und wie man Schleifen vermeidet.

Es ist auch die häufigste Ursache für einen plötzlichen 500 Internal Server Error direkt nach dem Bearbeiten der Datei: Eine aus einem Forenbeitrag für eine andere Apache-Version kopierte Regel (2.2er-Syntax Order/Deny gemischt mit 2.4er-Syntax Require) bricht das Parsen der gesamten Datei, inklusive des darunterliegenden WordPress-Blocks, und die ganze Website geht offline — nicht nur der Teil, den du bearbeitet hast.

Mehr als der Standard-Block

Der Standard-Block kümmert sich nur um das Permalink-Routing. Willst du zusätzlich den Zugriff auf sensible Dateien absichern oder die Handvoll .htaccess-Regeln ergänzen, die wirklich die Angriffsfläche reduzieren — PHP-Ausführung in /uploads blockieren, direkten Zugriff auf wp-config.php verweigern —, sieh dir WordPress .htaccess-Sicherheitsregeln, die wirklich etwas bringen an. Und wenn Permalinks aus einem anderen Grund 404 zeigen — falsche Permalink-Struktur, eine Caching-Schicht liefert veraltete Regeln aus, Multisite-Konflikte 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 schreibt, damit Permalinks an index.php aufgelöst werden statt auf 404 zu laufen.

Wie lautet der genaue Standard-.htaccess-Code von WordPress? RewriteEngine On, RewriteBase /, eine Durchlassregel für index.php, zwei Bedingungen, die prüfen, dass die Anfrage keine echte Datei oder kein echtes Verzeichnis ist, und eine abschließende 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? Die Startseite ist ohne jede Rewrite-Regel auffindbar; jeder andere Permalink braucht sie. Eine fehlende oder beschädigte .htaccess auf Apache erzeugt genau dieses Muster.

Erzeugt WordPress die .htaccess automatisch neu? Nur wenn die Datei beschreibbar ist — erneutes Speichern von Einstellungen > Permalinks löst das aus. Ist die Datei nicht beschreibbar, fehlt auf einem Hoster, der sie nicht automatisch erzeugt, oder ist AllowOverride deaktiviert, kann WordPress das nicht für dich beheben und du musst die Datei von Hand anlegen oder korrigieren.

Warum hat nginx keine WordPress-.htaccess-Datei? .htaccess funktioniert nur auf Apache und LiteSpeed. nginx hat keine verzeichnisbezogene Konfigurationsdatei und ignoriert .htaccess komplett; dasselbe Routing wird als try_files-Regel im server-Block von nginx geschrieben.

Warum ist meine .htaccess nach dem Speichern der Permalinks kaputtgegangen? Eine eigene Regel wurde innerhalb der Markierungen # BEGIN WordPress / # END WordPress statt darüber platziert, und WordPress hat diesen gesamten Abschnitt beim nächsten Speichern der Permalinks überschrieben.

---

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