Prüfen Sie die genaue URL mit einem Werkzeug, das jeden HTTP-Schritt anzeigt. Ermitteln Sie, welche Ebene den Statuscode 404 oder den Location-Header zurückgibt. Prüfen Sie beim WordPress-Routing, ob der Slug existiert, ob ein Typkonflikt vorliegt und wie die Rewrite-Regeln lauten; vereinheitlichen Sie bei einer Schleife HTTPS, Host und Schrägstrich zwischen Proxy, Server und WordPress-Einstellungen.
Ein WordPress-404 kann fehlende Inhalte, nicht aktualisierte Rewrite-Regeln, einen Slug-Konflikt, einen Serverfehler oder eine Anfrage bedeuten, die WordPress gar nicht erreicht hat. Eine Weiterleitungsschleife entsteht wiederum, wenn zwei Ebenen unterschiedliche Hosts, Protokolle, Schrägstriche oder Sprachen erzwingen. Der Browser zeigt denselben allgemeinen Fehler an, obwohl die Korrektur an einer ganz anderen Stelle erfolgen muss.
Die Diagnose verfolgt eine einzelne Anfrage Schritt für Schritt: DNS und Proxy, HTTPS, Webserver, `.htaccess`- oder Nginx-Regeln, den WordPress Canonical Redirect und Plugins. Ziel ist eine bevorzugte URL und höchstens eine direkte Weiterleitung von der alten Variante. Zufälliges Speichern der Permalinks oder das Hinzufügen eines weiteren Redirect-Plugins kann das Symptom vorübergehend verändern, erhöht aber die Unsicherheit.
Erfassen Sie den genauen HTTP-Pfad
Verwenden Sie curl oder das Netzwerk-Panel und notieren Sie die ursprüngliche URL, den Status, den Location-Header bei jedem Schritt und die finale Antwort. Testen Sie anonym ohne Cache und anschließend mit einem normalen Browser. Unterscheiden Sie eine Server-404 von einem WordPress-Template, einem Soft 404 mit Statuscode 200 und einer Sicherheitssperre. Zeitpunkt und Request-ID helfen, den Eintrag im Log zu finden.
Testen Sie HTTP und HTTPS, die www-Variante, den abschließenden Schrägstrich, Kleinschreibung und die URL ohne Kampagnenparameter, erstellen Sie aber nicht für jede Variante eine eigene Regel. Liefert das CDN eine andere Antwort als die direkte Verbindung zum Origin, liegt das Problem vor der Anwendung oder im Cache. Testen Sie den Origin direkt nur mit entsprechender Berechtigung und dem korrekten Host-Header.
Prüfen Sie Existenz und Konflikte der WordPress-Route
Suchen Sie im Admin-Bereich den veröffentlichten Eintrag sowie dessen Slug, Status, Typ und übergeordnetes Element. Dieselbe Basis kann von einer Seite, einem Inhaltstyp oder einer Taxonomie verwendet werden. Ein Entwurf oder privater Eintrag verhält sich gegenüber einem anonymen Nutzer anders. Prüfen Sie außerdem die Sprachversion und ob ein Plugin einen Endpoint mit demselben Namen hinzufügt.
Rewrite-Regeln lassen sich kontrolliert durch das Speichern der Permalinks oder per CLI neu aufbauen, dies sollte jedoch keine regelmäßige Notlösung sein. Ein eigenes Plugin sollte den Flush nur bei der Aktivierung oder bei einer Regeländerung ausführen, nicht bei jeder Anfrage. Hat der Neuaufbau geholfen, suchen Sie die Komponente, die die Regeln nicht zum richtigen Zeitpunkt registriert oder sie wiederholt überschreibt.
- Status und Art des Eintrags
- Konflikt bei Slug oder Basis
- Sprach- und übergeordneter Pfad
- Registrierung der Rewrite-Regel
Teilen Sie die Verantwortung der Redirect-Ebenen auf
Kanonischen Host und HTTPS sollten Sie idealerweise auf einer einzigen Edge- oder Serverebene unter Berücksichtigung der Proxy-Header regeln. WordPress muss das korrekte öffentliche Schema und die korrekte Adresse kennen. Wenn das CDN HTTPS terminiert, der Origin die Verbindung aber weiterhin als HTTP betrachtet, kann die Anwendung zurückleiten. Vertrauenswürdige Proxy-Header sollten Sie nur von einem bekannten Vermittler akzeptieren.
SEO-Plugin, Redirect-Plugin, Mehrsprachigkeits-Plugin und eigener Code können allesamt den Location-Header ändern. Erstellen Sie eine Bestandsaufnahme und weisen Sie jeder Kategorie einen Verantwortlichen zu: Host/Protokoll dem Server, alte Inhalts-URLs der Migrationszuordnung, Sprache dem Übersetzungssystem. Eine Regel hat einen Zweck. Verkürzen Sie Ketten, indem Sie den ersten Schritt direkt auf das endgültige Ziel aktualisieren.
Behandeln Sie alte und ungültige URLs entsprechend ihrer Bedeutung
Wurde ein Inhalt verschoben, verwenden Sie eine dauerhafte direkte Weiterleitung auf den nächstliegenden Ersatz. Hat er nie existiert oder gibt es keinen Ersatz, ist eine korrekte 404 richtig. Alles pauschal auf die Startseite umzuleiten, führt Nutzer in die Irre und verschleiert defekte Links. Verwenden Sie eine temporäre Weiterleitung nur bei einem tatsächlich vorübergehenden Zustand mit einem Plan für deren Beendigung.
Eine eigene 404-Seite sollte den Statuscode 404 zurückgeben, die Situation erklären und Navigation oder eine Suche anbieten. Sie enthält keine automatische Weiterleitung nach einigen Sekunden. Beobachten Sie die häufigsten fehlerhaften Pfade und korrigieren Sie die interne Quelle des Links. Bei schädlichem oder zufälligem Scanning ist es nicht nötig, für jeden Versuch eine Regel anzulegen.
- 301 für dauerhaften relevanten Ersatz
- 302 nur für einen vorübergehenden Zustand
- Echter 404-Code ohne vorgetäuschte Weiterleitung
- Korrektur eines internen Links an der Quelle
Testen Sie Regeln vor und nach dem Deployment
Erstellen Sie aus der Migrationskarte einen automatischen Test mit alter URL, erwartetem Status und finalem Ziel. Berücksichtigen Sie Schrägstrich, Query-String, kodierte Zeichen und einige nicht existierende Adressen. Auf dem Staging kann ein anderer Host verwendet werden, daher dürfen die Regeln Besucher nicht fest auf die Produktion weiterleiten. Validieren Sie die Serverkonfiguration vor dem Reload.
Gehen Sie nach dem Deployment die priorisierten URLs durch, achten Sie auf Schleifen, 5xx-Fehler und einen Anstieg von 404-Fehlern in den Logs. Leeren Sie nur den relevanten CDN-Cache. Dokumentieren Sie Änderungen mit Begründung und Datum, damit eine alte Regel bei der nächsten Migration nicht zurückkehrt. Bewahren Sie bei einem Vorfall die ursprüngliche Weiterleitungskette als Beleg auf und passen Sie erst danach die einzelnen Ebenen an.
Häufige Fragen
Hilft das Speichern der Permalinks bei WordPress-404-Fehlern?
Es kann die Rewrite-Regeln erneuern und diese Ebene bestätigen, ist aber keine universelle Lösung. Tritt das Problem wiederholt auf, muss der Slug-Konflikt, die fehlerhafte Registrierung oder die Serverregel gefunden werden, die den Zustand verursacht.
Warum entsteht ERR_TOO_MANY_REDIRECTS?
Meist sind sich zwei Ebenen bei HTTPS, Host, Schrägstrich, Sprache oder Anmeldung uneinig und schicken die Anfrage hin und her. Erfassen Sie die gesamte Kette und passen Sie die erste konfliktverursachende Ebene an, statt blind an Cookies zu ändern.
Soll ich jeden 404-Fehler auf die Startseite weiterleiten?
Nein. Leiten Sie nur alte URLs mit einem relevanten Ersatz weiter. Eine nicht existierende Adresse sollte einen echten 404-Status mit hilfreicher Navigation zurückgeben. Pauschale Weiterleitungen verwirren Menschen und erschweren das Aufdecken defekter Links.
Quellen und weiterführende Lektüre
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
