WordPress .htaccess 2026: Standard-Code, Sicherheit & Performance-Tweaks
Wer 2026 ernsthaft mit WordPress arbeitet, kommt an der .htaccess nicht vorbei. Sie steuert Permalinks, 301-Redirects, Login-Schutz, Caching-Header und ganze Sicherheits-Regelwerke. Ein einziger Tippfehler im File legt die Website lahm. Dieser Guide zeigt den kompletten Standard-Code 2026, die wichtigsten Sicherheits-Direktiven, alle Redirect-Patterns und die häufigsten Fehler mit konkreten Lösungen.
Was ist die .htaccess und warum braucht WordPress sie?
Die .htaccess ist eine versteckte Textdatei auf dem Webserver. Sie enthält Konfigurations-Direktiven für den Apache-Webserver. Im Gegensatz zur globalen Server-Konfiguration wirkt die .htaccess nur in dem Verzeichnis, in dem sie liegt, plus allen Unterverzeichnissen. Das macht sie für Shared-Hosting unverzichtbar, weil dort kein Zugriff auf die zentrale Apache-Config besteht.
WordPress nutzt die .htaccess vor allem für den Rewrite-Mechanismus. Eine URL wie /blog/wordpress-htaccess existiert auf dem Server nicht als physischer Pfad. Stattdessen leitet eine Rewrite-Regel die Anfrage intern auf die index.php um, die dann den passenden Beitrag aus der Datenbank holt. Ohne diese Rewrite-Logik wären nur hässliche URLs wie /?p=42 möglich.
Die .htaccess überschreibt die globale Apache-Config nur dann, wenn der Hoster AllowOverride All gesetzt hat. Manche günstigen Hoster blocken das aus Performance-Gründen. Im Zweifel beim Support nachfragen, ob Override aktiv ist. Sonst ignoriert der Server die Datei komplett.
Wo liegt die .htaccess und wie öffne ich sie?
Die WordPress-.htaccess liegt im Stammverzeichnis der Installation, auf derselben Ebene wie wp-config.php und wp-content. Bei den meisten Hostern heißt das Verzeichnis public_html, httpdocs oder www. Wer WordPress in einem Unterverzeichnis betreibt, findet die Datei dort.
Dateien mit führendem Punkt sind unter Linux und macOS standardmäßig versteckt. Im FTP-Client wie FileZilla muss die Option „versteckte Dateien anzeigen“ aktiviert sein (Menü Server, Erzwinge Anzeige versteckter Dateien). Im Plesk-Filemanager und in cPanel gibt es ähnliche Schalter. Wer die Datei nicht findet, hat oft nur diese Anzeige-Option vergessen.
FTP/SFTP: Mit FileZilla, Cyberduck oder WinSCP verbinden, versteckte Dateien einblenden, herunterladen, lokal mit VS Code oder Notepad++ bearbeiten, hochladen. Hosting-Filemanager: Plesk, cPanel und IONOS-Backend haben integrierte Editoren mit Syntax-Highlighting. SSH: ssh user@server, dann nano /var/www/html/.htaccess für direkte Bearbeitung. WP-Plugin: Yoast SEO und Rank Math bringen einen .htaccess-Editor im Backend mit, der vor Änderungen automatisch Backups anlegt.
Bei manchen Frischinstallationen existiert die .htaccess noch gar nicht. WordPress legt sie erst dann an, wenn unter Einstellungen, Permalinks ein Permalink-Schema ungleich „Einfach“ gespeichert wird. Falls das Datei-Anlegen scheitert (fehlende Schreibrechte), erstellt man die Datei manuell mit dem Standard-Block aus Abschnitt 3.
Der WordPress-Standard-Block 2026
Der offizielle WordPress-Standard-Block sieht 2026 unverändert wie folgt aus. Er gehört in jede WordPress-Site mit Apache und sauberen Permalinks. Wichtig: Eigene Regeln immer außerhalb der BEGIN/END-WordPress-Marker einfügen, sonst überschreibt WordPress sie bei nächster Permalink-Aktualisierung.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
Zeile für Zeile erklärt: IfModule mod_rewrite.c prüft, ob das Apache-Rewrite-Modul aktiv ist. RewriteEngine On schaltet das Umleiten an. RewriteBase / definiert das Basis-Verzeichnis als Domain-Root. Die erste RewriteRule sorgt dafür, dass direkte Aufrufe der index.php unverändert durchlaufen. Die beiden RewriteCond-Zeilen prüfen: existiert die angefragte URL als echte Datei (-f) oder als Verzeichnis (-d)? Wenn nicht, schickt die letzte RewriteRule die Anfrage an die index.php, die dann WordPress aufruft.
Bei WordPress-Multisite (Subdomain oder Subdirectory) ist der Standard-Block länger und enthält zusätzliche Rewrite-Regeln für die einzelnen Sub-Sites. Details in Abschnitt 8.
.htaccess für saubere Permalinks
Wer 2026 mit WordPress arbeitet, nutzt fast immer das Permalink-Schema Beitragsname (/%postname%/) oder eine Kategorie-Beitragsname-Kombination. Dafür ist die .htaccess zwingend nötig. Ohne den Rewrite-Block landen alle Anfragen außer der Startseite im 404.
Der bewährte Reset-Trick bei kaputten Permalinks: ins WP-Backend gehen, unter Einstellungen, Permalinks einmal auf „Änderungen speichern“ klicken, ohne etwas zu ändern. WordPress regeneriert daraufhin die .htaccess-Rewrite-Sektion. In 90 Prozent der Fälle laufen die Permalinks danach wieder.
Caching-Plugins wie WP-Rocket, W3 Total Cache und LiteSpeed Cache schreiben eigene Blöcke in die .htaccess. Die Reihenfolge ist kritisch: Cache-Regeln müssen vor dem WordPress-Standard-Block stehen, sonst greift der WP-Rewrite zuerst und der Cache wird umgangen. Bei Problemen Plugin deaktivieren, .htaccess prüfen, wieder aktivieren.
Sicherheits-Hardening per .htaccess
Die .htaccess ist 2026 immer noch eine der stärksten Hardening-Ebenen für WordPress, weil sie auf Server-Ebene wirkt — noch bevor PHP startet. Fünf Blöcke gehören in jede ernsthafte WordPress-Installation.
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
<Files wp-config.php>
Order Allow,Deny
Deny from all
</Files>
Options -Indexes
<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from 91.123.45.67
</Files>
Der xmlrpc-Block ist 2026 für 99 Prozent der Sites unkritisch, weil moderne Plugins die XML-RPC-Schnittstelle nicht mehr brauchen. Wer Jetpack oder die WordPress-App nutzt, lässt den Block weg oder erlaubt gezielt die nötigen IPs.
Beim wp-login-Schutz per IP-Whitelist aufpassen: die eigene IP ändert sich oft (Dynamic IP, mobiles Internet, VPN). Wer sich aussperrt, kommt nur noch per FTP an die .htaccess. Alternative: ein Plugin wie Limit Login Attempts Reloaded, das per PHP arbeitet und flexibler ist.
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www\.)?werbeagentur-landau\.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp|svg)$ – [F,NC,L]
Der Hotlink-Block 2026 erlaubt nur Bilder-Anfragen, die von der eigenen Domain kommen. Externe Seiten, die ein Bild per img src einbinden, bekommen einen 403. Spart Bandbreite und schützt Bildrechte.
Performance-Tweaks per .htaccess
Browser-Caching und Gzip-Compression sind 2026 die zwei schnellsten Hebel, um WordPress-Sites auf PageSpeed 90+ zu bringen. Beide laufen direkt in der .htaccess, ohne PHP oder Plugin. Wer ein Caching-Plugin nutzt, hat diese Regeln meist schon automatisch — wer ohne Plugin auskommt, fügt sie manuell hinzu.
<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“
ExpiresByType font/woff2 „access plus 1 year“
ExpiresByType text/html „access plus 1 hour“
</IfModule>
Die mod_expires-Direktiven setzen Expires– und Cache-Control: max-age-Header. Bilder, Fonts und Skripte bleiben so lange im Browser-Cache wie definiert — der Browser lädt sie beim zweiten Besuch nicht erneut vom Server. Effekt: zweite und alle weiteren Seitenaufrufe deutlich schneller, Server-Load sinkt.
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/xml
</IfModule>
Gzip komprimiert HTML, CSS und JavaScript vor der Auslieferung. Typische Einsparung: 60 bis 80 Prozent Datenvolumen. Auf modernen Hostern ist Brotli noch effizienter — wer Brotli-Support hat, ersetzt mod_deflate durch mod_brotli mit gleicher Syntax.
WordPress-Site ohne Performance-.htaccess: 2,8 Sekunden Largest Contentful Paint, PageSpeed-Score 67. Nach Einbau von mod_expires plus mod_deflate ohne weitere Optimierung: 1,4 Sekunden LCP, Score 88. Zeitaufwand für die Änderung: 5 Minuten. Bei werbeagentur-landau.com sind diese Regeln in jeder Auslieferung standardmäßig drin, PageSpeed liegt bei 92 bis 98 Punkten.
301-Redirects einrichten
301-Redirects sind das wichtigste SEO-Werkzeug bei URL-Änderungen. Sie sagen Suchmaschinen: „diese Seite ist dauerhaft umgezogen“. Rankings, Backlinks und Trust gehen auf die neue URL über. In der .htaccess gibt es zwei Wege — die einfache Redirect-Direktive und die mächtigere RewriteRule.
Redirect 301 /alte-seite /neue-seite
RedirectMatch 301 ^/blog-alt/(.*)$ /blog/$1
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]
RewriteCond %{REQUEST_URI} /+[^\.]+$
RewriteRule ^(.+[^/])$ %{REQUEST_URI}/ [R=301,L]
Wichtige Reihenfolge: https-Erzwingen kommt vor www-Redirect, sonst entsteht ein doppelter Redirect (erst Protokoll, dann Subdomain), der die Time-To-First-Byte unnötig erhöht. Saubere Lösung: beide Bedingungen in einer Regel kombinieren.
Bei wenigen Redirects ist die .htaccess die schnellste Lösung. Ab etwa 50 Regeln wird die Datei unübersichtlich. Plugins wie „Redirection“ oder „Rank Math Redirects“ speichern die Regeln in der Datenbank und bringen ein UI mit. SEO-Effekt identisch, Pflege deutlich angenehmer.
Multisite-spezifische .htaccess-Regeln
Bei WordPress-Multisite ist die .htaccess deutlich umfangreicher. WordPress unterscheidet zwischen Subdomain-Setup (shop.domain.de) und Subdirectory-Setup (domain.de/shop). Beide brauchen unterschiedliche Rewrite-Blöcke, die WordPress beim Aktivieren der Multisite automatisch vorschlägt.
RewriteEngine On
RewriteRule ^index\.php$ – [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^[_0-9a-zA-Z-]+/(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
Der Subdomain-Block ist kürzer, weil weniger Pfad-Mapping nötig ist. Beim Multisite-Setup gibt WordPress unter Netzwerk-Verwaltung, Einstellungen, Netzwerk einrichten den exakt passenden Block aus. Diesen 1:1 kopieren, nicht selbst basteln. Tippfehler legen die ganze Multisite gleichzeitig lahm.
Häufige .htaccess-Fehler und Lösungen
Die .htaccess ist die häufigste Fehlerquelle bei kaputten WordPress-Sites. Fünf Symptome decken 90 Prozent der Fälle ab.
Ursache: Syntaxfehler in der .htaccess, oft ein vergessenes
</IfModule> oder ein nicht installiertes Apache-Modul. Lösung: .htaccess komplett umbenennen in .htaccess-broken, Seite testen. Lädt die Startseite, ist das File die Ursache. Standard-Block neu einfügen, Regeln einzeln dazunehmen.Ursache: IP-Whitelist auf
wp-login.php sperrt die eigene aktuelle IP aus. Lösung: per FTP in die .htaccess, den Allow from-Block entfernen oder eigene neue IP eintragen. Bei dynamischen IPs besser per Plugin schützen.Ursache: oft kombiniert mit fehlerhaftem Plugin, kann aber auch von einer .htaccess kommen, die PHP-Handler falsch zuweist. Lösung: .htaccess umbenennen, Debug-Mode in wp-config.php aktivieren, Logs prüfen.
Ursache: Plugin oder Update hat den BEGIN/END-WordPress-Block beschädigt. Lösung: ins WP-Backend, Einstellungen, Permalinks, einmal speichern. WordPress schreibt den Block neu. Funktioniert das nicht, manuell aus dieser Anleitung übernehmen.
Ursache: Hoster nutzt Reverse-Proxy oder Cloudflare, leitet Anfragen intern bereits als http weiter. Lösung: statt
%{HTTPS} off die Bedingung %{HTTP:X-Forwarded-Proto} !https verwenden. Funktioniert hinter den meisten Reverse-Proxies sauber.Vor jeder .htaccess-Änderung das aktuelle File als .htaccess.bak sichern. Im Fehlerfall in 30 Sekunden wieder online. Wer ohne Backup arbeitet, sucht im Worst Case stundenlang nach dem Tippfehler.
Wann .htaccess nicht ausreicht
Die .htaccess ist eine Apache-Funktion. Wer auf Nginx hostet (Hetzner Cloud, viele Managed-Hoster ab 2024, Cloud-Plattformen wie DigitalOcean), hat keine .htaccess. Alle Regeln müssen stattdessen im Server-Block der Nginx-Konfiguration eingetragen werden, was Root-Zugriff voraussetzt.
Wer keinen Root-Zugriff hat (Shared-Nginx-Hosting), nutzt Cloudflare-Page-Rules als Alternative. Redirects, Cache-Header und Security-Regeln laufen dann auf der Cloudflare-Edge, noch vor dem eigentlichen Hoster. Funktional fast deckungsgleich, in vielen Fällen sogar schneller. Wer einen kompletten Migrations-Pfad von Apache auf Nginx braucht oder Cloudflare-Setup will, kann das Setup bei uns ab 70 Euro Stundensatz beauftragen.
Ihre Website ab 759 Euro
Festpreis, DSGVO-konform, PageSpeed 90+ und 12 Monate Support inklusive.
Häufige Fragen zur WordPress .htaccess
Fazit
Die WordPress-.htaccess ist 2026 immer noch das mächtigste Konfigurations-Tool für Apache-basierte Sites. Der Standard-Block sichert Permalinks, sauber gesetzte Sicherheits-Regeln schützen Login und Config-Dateien, mod_expires und mod_deflate katapultieren den PageSpeed-Score nach oben. Wer 301-Redirects beherrscht, behält bei jeder URL-Änderung die SEO-Rankings.
Drei Regeln gelten immer: vor jeder Änderung Backup anlegen, eigene Regeln außerhalb des BEGIN/END-WordPress-Blocks platzieren, nach Änderung sofort die Startseite und eine Unterseite prüfen. Wer auf Nginx hostet, ersetzt .htaccess durch Server-Block-Konfiguration oder Cloudflare-Page-Rules. Unser Team aus über 60 betreuten WordPress-Projekten in 2025 und 2026 setzt die hier gezeigten .htaccess-Patterns als Standard bei jedem neuen Auftrag ein. Beratung kostenlos unter +49 176 21 776099, Setup ab 70 Euro Stundensatz oder fertig im STARTER-Paket ab 759 Euro Festpreis.