Die Standard-.htaccess von WordPress: was drinsteht und was nicht
Fast jede WordPress-Installation hat eine .htaccess im Wurzelverzeichnis, und fast niemand weiß, was eigentlich drinstehen sollte.
Das ist ein Problem, sobald etwas kaputtgeht. Wer den Sollzustand nicht kennt, kann eine gewachsene Datei nicht aufräumen — und traut sich zu Recht nicht, etwas zu löschen.
Der Sollzustand#
Das ist alles, was WordPress selbst hineinschreibt:
`` # 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 ``
Zehn Zeilen. Sie tun eine Sache: Anfragen, für die es keine echte Datei und kein echtes Verzeichnis gibt, an index.php weiterreichen. Das ist der ganze Mechanismus hinter den sprechenden Adressen.
Zeile für Zeile:
RewriteEngine Onschaltet das Umschreiben ein.RewriteBase /legt fest, worauf sich relative Ziele beziehen. In einer Unterverzeichnis-Installation steht hier der Pfad.RewriteRule ^index\.php$ - [L]lässt direkte Aufrufe vonindex.phpin Ruhe.- Die beiden
RewriteCondprüfen: keine Datei (!-f), kein Verzeichnis (!-d). - Die letzte Regel schickt alles Übrige an WordPress.
Wichtig: Alles zwischen # BEGIN WordPress und # END WordPress gehört WordPress. Der Block wird beim Speichern der Permalink-Einstellungen überschrieben. Eigene Regeln gehören darüber oder darunter, sonst sind sie irgendwann weg.
Was nicht drinsteht — aber bei dir vermutlich steht#
Wenn deine Datei deutlich länger ist, stammt der Rest von Plugins. Die üblichen Verdächtigen:
| Was du siehst | Wer es war |
|---|---|
<IfModule mod_expires.c> mit ExpiresByType | ein Caching-Plugin |
mod_deflate oder mod_brotli | ein Caching- oder Performance-Plugin |
lange Blöcke mit RewriteCond %{HTTP_USER_AGENT} | ein Sicherheits-Plugin |
Regeln für webp | ein Bild-Plugin |
| Weiterleitungen einzelner Adressen | ein Redirect-Plugin |
Fast alle davon kennzeichnen ihren Bereich mit eigenen # BEGIN- und # END-Kommentaren. Das ist die Einladung zum Aufräumen: Deaktivierst du ein Plugin, bleibt sein Block oft stehen. Genau so sammelt sich über Jahre Konfiguration an, für die niemand mehr zuständig ist.
Wie du sie sicher zurücksetzt#
- Kopie ziehen.
.htaccessherunterladen und lokal wegsichern. Nicht in dasselbe Verzeichnis unter anderem Namen — Apache verarbeitet sie dort zwar nicht, aber die Datei ist dann über den Browser abrufbar. - Ersetzen durch die zehn Zeilen oben.
- In WordPress unter Einstellungen → Permalinks einmal speichern, ohne etwas zu ändern. Das schreibt den Block sauber neu.
- Prüfen: Startseite, ein Beitrag, eine Seite, das Kontaktformular, der Anmeldebereich.
Was danach fehlt, kam von einem Plugin — und dann kannst du entscheiden, ob du es zurückholst oder das Plugin gleich mit.
Wenn es die Datei gar nicht gibt#
Zwei mögliche Gründe.
Sie ist versteckt. Namen mit führendem Punkt blendet fast jeder Dateimanager standardmäßig aus. Im FTP-Programm die Anzeige versteckter Dateien einschalten.
Der Server ist kein Apache. Auf nginx gibt es keine .htaccess — Konfiguration liegt dort zentral und wird nicht pro Verzeichnis gelesen. Anleitungen, die dir eine .htaccess für nginx empfehlen, haben sich schlicht geirrt; die Datei liegt dann herum und tut nichts.
Ob dein Server Apache, nginx oder LiteSpeed ist, verrät oft schon die Antwort-Kopfzeile — der Tech-Stack-Check liest sie aus.
Rechte und Sichtbarkeit#
Die Datei sollte 644 haben: lesbar für den Server, beschreibbar nur für den Eigentümer. Mit 444 kann WordPress die Permalinks nicht mehr aktualisieren und meldet das auch. Mit 666 darf jeder Prozess auf dem Server hineinschreiben — das ist der Zustand, in dem eine kompromittierte Seite ihre Weiterleitungen unterbringt.
Wenn dich das interessiert, weil etwas nicht stimmt: Gehackte Website erkennen und WordPress-Sicherheitslücken beheben gehen darauf ein. Für einen Blick von außen gibt es den Security-Scan.