Permalinks und 404-Fehler in WordPress beheben

Die Startseite lädt, aber jeder Beitrag und jede Unterseite endet mit „Seite nicht gefunden“. Oder ein einzelner, oft verlinkter Beitrag ist nach einer Änderung plötzlich weg. Hinter beiden Fällen stecken meist die Permalinks: die Regeln, mit denen WordPress eine lesbare Adresse wie /kontakt/ dem richtigen Inhalt zuordnet. Diese Anleitung zeigt, wie Sie am Fehlerbild erkennen, ob der Webserver oder WordPress den 404 erzeugt, wie Sie die Regeln sicher neu schreiben und wie Sie verhindern, dass geänderte Adressen Besucher und Suchmaschinen ins Leere schicken. Alle Fehlerbilder wurden im Labor mit WordPress 7.1.2 auf Apache nachgestellt.

Voraussetzungen

• WordPress: aktuelle Version, hier 7.1.2. Die Abläufe gelten seit vielen Versionen unverändert.
• PHP: mindestens 7.4 laut WordPress-API, empfohlen ist eine aktuelle, unterstützte Version wie PHP 8.4.
• Rolle: Administrator im WordPress-Backend.
• Zugriff: FTP oder Dateimanager des Hosters, um die .htaccess im WordPress-Hauptverzeichnis zu prüfen. Für Nginx oder Serverkonfiguration brauchen Sie SSH oder den Support Ihres Hosters. WP-CLI ist hilfreich, aber nicht nötig.
• Webserver: Sie wissen, ob Ihre Website auf Apache (bzw. LiteSpeed) oder Nginx läuft. Den Hinweis finden Sie unter „Werkzeuge > Website-Zustand“ in den Informationen zum Server.
• Backup: eine aktuelle Sicherung, mindestens eine Kopie der bestehenden .htaccess, bevor Sie Permalinks oder Serverregeln ändern.

Schritt 1: Fehlerbild eingrenzen

Der wichtigste Hinweis steckt in der Fehlerseite selbst. Im Labor gab es zwei deutlich unterscheidbare Varianten:

Fehlerseite	Wer antwortet	Typische Ursache
Design Ihres Themes, Titel „Seite nicht gefunden“	WordPress	Veraltete Rewrite-Regeln, geänderte Adresse, Inhalt gelöscht
Schlichte Seite „404 Not Found“, „The requested URL was not found on this server.“	Webserver	.htaccess fehlt oder wird ignoriert, Nginx ohne try_files

Prüfen Sie außerdem den Umfang. Sind alle Unterseiten betroffen, aber die Startseite funktioniert, liegt es fast immer am Server oder an den Rewrite-Regeln. Ist nur eine einzelne Adresse betroffen, wurde meist der Inhalt umbenannt, verschoben oder gelöscht.

Ein schneller Gegentest: Rufen Sie einen Beitrag über seine interne ID auf, etwa https://ihre-domain.de/?p=4. Die ID sehen Sie in der Adresszeile, wenn Sie den Beitrag im Backend bearbeiten. Im Labor antwortete WordPress darauf auch bei defekten Regeln mit einer Weiterleitung auf die aktuelle Adresse. Funktioniert dieser Aufruf, ist der Inhalt vorhanden und nur die Zuordnung der lesbaren Adresse gestört.

Per Kommandozeile sehen Sie Statuscode und Weiterleitungsziel in einem Schritt:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" https://ihre-domain.de/kontakt/

Verifizieren: Sie wissen, welche der beiden Fehlerseiten erscheint, ob alle oder nur einzelne Adressen betroffen sind und ob der Aufruf per ?p=ID funktioniert.

Schritt 2: Permalink-Regeln neu schreiben

WordPress speichert seine Rewrite-Regeln in der Datenbank. Registriert ein Plugin einen neuen Inhaltstyp, etwa „Leistungen“ oder „Produkte“, müssen diese Regeln neu erzeugt werden. Geschieht das nicht, kennt WordPress die neuen Adressen nicht. Im Labor legten wir einen eigenen Inhaltstyp „Leistungen“ an: Der Eintrag unter /leistungen/wartung/ lieferte die WordPress-Fehlerseite. Nach dem Neuschreiben der Regeln kam Statuscode 200.

