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.
Erscheint direkt nach einer .htaccess-Änderung HTTP 500, stellen Sie zuerst die letzte funktionierende Datei wieder her. Danach führt das Serverfehlerprotokoll zur fehlerhaften Direktive oder zum fehlenden Modul.
Die Meldung „.htaccess nicht beschreibbar“ rechtfertigt keine 777-Rechte. Prüfen Sie aktive Datei, PHP-Benutzer, Eigentümer, Verzeichnisrechte und Deployment-Modell und geben Sie nur dem vorgesehenen Prozess Schreibzugriff.