Die .htaccess-Datei steuert auf Apache-Webservern unter anderem Weiterleitungen, WordPress-Permalinks, Zugriffsschutz und Browser-Caching. Eine universell „perfekte“ Datei gibt es jedoch nicht: Welche Regeln funktionieren, hängt vom Hosting, den aktivierten Apache-Modulen und der WordPress-Konfiguration ab.

Wichtig: Erstellen Sie vor jeder Änderung eine Sicherung der vorhandenen .htaccess. Schon ein einzelner Syntaxfehler kann einen HTTP-500-Fehler verursachen. Testen Sie Änderungen deshalb einzeln und halten Sie einen FTP-, SFTP- oder Hosting-Zugang bereit, über den Sie die Datei zurücksetzen können.

Wann eine .htaccess-Datei verwendet wird

.htaccess gilt für Apache und kompatible Serverkonfigurationen. Nginx verwendet keine .htaccess-Dateien; dort gehören entsprechende Regeln in die Serverkonfiguration. Wer den Apache-Server selbst verwaltet, sollte dauerhafte Regeln möglichst direkt in der Hauptkonfiguration hinterlegen. Das ist übersichtlicher und vermeidet die zusätzlichen Dateiprüfungen bei jeder Anfrage.

WordPress-Standardregeln für Permalinks

WordPress erzeugt den benötigten Rewrite-Block normalerweise automatisch, sobald die Permalink-Einstellungen gespeichert werden. Eine typische Installation im Webroot verwendet:

# 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

Bearbeiten Sie den Bereich zwischen # BEGIN WordPress und # END WordPress nicht manuell. WordPress oder ein Plugin kann diesen Block neu schreiben. Eigene Regeln gehören außerhalb der Markierungen.

HTTPS und bevorzugte Domain erzwingen

Weiterleitungen sollten möglichst schon beim Hosting oder Reverse Proxy eingerichtet werden. Falls dies nicht möglich ist, kann Apache auf HTTPS und eine einheitliche Domain umleiten. Ersetzen Sie example.com durch Ihre Domain:

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www.example.com$ [NC]
RewriteRule ^ https://www.example.com%{REQUEST_URI} [R=301,L]
</IfModule>

Bei Cloudflare, Load-Balancern oder anderen Proxys kann %{HTTPS} trotz einer externen HTTPS-Verbindung „off“ melden. Verwenden Sie in diesem Fall die vom Anbieter dokumentierte Proxy-Konfiguration, sonst kann eine Weiterleitungsschleife entstehen.

Zugriff auf sensible Dateien sperren

Die folgenden Apache-2.4-Regeln blockieren direkte Webzugriffe auf die WordPress-Konfiguration und auf Dateien, die häufig versehentlich hochgeladen werden:

<Files "wp-config.php">
Require all denied
</Files>

<FilesMatch "(^.|.bak$|.sql$|.log$|.ini$)">
Require all denied
</FilesMatch>

Diese Regeln ersetzen keine korrekten Dateirechte und kein sauberes Backup-Konzept. Sensible Sicherungsdateien sollten gar nicht erst im öffentlich erreichbaren Webverzeichnis liegen.

Verzeichnisauflistung deaktivieren

Falls der Server Verzeichnisinhalte ohne Indexdatei auflistet, lässt sich dies deaktivieren:

Options -Indexes

Browser-Caching mit Bedacht konfigurieren

Für versionierte statische Dateien können längere Cache-Zeiten sinnvoll sein. Viele Performance- oder Cache-Plugins verwalten diese Regeln bereits. Doppelte oder widersprüchliche Einstellungen sollten vermieden werden.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "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>

HTML-Seiten sollten nicht pauschal ein Jahr zwischengespeichert werden. Bei dynamischen WordPress-Seiten übernimmt dies besser eine abgestimmte Cache-Lösung, die angemeldete Benutzer, Warenkörbe und personalisierte Inhalte korrekt ausnimmt.

Sicherheitsheader: nicht blind kopieren

Header wie X-Content-Type-Options, Referrer-Policy oder Content-Security-Policy können die Sicherheit verbessern. Eine Content Security Policy muss jedoch auf die tatsächlich geladenen Skripte, Schriften, Bilder und Dienste abgestimmt werden. Eine fremde CSP ungeprüft zu übernehmen kann Formulare, Zahlungsanbieter, Videos oder den WordPress-Editor blockieren.

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>

Strict-Transport-Security sollte erst aktiviert werden, wenn die gesamte Domain einschließlich aller benötigten Subdomains dauerhaft und fehlerfrei über HTTPS erreichbar ist.

Regeln sicher testen

  1. Vorhandene .htaccess lokal sichern.
  2. Nur einen Regelblock auf einmal ergänzen.
  3. Startseite, Unterseiten, Anmeldung, REST-API, Formulare und Medien testen.
  4. Weiterleitungen mit einem privaten Browserfenster und einem HTTP-Header-Prüftool kontrollieren.
  5. Bei einem HTTP-500-Fehler die letzte Änderung sofort zurücknehmen und das Serverprotokoll prüfen.

Die beste .htaccess ist nicht die längste, sondern die kleinste nachvollziehbare Konfiguration, die zum eigenen Server und zur Website passt.