.htaccess-Audit: warum die Site 500 liefert und welche Regeln nicht greifen
Ziehen Sie die Datei hierher — das Werkzeug findet BOM, tote Direktiven, Regeln mit hohem Risiko für einen Fehler 500 und Anzeichen fremder Eingriffe. Die Datei wird in Ihrem Browser gelesen und nirgendwohin gesendet.
Der Text wurde manuell eingefügt, daher wurde der Byte-Prüfblock übersprungen. Um BOM, CRLF und unsichtbare Zeichen zu sehen, ziehen Sie die Datei selbst hierher.
Eine saubere .htaccess heilt keinen Hack. Ist die Site kompromittiert, steckt der Schadcode in PHP, und .htaccess ist nur dessen Folge: Der Dropper schreibt die Datei binnen Minuten nach Ihrer Bereinigung wieder um. Die Reihenfolge ist umgekehrt — zuerst den ausführbaren Code finden, dann die Konfiguration in Ordnung bringen.
Hier erscheint die Quelldatei mit Zeilennummern.
Zeilen mit Funden sind mit ! markiert: rot für Fehler, bernsteinfarben für Warnungen. Unsichtbare und nicht druckbare Zeichen werden als Punkt · dargestellt — in der Datei selbst steht an ihrer Stelle nichts.
Die Bereinigung entfernt das BOM, stellt die Zeilenenden auf LF um, entfernt nicht druckbare Zeichen, ersetzt geschützte Leerzeichen durch normale und ergänzt am Ende einen Zeilenumbruch. Die Direktiven bleiben unverändert. Die Datei wird als htaccess-clean.txt gespeichert — benennen Sie sie vor dem Hochladen in .htaccess um.
# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<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
Genau das schreibt WordPress selbst. Eigene Regeln setzen Sie oberhalb der Zeile # BEGIN WordPress: alles zwischen den Markern wird jedes Mal überschrieben, wenn Sie die Permalink-Einstellungen speichern.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
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).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
</IfModule>
# END WordPress
Für ein Multisite mit Subdomains ist der Block derselbe, nur ohne das Präfix ^([_0-9a-zA-Z-]+/)? in den letzten drei Regeln: RewriteRule ^(wp-(content|admin|includes).*) $1 [L] und RewriteRule ^(.*\.php)$ $1 [L].
Das Ersetzen des Blocks stellt die Permalinks nicht von selbst wieder her: Gehen Sie nach der Änderung zu Einstellungen → Permalinks und klicken Sie auf „Speichern“ — WordPress prüft den Block und schreibt ihn bei Bedarf neu.
Die Datei wird in Ihrem Browser gelesen — ihr Inhalt wird nirgendwohin gesendet und nirgends gespeichert.
Warum eine Datei und kein eingefügter Text
Die häufigste Ursache für einen 500er nach dem Bearbeiten von .htaccess ist im Text überhaupt nicht zu sehen. Es ist das BOM — drei unsichtbare Bytes am Dateianfang, die der Windows-Editor beim Speichern in UTF-8 hinzufügt. Apache hält sie für einen Teil der ersten Direktive und kann sie nicht parsen. Deshalb nimmt das Werkzeug genau die Datei entgegen: nur so lassen sich die Bytes lesen und das BOM, Windows-Zeilenumbrüche sowie unsichtbare Zeichen innerhalb der Zeilen erkennen. Die zweite Problemgruppe sind Direktiven, die nichts tun, aber funktionsfähig aussehen. mod_gzip_on ist Apache-1.3-Syntax; auf modernen Servern wird es stillschweigend ignoriert, während man jahrelang glaubt, die Komprimierung sei aktiv. Ein ExpiresByType-Block, der in eine Prüfung auf mod_headers.c statt mod_expires.c gepackt ist, greift ebenfalls nicht — und ohne Hinweis fällt das nicht auf. Drittens php_value und php_flag. Sie wirken nur, wenn PHP als Apache-Modul eingebunden ist. Auf modernen Hostings mit PHP-FPM wird eine solche Zeile entweder ignoriert oder liefert sofort einen 500er. Und getrennt zur Sicherheit: Wenn in der Datei Regeln stehen, die Besucher je nach Suchmaschine, aus der sie kommen, weiterleiten oder die Weiterleitung vor dem Administrator verbergen, ist das ein typisches Zeichen für eine Kompromittierung. Eine saubere .htaccess heilt den Hack jedoch nicht: fast immer liegt irgendwo in den Dateien ein PHP-Skript, das sie zurückschreibt.