Im Backend genügt ein Klick: Öffnen Sie „Einstellungen > Permalinks“ und klicken Sie auf „Änderungen speichern“, ohne etwas zu ändern. WordPress bestätigt mit „Die Permalink-Struktur wurde aktualisiert.“ Beim Speichern schreibt WordPress die Regeln neu und aktualisiert auf Apache auch die .htaccess, sofern es die Datei beschreiben darf.

Mit WP-CLI geht es so, der zweite Befehl zeigt, welche Regel eine Adresse bedient:

wp rewrite flush
wp rewrite list --match=/leistungen/wartung/ --fields=match,query,source

Lösen Sie das Neuschreiben nicht automatisch bei jedem Seitenaufruf aus, etwa durch eigenen Code in der functions.php. Die WordPress-Entwicklerdokumentation zu flush_rewrite_rules() bezeichnet den Vorgang als aufwendig, er sollte nur bei Bedarf laufen, etwa wenn ein Plugin einen neuen Inhaltstyp registriert.

Verifizieren: Die zuvor fehlerhafte Adresse liefert Statuscode 200, und wp rewrite list --match=... nennt eine passende Regel mit dem erwarteten Inhaltstyp in der Spalte source.

Schritt 3: .htaccess auf Apache prüfen und wiederherstellen

Erscheint die schlichte Server-Fehlerseite, prüfen Sie die Datei .htaccess im WordPress-Hauptverzeichnis, also im selben Ordner wie wp-config.php. Der Punkt am Anfang macht sie in vielen FTP-Programmen unsichtbar, aktivieren Sie dort die Anzeige versteckter Dateien. Im Labor lieferte jede Unterseite nach dem Entfernen der Datei die Meldung „404 Not Found“ des Servers, die Startseite funktionierte weiter.

Den Standardblock von WordPress veröffentlicht die offizielle Dokumentation. Er lautet für eine Installation im Hauptverzeichnis:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Einfacher ist es meist, WordPress die Datei selbst schreiben zu lassen: Legen Sie eine leere .htaccess an, sorgen Sie dafür, dass der Webserver sie beschreiben darf, und speichern Sie wie in Schritt 2 die Permalinks. Regeln anderer Plugins, etwa für Caching oder Sicherheit, stehen in eigenen Blöcken außerhalb von „BEGIN WordPress“ und „END WordPress“. Diese Blöcke müssen Sie nach einem Neuanlegen gegebenenfalls über die Einstellungen der jeweiligen Plugins wiederherstellen. Hier zahlt sich die Kopie aus den Voraussetzungen aus.

Eine Falle bei WP-CLI: wp rewrite flush --hard schreibt die .htaccess nur, wenn WP-CLI weiß, dass mod_rewrite aktiv ist. Im Labor erschien ohne diese Angabe die Warnung „Regenerating a .htaccess file requires special configuration. See usage docs.“ und es entstand keine Datei. Mit einer wp-cli.yml im WordPress-Verzeichnis klappte es:

apache_modules:
  - mod_rewrite

Ist die .htaccess korrekt und der Fehler bleibt, ignoriert der Server die Datei. Im Labor genügte dafür die Einstellung AllowOverride None in der Apache-Konfiguration: Jede Unterseite lieferte wieder „404 Not Found“, obwohl die Datei vollständig war. Diese Einstellung liegt außerhalb von WordPress. Bei Webhosting-Tarifen klären Sie das mit dem Support, auf eigenen Servern muss für das WordPress-Verzeichnis AllowOverride All oder mindestens FileInfo gesetzt und mod_rewrite aktiv sein.

Verifizieren: Die .htaccess enthält den Block „BEGIN WordPress“ bis „END WordPress“, und eine Unterseite zeigt wieder Ihren Inhalt statt der Server-Fehlerseite.

Schritt 4: Nginx richtig konfigurieren

Nginx liest keine .htaccess. Speichern der Permalinks im Backend ändert dort also nichts an der Serverkonfiguration. Laut WordPress-Dokumentation für Nginx leitet diese Zeile im server-Block alle Anfragen, zu denen es keine Datei gibt, an WordPress weiter:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Der Teil ?$args gibt Parameter wie Suchbegriffe an WordPress weiter. Fehlt die Zeile, liefert Nginx für jede Unterseite eine eigene 404-Seite. Nach einer Änderung prüfen Sie die Konfiguration mit nginx -t und laden sie mit systemctl reload nginx neu. Bei verwaltetem Hosting setzt der Anbieter diese Regel, wenden Sie sich bei diesem Fehlerbild an den Support.

