Nach einer Migration funktioniert die Startseite, aber jeder Beitrag endet mit 404. Eine URL der Form /?p=123öffnet denselben Beitrag weiterhin. Dieses Muster spricht dafür, dass WordPress läuft, die Umschreibung sprechender Permalinks jedoch fehlt oder beschädigt ist.
Die Standard-.htaccess neu zu erstellen bedeutet nicht, die gesamte Datei durch ein Beispiel aus dem Internet zu ersetzen. Wiederhergestellt wird nur der WordPress-eigene Rewrite-Block, passend zur aktuellen Installation.
Was neu erzeugt wird
WordPress schreibt auf Apache-kompatiblen Servern einen markierten Rewrite-Block in die .htaccess. Dieser leitet Anfragen, die weder vorhandene Dateien noch Verzeichnisse betreffen, an den Front Controller index.phpweiter. WordPress löst dort den Permalink auf.
Regeln des Hosters, Sicherheitsdirektiven und eigene Redirects außerhalb der WordPress-Marken werden durch das Speichern der Permalinks nicht rekonstruiert. Sie müssen vor jeder Neuerstellung gesichert und getrennt beurteilt werden.
Typischer Migrationsfehler
Eine Website wurde aus dem Webroot in ein Unterverzeichnis verschoben. Der alte WordPress-Block enthält noch die frühere Rewrite-Basis. Das Team kopiert zunächst die vollständige Datei, trennt eigene Abschnitte ab und lässt WordPress über die Permalink-Einstellungen einen neuen Block erzeugen. Die Ausgabe passt nun zum Installationspfad.
Erst nachdem Beiträge, Taxonomien, REST-API, Adminbereich, statische Dateien und eine echte 404-Seite korrekt reagieren, werden benötigte eigene Abschnitte einzeln wieder ergänzt und jeweils erneut getestet.
Wann die Neuerstellung hilft
Sie ist sinnvoll, wenn der WordPress-Block fehlt, beschädigt ist oder nicht mehr zur Permalink-Struktur beziehungsweise zum Installationspfad passt. Sie löst keine DNS-, TLS- oder Proxyfehler und aktiviert weder mod_rewritenoch serverseitig gesperrte Funktionen.
Nginx verwendet keine .htaccess. Bei Multisite und Unterordnerinstallationen gelten andere Regeln als bei einer Einzelinstallation im Webroot. Verwenden Sie daher die Ausgabe der aktuellen WordPress-Installation, nicht einen beliebigen Standardblock.
Schrittweise Wiederherstellung
- Ermitteln Sie Webserver, Document Root und WordPress-Verzeichnis.
- Sichern Sie die vollständige aktuelle
.htaccessaußerhalb des Webroots. - Markieren Sie Hoster-, Sicherheits- und eigene Bereiche.
- Speichern Sie die bestehende Permalink-Struktur einmal im WordPress-Dashboard.
- Prüfen Sie, ob der neue WordPress-Block tatsächlich geschrieben wurde.
- Testen Sie Kernrouten, bevor zusätzliche Abschnitte einzeln zurückkehren.
Technische Prüfung
Vergleichen Sie Rewrite-Basis und Ziel mit dem Bereitstellungspfad. Prüfen Sie AllowOverride, das Rewrite-Modul, verschachtelte .htaccess-Dateien und übergeordnete Regeln. Bei Schreibproblemen kann WordPress den korrekten Block anzeigen, ohne ihn in die Datei übernehmen zu können.
Eine sinnvolle Testmatrix umfasst mehrere Beitrags- und Archiv-URLs, Pagination, Feed, REST, /wp-admin/, statische Datei, Query-Permalink und echte 404. Notieren Sie jeweils den ersten abweichenden Status und lesen Sie bei HTTP 500 das Serverfehlerprotokoll.
Risiken, Backup und Rollback
Das vollständige Überschreiben der Datei kann Hoster- oder Sicherheitsregeln entfernen. Zu weit geöffnete Dateirechte sind keine dauerhafte Lösung. Kopieren Sie auch keinen Block einer anderen Installation mit unbekannter Architektur.
Wenn die neue Datei HTTP 500, 403 oder unerwartete Redirects auslöst, stellen Sie über den unabhängigen Dateizugang die gesicherte Fassung wieder her. Ergänzen Sie anschließend nur den minimalen WordPress-Block und untersuchen weitere Abschnitte einzeln.
So unterstützt AIOWS:
AIOWS Htaccess Editor
AIOWS Htaccess Editor ermöglicht in unterstützten Umgebungen die kontrollierte Bearbeitung der aktiven .htaccessund erstellt vor dem Speichern eine Sicherung. Beim Wiederherstellen des WordPress-Blocks bleibt dadurch die vorherige Fassung als direkter Rückweg verfügbar.
Prüfen Sie vorab, ob der Editor die tatsächlich wirksame Datei im richtigen Installationsverzeichnis zeigt. Bewahren Sie zusätzlich eine externe Kopie auf und halten Sie einen vom WordPress-Adminbereich unabhängigen Dateizugang bereit. Nach dem Speichern testen Sie Permalinks, REST, Adminbereich, statische Dateien und 404-Antworten.
Der Editor kann keine fehlenden Servermodule aktivieren und rekonstruiert keine unbekannten Hoster- oder Pluginregeln. Eigene Abschnitte werden nicht gesammelt zurückkopiert, sondern nach bestandener Kernprüfung einzeln ergänzt. Scheitert die Änderung, stellen Sie die letzte funktionierende Datei wieder her.
Passende Artikel
- Die WordPress-.htaccess verstehen und sicher bearbeiten
- WordPress-Fehler 500 nach einer .htaccess-Änderung beheben
- WordPress-Permalinks liefern wegen der .htaccess einen 404-Fehler
Fazit
Stellen Sie nur den WordPress-eigenen Rewrite-Block für die aktuelle Installation wieder her. Bewahren Sie die Originaldatei und fremde Abschnitte getrennt auf und ergänzen Sie Zusatzregeln erst nach einer bestandenen Routenprüfung.
