Die .htaccess in WordPress verstehen: Aufbau, Beispiele und sichere Snippets

Die .htaccess ist eine der wenigen Dateien in WordPress, vor denen viele echten Respekt haben. Zu Recht, denn ein falsches Zeichen darin legt die komplette Website lahm. Gleichzeitig ist sie unglaublich nützlich, wenn du weißt, was du tust: Weiterleitungen, Zugriffsschutz, Performance-Header, alles läuft über diese eine unscheinbare Textdatei.

In diesem Beitrag erkläre ich dir, was die .htaccess in WordPress macht, wie ihr Standardinhalt zu lesen ist, welche Snippets sich in der Praxis wirklich lohnen und was du besser nicht hineinschreibst. Und weil das früher oder später passiert: am Ende steht, wie du einen Fehler 500 wieder loswirst.

Was die .htaccess überhaupt ist

Die .htaccess ist eine Konfigurationsdatei für den Apache-Webserver. Sie liegt im Hauptverzeichnis deiner WordPress-Installation und wird bei jedem einzelnen Seitenaufruf gelesen. Der Punkt am Anfang des Namens macht sie unter Linux zu einer versteckten Datei, weshalb du in deinem FTP-Programm oft erst die Anzeige versteckter Dateien aktivieren musst, um sie überhaupt zu sehen.

Zwei Dinge solltest du vorab wissen. Erstens: Nicht jeder Server nutzt sie. Wenn dein Hoster nginx einsetzt, wird die Datei schlicht ignoriert, und die entsprechenden Regeln müssen anders hinterlegt werden. Zweitens: Sie wirkt sofort. Es gibt kein Speichern und kein Bestätigen, die nächste Anfrage arbeitet bereits mit deiner neuen Version. Deshalb gilt hier mehr als überall sonst: vorher eine Kopie ziehen.

Der Standardinhalt, den WordPress selbst schreibt

Wenn du in den Einstellungen schöne Permalinks aktivierst, legt WordPress diesen Block automatisch an:

# 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

Übersetzt heißt das: Wenn die angefragte Adresse keiner echten Datei und keinem echten Verzeichnis entspricht, schick die Anfrage an die index.php und lass WordPress entscheiden, was ausgeliefert wird. Genau deshalb funktionieren Adressen wie /blog/wordpress-htaccess/, obwohl es diesen Ordner auf dem Server gar nicht gibt.

Ganz wichtig: Alles zwischen # BEGIN WordPress und # END WordPress gehört WordPress. Diesen Bereich schreibt das System bei Bedarf neu und überschreibt dabei deine Änderungen. Eigene Regeln kommen deshalb immer oberhalb des BEGIN-Blocks oder unterhalb des END-Blocks.

Nützliche Snippets für deine .htaccess

Weiterleitung auf HTTPS erzwingen

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Damit landet jeder Besucher auf der verschlüsselten Variante deiner Seite. Der Statuscode 301 sagt Suchmaschinen, dass die Weiterleitung dauerhaft ist, und gibt die Rankings an die neue Adresse weiter. Viele Hoster bieten dieselbe Funktion inzwischen als Schalter im Kundenmenü an, dann brauchst du das Snippet nicht.

Einzelne Seite dauerhaft umleiten

Redirect 301 /alte-seite/ https://deine-domain.de/neue-seite/

Der Klassiker nach einem Relaunch. Wichtig ist, dass du wirklich jede alte Adresse abfängst, die Rankings oder Backlinks hatte. Für einzelne Umleitungen reicht dieses Snippet, bei vielen Weiterleitungen ist ein Plugin übersichtlicher. Welche Varianten es gibt und wann welche passt, habe ich im Beitrag Weiterleitungen in WordPress erstellen aufgeschrieben.