Verifizieren: nginx -t meldet „syntax is ok“ und „test is successful“, und eine Unterseite liefert Statuscode 200.

Schritt 5: Geänderte Adressen weiterleiten

Einzelne 404-Fehler entstehen fast immer durch Änderungen. Was WordPress dabei selbst abfängt und was nicht, zeigte der Labortest:

• Titelform eines Beitrags geändert: WordPress merkt sich die alte Titelform im Metafeld _wp_old_slug und leitet die alte Adresse per 301 auf die neue um. Im Labor führte /oeffnungszeiten-buero/ nach der Umbenennung zuverlässig auf /oeffnungszeiten-2026/.
• Titelform einer Seite geändert: Für Seiten legte WordPress im Labor kein solches Metafeld an. Die alte Adresse /kontakt/ wurde nur deshalb weitergeleitet, weil WordPress bei einem 404 eine ähnlich lautende Adresse rät. Dieses Raten lässt sich per Filter do_redirect_guess_404_permalink abschalten, im Labor lieferte die alte Adresse danach 404. Verlassen Sie sich bei Seiten also nicht darauf.
• Permalink-Struktur geändert: Nach dem Wechsel von „Monat und Name“ auf „Beitragsname“ lieferte die alte Adresse mit Jahr und Monat im Labor 404. Umgekehrt, von „Beitragsname“ auf eine Struktur mit Datum, leitete WordPress die kurzen Adressen noch weiter. Planen Sie bei jedem Strukturwechsel eigene Weiterleitungen.

Richten Sie für wichtige alte Adressen 301-Weiterleitungen ein, entweder mit einem Weiterleitungs-Plugin oder auf Apache in der .htaccess oberhalb des WordPress-Blocks:

Redirect 301 /kontakt/ /kontakt-anfahrt/

Der Statuscode 301 signalisiert eine dauerhafte Änderung. Suchmaschinen übernehmen dann die neue Adresse, Links von anderen Websites bleiben wirksam. Einen einmal gewählten Strukturwechsel sollten Sie auf einer Staging-Umgebung durchspielen und alle bisherigen Adressen vorher als Liste sichern.

Verifizieren: Die alte Adresse liefert mit dem curl-Befehl aus Schritt 1 den Statuscode 301 und als Ziel die neue Adresse, die neue Adresse selbst liefert 200.

Schritt 6: 404-Fehler dauerhaft überwachen

Viele 404-Fehler bemerken Sie erst, wenn Kunden sich melden. Die Google Search Console listet im Bericht zur Seitenindexierung Adressen, die Google als „Nicht gefunden (404)“ erkannt hat. Prüfen Sie diesen Bericht nach jedem Umbau und danach regelmäßig. Viele Weiterleitungs-Plugins protokollieren zusätzlich 404-Aufrufe auf der Website selbst. Achten Sie dabei auf den Datenschutz: Solche Protokolle speichern oft IP-Adressen und sollten nach kurzer Zeit gelöscht werden.

Nicht jeder 404 ist ein Problem. Aufrufe von Adressen, die nie existiert haben, etwa von automatisierten Scannern, dürfen einen 404 liefern. Weiterleiten sollten Sie nur Adressen, die früher Inhalte hatten und noch verlinkt oder aufgerufen werden.

Permalinks brechen selten von allein, sondern fast immer nach Updates, Plugin-Wechseln oder Umbauten. Wer die laufende Pflege nicht selbst übernehmen möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und wöchentliche Backups auf externen Speicher, von denen sich auch eine versehentlich überschriebene .htaccess zurückholen lässt.

Verifizieren: Der Indexierungsbericht der Search Console zeigt keine neuen 404-Adressen, die früher Inhalte hatten, und ein Termin für die nächste Kontrolle steht fest.

Typische Fehler

