
WordPress-Sicherheitsheader per .htaccess einrichten
HSTS, CSP und weitere Sicherheitsheader können WordPress im Browser absichern. So führen Sie sie schrittweise ein, prüfen Abhängigkeiten und vermeiden Ausfälle durch zu strenge Regeln.
.htaccess ist eine einfache Textdatei im Stammverzeichnis der Website, die der Webserver bei jeder einzelnen Anfrage liest. Sie ist der Grund, warum Permalinks funktionieren, und sie ist der schnellste Weg, eine Website vollständig lahmzulegen — ein einzelnes falsches Zeichen erzeugt auf jeder Seite gleichzeitig einen 500er, das Dashboard eingeschlossen.
Aus dieser Kombination folgt, dass diese Anleitungen mit Orientierung beginnen und nicht mit Regeln. Was die Datei ist, was der von WordPress verwaltete Block darin bewirkt, wie der Server sie liest und wie sich vor jeder Änderung eine Kopie sichern lässt, die zurückgespielt werden kann.
Danach die Regeln, die sich lohnen. HTTPS erzwingen, zwischen www und ohne www entscheiden, Cache-Header für statische Dateien ergänzen und die Sicherheits-Header setzen, die Browsern sagen, wie streng sie mit den Seiten umgehen sollen.
Eine weitere Gruppe härtet einzelne Punkte ab: Verzeichnislisten unterbinden, die Ordnerinhalte preisgeben, wp-config.php dem Zugriff entziehen, XML-RPC blockieren, wenn es nicht gebraucht wird, und verhindern, dass fremde Websites die eigenen Bilder einbinden und dabei Traffic verursachen.
Der Rest ist Wiederherstellung, denn diese Datei zerlegt früher oder später jede und jeder. Ein 500er nach einer Änderung, Permalinks, die 404 liefern, weil der WordPress-Block fehlt, eine Datei, die der Server nicht beschreiben lässt.
Der Einsteigerartikel zur Datei lohnt sich auch für Erfahrene. Er beschreibt die Rücksicherungsgewohnheit, die alles Weitere hier gefahrlos ausprobierbar macht.

HSTS, CSP und weitere Sicherheitsheader können WordPress im Browser absichern. So führen Sie sie schrittweise ein, prüfen Abhängigkeiten und vermeiden Ausfälle durch zu strenge Regeln.

Sinnvolle Cache-Control- und Expires-Header beschleunigen statische WordPress-Dateien. So wählen Sie passende Laufzeiten, vermeiden veraltete Assets und trennen Browser-, CDN- und HTML-Caching.

Hotlink-Schutz kann unerwünschte Bildeinbettungen und Bandbreitenverbrauch reduzieren. So grenzen Sie die Apache-Regel ein, ohne Feeds, Social Previews oder legitime Partner zu blockieren.

Bevor Sie xmlrpc.php auf Serverebene sperren, prüfen Sie Jetpack, mobile Apps und andere legitime Clients. So blockieren Sie den Endpunkt gezielt und testen die Folgen.

Eine gezielte Apache-Regel blockiert HTTP-Zugriffe auf wp-config.php. Wirksamer Schutz umfasst außerdem restriktive Dateirechte, einen geeigneten Speicherort und das Entfernen öffentlicher Sicherungskopien.

Mit Options -Indexes verhindern Sie automatisch erzeugte Dateilisten in Apache-Verzeichnissen. So prüfen Sie den richtigen Geltungsbereich, ohne reguläre WordPress-Dateien zu sperren.

Wenn Query-URLs funktionieren, sprechende Permalinks aber 404 melden, liegt die Ursache häufig im Apache-Rewrite. So grenzen Sie den Fehler ein und stellen den passenden WordPress-Regelblock wieder her.

So richten Sie in Apache eine eindeutige Hauptdomain mit oder ohne WWW ein, ohne Redirect-Ketten, Zertifikatsfehler oder unterbrochene WordPress-Integrationen.

Eine HTTPS-Regel darf erst aktiv werden, wenn Zertifikat und Proxy-Erkennung stimmen. So vermeiden Sie Redirect-Schleifen hinter CDN oder Load Balancer und behandeln Mixed Content sowie HSTS getrennt.

Eine brauchbare .htaccess-Sicherung ist eindeutig beschriftet, außerhalb des Webroots gespeichert und über einen unabhängigen Zugang wiederherstellbar. So planen und testen Sie den Rollback vor der Änderung.