Nach einem Umzug von Staging nach Produktion funktionieren Startseite und wp-admin, doch jede Beitrags-URL endet auf der 404-Seite des Webservers. Das Speichern der Permalink-Einstellungen scheint kurz zu helfen; Anfragen an einen zweiten Server schlagen weiterhin fehl.
Dieses Muster spricht für ein Routingproblem, nicht für verschwundene Inhalte. Bevor Weiterleitungen ergänzt oder Permalinks immer wieder neu gespeichert werden, muss feststehen, welche Ebene die 404 erzeugt und ob alle Server denselben Document Root und dieselben Rewrite-Regeln verwenden.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rückweg
- Wie AIOWS unterstützt: AIOWS Weiterleitungs-Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was das Thema bedeutet
Ein Permalink-404 entsteht, wenn ein lesbarer WordPress-Pfad den Front Controller nicht erreicht oder WordPress die daraus gebildete Abfrage keinem Inhalt zuordnen kann. Ursachen reichen von Webserverregeln und Virtual Hosts über Multisite-Pfade bis zur Registrierung eigener Inhaltstypen, Endpunktkonflikten oder einem einzelnen fehlenden Slug.
Die 404-Seite des Servers ist ein anderer Befund als das 404-Template des Themes. Ebenso unterscheiden sich der Ausfall aller sprechenden URLs und ein einzelner nicht erreichbarer Beitrag. Eine Zielweiterleitung repariert kein defektes Anwendungsrouting.
Ein realistisches WordPress-Beispiel
Im Beispiel öffnet eine einfache Abfrage wie /?p=123den Beitrag, während /beispielbeitrag/scheitert. Statische Dateien und die Startseite funktionieren ebenfalls. Einer der Server im Load Balancer besitzt die richtige Front-Controller-Regel, der andere noch eine ältere Virtual-Host-Konfiguration.
Dauerhaft hilft nur, die aktive Rewrite-Konfiguration auf allen Knoten einheitlich bereitzustellen und kontrolliert neu zu laden. Anschließend kann WordPress seine Rewrite-Regeln einmal auf unterstütztem Weg aktualisieren; als regelmäßige Reparatur für Serverabweichungen taugt dieser Schritt nicht.
Warum es wichtig ist und wann es eingesetzt wird
Defekte Permalinks können nahezu alle öffentlichen Inhalte unzugänglich machen, obwohl die Verwaltung weiterhin normal aussieht. Eine saubere Diagnose verhindert zugleich, dass ein tatsächlich gelöschter Beitrag mit einem systemweiten Routingfehler verwechselt wird.
Prüfen Sie eine kleine Auswahl: Startseite, Beitrag, Seite, Archiv, einfache Query-URL, REST-Endpunkt und statische Datei. Statuscode und Gestaltung der 404 zeigen meist, ob die Anfrage bereits am Server endete oder WordPress erreicht hat.
Der einfache Weg für Einsteiger
- Sichern Sie die aktive Webserverkonfiguration und klären Sie den Wiederherstellungsweg.
- Kontrollieren Sie WordPress-Adresse, Website-Adresse und die gewählte Permalink-Struktur.
- Vergleichen Sie eine fehlerhafte sprechende URL mit ihrer einfachen Query-Variante und bestimmen Sie den Erzeuger der 404.
- Prüfen Sie auf jedem Server den aktiven Virtual Host, den Document Root und die Front-Controller-Regel für Apache oder Nginx.
- Aktualisieren Sie nach der Serverkorrektur die WordPress-Rewrite-Regeln einmal über eine unterstützte Funktion und testen Sie alle Beispielrouten erneut.
Der technische Weg
Bei Apache müssen der tatsächlich aktive Virtual Host und das für .htaccessgeltende AllowOverridestimmen. Bei Nginx ist die wirksame try_files-Regel entscheidend. In Clustern oder Containern werden Release und Konfiguration jedes Knotens verglichen.
Scheitern nur ein eigener Inhaltstyp, eine Taxonomie, ein Sprachpräfix oder ein Multisite-Pfad, prüfen Sie Registrierung und Ladezeitpunkt der Rewrite-Regeln. Endpunktkonflikte können eng begrenzt sein, obwohl gewöhnliche Beiträge funktionieren.
Risiken, häufige Fehler, Backup und Rückweg
Überschreiben Sie .htaccessnicht, ohne Hosting- und Sicherheitsdirektiven zu sichern. Breite Weiterleitungen verdecken den Fehler und können Schleifen oder Soft-404-Seiten erzeugen. Wiederholtes Speichern der Permalinks kann außerdem nur einen einzelnen Knoten vorübergehend korrigieren.
Stellen Sie den vorherigen Zustand wieder her, wenn Verwaltung, REST, Feeds oder statische Dateien beeinträchtigt werden, ein Reload fehlschlägt oder neue Schleifen entstehen. Der Test muss nach Cache-Ablauf und Dienstneustart auf jedem Knoten bestehen.
Wie AIOWS unterstützt:
AIOWS Weiterleitungs-Manager
Der AIOWS Weiterleitungs-Manager macht explizite WordPress-Weiterleitungen sichtbar und hilft damit, diese Ebene vom eigentlichen Permalink-Routing zu unterscheiden. Während der Diagnose lässt sich prüfen, ob eine Regel in WordPress beteiligt ist oder die 404 bereits von CDN beziehungsweise Webserver stammt.
Lassen Sie die Regeln unverändert, bis Server-Rewrite und WordPress-Permalink-Zustand geklärt sind. Eine verwaltete Weiterleitung ist nur dann angebracht, wenn eine konkrete alte URL dauerhaft zu einem erreichbaren, fachlich passenden Inhalt umgezogen ist.
Apache- oder Nginx-Regeln kann das Modul ebenso wenig reparieren wie unterschiedliche Clusterknoten oder fehlende Inhalte. Seine Aufgabe besteht hier darin, die WordPress-Weiterleitungsebene nachvollziehbar und kontrolliert zu halten.
AIOWS Weiterleitungs-Manager ansehenAIOWS-Tarife vergleichen
Passende AIOWS-Artikel
- 301 Weiterleitung in WordPress: Sicher einrichten und testen
- WordPress Weiterleitungsschleife: Ursache finden und beheben
- Probleme mit Trailing-Slash-Weiterleitungen in WordPress
Fazit und empfohlener Weg
Bestimmen Sie den Erzeuger der 404, vergleichen Sie sprechende und einfache Query-URLs und prüfen Sie die aktive Rewrite-Konfiguration auf jedem Knoten. Reparieren Sie das Routing, aktualisieren Sie WordPress-Regeln bei Bedarf einmalig und testen Sie repräsentative Wege, statt den Ausfall mit Weiterleitungen zu kaschieren.