• „404 Not Found“ mit „The requested URL was not found on this server.“: Die Meldung kommt vom Webserver. Im Labor trat sie ohne .htaccess und bei AllowOverride None auf. Weiter mit Schritt 3.
• „Regenerating a .htaccess file requires special configuration. See usage docs.“: WP-CLI weiß nicht, dass mod_rewrite aktiv ist. Legen Sie die wp-cli.yml aus Schritt 3 an oder speichern Sie die Permalinks im Backend.
• Neue Inhaltstypen eines Plugins liefern 404: Die Rewrite-Regeln sind veraltet. Permalinks einmal speichern.
• Nach Umstellung der Permalinks sind alte Links tot: WordPress leitet nicht alle alten Strukturen weiter. Eigene 301-Weiterleitungen einrichten.
• Nach dem Neuanlegen der .htaccess fehlen Cache- oder Sicherheitsregeln: Diese Blöcke stammen von Plugins. Sichern Sie die Datei vor jeder Änderung und stellen Sie die Regeln über die Plugins wieder her.
• Permalink-Einstellung „Einfach“ als Notlösung: Damit funktionieren zwar alle Aufrufe per ?p=ID, aber sämtliche bisherigen Adressen ändern sich. Beheben Sie stattdessen die Ursache.

Häufige Fragen

Schadet es, die Permalinks häufig zu speichern?

Nein. Solange Sie die Struktur nicht ändern, schreibt WordPress nur dieselben Regeln neu. Vermeiden Sie lediglich Code, der das bei jedem Seitenaufruf auslöst.

Welche Permalink-Struktur ist die richtige?

Für Unternehmensseiten ist „Beitragsname“ verbreitet, weil die Adressen kurz und zeitlos sind. Wichtiger als die Wahl ist, sie nach dem Start nicht mehr zu ändern.

Warum funktioniert die Startseite, obwohl alle Unterseiten 404 liefern?

Die Startseite ruft direkt die index.php auf und braucht keine Rewrite-Regel. Alle anderen lesbaren Adressen gibt es als Datei nicht, sie müssen erst an WordPress weitergereicht werden.

Gilt das auch für LiteSpeed?

LiteSpeed-Server verarbeiten in der Regel die .htaccess wie Apache. Die Schritte 2 und 3 gelten dann entsprechend. Im Labor getestet wurde nur Apache.

Testumfang

Im Labor mit WordPress 7.1.2 (deutsch), PHP 8.4.26, Apache und WP-CLI 2.12.0 nachgestellt: WordPress- und Server-404 im Vergleich, Aufruf per ?p=ID, fehlende .htaccess, AllowOverride None, wp rewrite flush --hard mit und ohne wp-cli.yml, veraltete Regeln bei einem eigenen Inhaltstyp, Speichern der Permalinks im Backend, Weiterleitung nach Umbenennung von Beitrag und Seite, Wirkung des Filters do_redirect_guess_404_permalink sowie Wechsel der Permalink-Struktur in beide Richtungen. Die Nginx-Regel stammt aus der WordPress-Dokumentation und wurde nicht im Labor getestet.

Fazit

404-Fehler in WordPress lassen sich fast immer einer von zwei Ursachen zuordnen: Entweder erreicht die Anfrage WordPress gar nicht, dann liegt es an .htaccess oder Serverkonfiguration, oder WordPress kennt die Adresse nicht, dann helfen neu geschriebene Regeln oder eine Weiterleitung. Ein Blick auf die Fehlerseite spart dabei die meiste Suche. Sichern Sie die .htaccess vor Änderungen, ändern Sie die Permalink-Struktur möglichst nie und richten Sie für geänderte Adressen 301-Weiterleitungen ein. Wer Updates und Backups dauerhaft in fachkundige Hände geben möchte, findet sie bei der WordPress-Wartung von Marcel Schönfelder.

Weiterführende Anleitungen und Quellen

• WordPress-Update fehlgeschlagen: weiße Seite und kritischen Fehler beheben
• WordPress auf HTTPS umstellen und Mixed Content beheben
• Staging-Umgebung für WordPress einrichten
• WordPress-Dokumentation: .htaccess
• WordPress-Dokumentation: Nginx
• WP-CLI: wp rewrite
• Entwicklerreferenz: flush_rewrite_rules()
• Apache-Dokumentation: AllowOverride