Die Startseite und wp-adminsind erreichbar, auch index.php?p=42öffnet den gewünschten Beitrag. Der sprechende Permalink endet dagegen mit einem 404-Fehler. Dieses Muster zeigt meist, dass der Inhalt vorhanden ist, Apache die Anfrage aber nicht korrekt an WordPress übergibt.
Im Folgenden prüfen Sie, ob die richtige .htaccessausgewertet wird, ob Apache Umschreibungen zulässt und ob der WordPress-Regelblock zur tatsächlichen Installation passt.
Inhaltsverzeichnis
Was hinter dem Fehler steckt
WordPress nutzt bei Apache mod_rewrite, um virtuelle Pfade an index.phpzu übergeben. Vorhandene Dateien und Verzeichnisse werden dabei normalerweise ausgenommen. Fehlt dieser Regelblock, liegt er im falschen Verzeichnis oder darf Apache ihn wegen der Serverkonfiguration nicht anwenden, beantwortet der Webserver den Permalink selbst mit 404.
Eine von WordPress gestaltete 404-Seite bedeutet hingegen, dass die Anfrage WordPress erreicht hat, dort aber keinem Inhalt zugeordnet werden konnte. Diese Unterscheidung bestimmt, ob Sie die Serverregeln oder die Inhalts- und Slug-Zuordnung untersuchen müssen.
Ein typischer Fall nach einem Umzug
Eine Website wird aus dem Webroot in das Unterverzeichnis /blogverschoben. Die alte .htaccessbleibt im bisherigen Verzeichnis, während die neue Installation einen Regelblock mit unpassender Basis enthält. Direkte Query-URLs funktionieren, doch Beiträge, Kategorien, Feeds und REST-Routen liefern eine Server-404-Seite.
In diesem Fall hilft es nicht, den Cache wiederholt zu leeren. Entscheidend ist, welches Document Root der aktive Virtual Host verwendet, wo WordPress tatsächlich liegt und welche .htaccessApache für die Anfrage einliest.
Warum die Unterscheidung wichtig ist
Ein pauschal eingefügter Catch-all kann statische Dateien, das Backend oder eine zweite Anwendung im selben Verzeichnis erfassen. Umgekehrt repariert das erneute Speichern der Permalinks keine Nginx-Konfiguration und keine Apache-Einstellung, die .htaccess-Overrides grundsätzlich verbietet.
Die funktionierende Query-URL ist ein wertvoller Kontrolltest: Sie belegt, dass Beitrag und WordPress-Anwendung erreichbar sind. Der Vergleich mit derselben Ressource als sprechende URL grenzt den Fehler auf das Routing ein.
Der einfache Diagnoseweg
- Öffnen Sie denselben Beitrag einmal als Query-URL und einmal über seinen Permalink.
- Prüfen Sie unter Einstellungen → Permalinks, welches Muster aktiv ist, und speichern Sie es einmal neu.
- Kontrollieren Sie, ob die erzeugte
.htaccessim Verzeichnis mitwp-admin,wp-contentundwp-includesliegt. - Vergleichen Sie den Regelblock mit der tatsächlichen Root- oder Unterverzeichnisinstallation.
- Testen Sie anschließend Beitrag, Seite, Kategorie, Feed, REST-Route, Mediendatei und einen absichtlich nicht vorhandenen Slug.
Kann WordPress die Datei nicht schreiben, kopieren Sie den angezeigten Regelblock erst nach einem Backup manuell. Bleibt das Problem bestehen, sollte der Hoster bestätigen, dass mod_rewriteaktiv ist und AllowOverridedie benötigten Anweisungen zulässt.
Die technische Prüfung
Vergleichen Sie öffentlichen Pfad, physisches Installationsverzeichnis, WordPress-Adresse und Website-Adresse. In einer Unterverzeichnisinstallation müssen RewriteBaseund Zielpfad dazu passen. Prüfen Sie außerdem, ob eine übergeordnete .htaccess, ein Alias oder eine Proxy-Regel die Anfrage bereits verändert.
Die Serverlogs zeigen, ob Apache eine Datei direkt sucht, intern mehrfach umleitet oder index.phperreicht. Eine temporäre, harmlose Markierung oder ein gezielter Zugriffstest kann bestätigen, dass die vermutete Datei überhaupt ausgewertet wird. Entfernen Sie solche Diagnoseanweisungen anschließend wieder.
Bei Nginx wird die WordPress-Weiterleitung in der Serverkonfiguration gepflegt; eine .htaccesshat dort keine Wirkung. Auch bei verwalteten Hosting-Plattformen kann die zuständige Rewrite-Ebene außerhalb des WordPress-Verzeichnisses liegen.
Risiken, Backup und Rollback
Sichern Sie die aktive Datei, bevor Sie Regeln ersetzen. Verwenden Sie keinen Regelblock aus einer beliebigen anderen Installation: Multisite, Unterverzeichnisse und zusätzliche Anwendungen benötigen eigene Varianten. Ein Syntaxfehler kann die gesamte Website mit Status 500 unzugänglich machen.
Falls die Änderung den Fehler verschärft, stellen Sie die gesicherte Datei über SFTP oder das Hosting-Panel wieder her. Löschen Sie Cache-Ebenen erst, nachdem der Origin-Server korrekt antwortet; sonst kann eine zwischengespeicherte 404-Antwort die erfolgreiche Reparatur verdecken.
Wie AIOWS unterstützt:
Wie AIOWS Htaccess Editor hilft
AIOWS Htaccess Editor stellt die .htaccessin unterstützten Umgebungen über eine verwaltete WordPress-Oberfläche bereit und legt vor dem Speichern automatisch eine Sicherung an. Damit lässt sich ein fehlender oder fehlerhafter WordPress-Regelblock kontrolliert korrigieren.
Vergleichen Sie zunächst die angezeigte Datei mit dem tatsächlichen Installationspfad. Ändern Sie nur den betroffenen Rewrite-Abschnitt und prüfen Sie danach sowohl einen funktionierenden Query-Aufruf als auch mehrere Permalinks. Der automatische Sicherungspunkt erleichtert das Zurücksetzen, ersetzt aber keinen unabhängigen Dateizugriff, falls WordPress nach einer fehlerhaften Regel nicht mehr erreichbar ist.
Das Modul kann keine serverweit deaktivierten Overrides freischalten und keine Nginx-Regel ändern. Wenn Apache die Datei nicht auswertet, muss die zuständige Server- oder Hosting-Konfiguration angepasst werden.
Passende AIOWS-Artikel
- Die WordPress-.htaccess verstehen
- Die WordPress-Standard-.htaccess neu erstellen
- Alten WordPress-Slug nach einer URL-Änderung weiterleiten
Fazit
Nutzen Sie die funktionierende Query-URL als Kontrolle und klären Sie, ob der 404-Fehler von Apache oder WordPress stammt. Erstellen Sie den Rewrite-Block für den tatsächlichen Installationspfad neu und akzeptieren Sie die Reparatur erst, wenn reguläre Permalinks, statische Dateien und echte 404-Seiten korrekt funktionieren.