Browser-Caching für statische Dateien

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Damit sagst du dem Browser, wie lange er Bilder, CSS und JavaScript behalten darf, statt sie bei jedem Besuch neu zu laden. Für wiederkehrende Besucher ist das einer der spürbarsten Performance-Gewinne überhaupt. Achtung: Die meisten guten Cache-Plugins setzen diese Header bereits selbst. Prüf das vorher, sonst hast du die Regeln doppelt.

Sensible Dateien schützen

<files wp-config.php>
order allow,deny
deny from all
</files>

<files .htaccess>
order allow,deny
deny from all
</files>

Die wp-config.php enthält deine Datenbank-Zugangsdaten. Sie sollte über den Browser niemals erreichbar sein. Diese beiden Blöcke sind schnell gesetzt und gehören für mich auf jede WordPress-Installation. Weitere Maßnahmen in dieser Richtung findest du im Beitrag WordPress Sicherheit verbessern sowie in der offiziellen Hardening-Dokumentation.

xmlrpc.php sperren

<files xmlrpc.php>
order deny,allow
deny from all
</files>

Diese Schnittstelle ist ein beliebtes Ziel für automatisierte Angriffe. Die meisten Websites brauchen sie längst nicht mehr. Eine Ausnahme sind die offiziellen WordPress-Apps und einzelne ältere Plugins, die noch darüber kommunizieren. Sperr sie, prüf danach, ob alles läuft, und nimm die Regel im Zweifel wieder heraus.

Was du besser nicht in die .htaccess schreibst

Im Netz kursieren lange Sammlungen mit fünfzig Zeilen, die angeblich jede Website braucht. Davon würde ich abraten, und zwar aus drei Gründen.

Copy-Paste ohne Verständnis. Jede Regel wird bei jedem Seitenaufruf ausgewertet. Regeln, die du nicht verstehst, kannst du im Fehlerfall auch nicht debuggen. Nimm nur auf, was du erklären könntest.

Doppelte Regeln. Sicherheits-Plugins und Cache-Plugins schreiben eigene Blöcke in die Datei. Wenn du dieselbe Sache zusätzlich manuell setzt, widersprechen sich die Anweisungen im schlechtesten Fall gegenseitig.

Zugriffssperren nach Land oder IP. Klingt verlockend, um Angriffe zu reduzieren, sperrt in der Praxis aber schnell echte Besucher oder Suchmaschinen aus. Solche Filter gehören eher in eine Firewall als in die .htaccess.

Fehler 500 nach einer Änderung: so kommst du zurück

Wenn nach dem Speichern plötzlich jede Seite einen internen Serverfehler zeigt, ist fast immer die .htaccess schuld. Die gute Nachricht: Das ist in zwei Minuten behoben, weil kein Datenverlust entsteht.

Verbinde dich per FTP, benenne die Datei in htaccess-alt um und lade die Seite neu. Wenn sie wieder erscheint, weißt du, dass die Ursache dort liegt. Danach loggst du dich in WordPress ein, gehst auf Einstellungen und dann Permalinks und klickst einmal auf Speichern, ohne etwas zu ändern. WordPress legt daraufhin eine frische, funktionierende .htaccess an. Deine eigenen Snippets fügst du anschließend einzeln wieder hinzu und prüfst nach jedem Schritt.

Falls die Website danach immer noch nicht läuft, liegt das Problem woanders. Dann hilft dir meine Anleitung zum kritischen Fehler in WordPress weiter.

Fazit

Die .htaccess ist kein Ort für Experimente, aber auch kein Grund zur Angst. Zieh vor jeder Änderung eine Kopie, schreib eigene Regeln außerhalb des WordPress-Blocks, nimm nur Snippets auf, die du verstehst, und prüfe nach jeder Änderung die Seite. Mit den fünf Blöcken aus diesem Beitrag deckst du das ab, was in der Praxis wirklich gebraucht wird. Wenn du bei Weiterleitungen nach einem Relaunch unsicher bist oder dir jemand über die Schulter schauen soll, schreib mir gern.