WordPress 404 auf allen Seiten außer der Startseite: Lösung

Wenn die Startseite von WordPress lädt, Beiträge, Seiten und Kategorien aber 404 liefern, erreicht die Anfrage entweder nie die index.php (in Nginx fehlt das richtige try_files, bei Apache fehlt die .htaccess, mod_rewrite ist aus oder AllowOverride steht auf None), oder WordPress hat für diese URL keine Rewrite-Regel. Prüfen Sie zuerst, wer die 404-Seite ausgeliefert hat: Fehlt das Theme-Design, liegt der Fehler beim Webserver; ist es die 404-Seite Ihres Themes, führen Sie wp rewrite flush aus (oder speichern Sie Einstellungen → Permalinks) und suchen Sie nach einem Plugin, das die Regeln stört. Wir haben sechs Ursachen auf einem Testsystem nachgestellt; unten finden Sie die echten Antwortcodes und die geprüften Lösungen.

Schritt eins: Wer hat die 404 geliefert, der Server oder WordPress?

Nehmen Sie eine beliebige Beitrags-URL, die 404 liefert, und führen Sie drei Befehle aus:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/post-name/
curl -s https://example.com/post-name/ | grep -c wp-content
curl -sI "https://example.com/?p=123" | grep -iE "^HTTP|^location"

Auf dem Testsystem enthielt die 404-Seite von nginx oder Apache 0 Erwähnungen von wp-content, die 404-Seite von Twenty Twenty-Five dagegen 4. Null bedeutet: Die Anfrage hat PHP nie erreicht, und die Konfiguration des Webservers muss korrigiert werden. Eine Zahl größer als null bedeutet: WordPress hat die Anfrage erhalten, aber keine passende Regel gefunden.

Die Prüfung über die einfache Adresse /?p=ID ist nützlich, verhält sich aber anders, als viele Anleitungen behaupten: Sie liefert nicht 200, sondern leitet mit 301 auf die sprechende URL weiter. Das passierte in jedem unserer Szenarien: /?p=304 lieferte 301 auf /post-300/, und diese Adresse lieferte dann 404. Die Weiterleitung selbst beweist, dass PHP und die Datenbank funktionieren und nur das Umschreiben der URLs defekt ist.

Ursache 1. Nginx ohne das richtige try_files

Nginx ignoriert die .htaccess, deshalb hängt alles vom Block location / ab. Wir haben die Kopie der Website mit drei Varianten davon betrieben:

Die Startseite funktioniert immer, weil nginx für „/“ die index.php über die Direktive index findet. Die Zeile try_files $uri $uri/ =404; stammt aus der Standard-Site von Ubuntu und landet deshalb oft in WordPress-Konfigurationen. Mit ihr blieb das error.log leer, das Log führt Sie also nicht zur Ursache. Ganz ohne Block location / gibt das Log dagegen einen Hinweis:

[error] ... "/var/www/r10wp/sample-page/index.php" is not found (2: No such file or directory), request: "GET /sample-page/ HTTP/1.1"

Auch /wp-json/ ging kaputt, sodass der Block-Editor keine Beiträge speichern kann. Gleichzeitig lieferte /?rest_route=/ den Code 200: Die REST-API funktioniert, nur das Umschreiben schlägt fehl. Der Block, mit dem auf dem Testsystem jede URL 200 lieferte:

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/public_html;
    index index.php;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

sudo nginx -T | grep -n try_files
sudo nginx -t && sudo systemctl reload nginx

Ersetzen Sie die PHP-Version im Socket-Pfad durch Ihre eigene. Weitere Nginx-Blöcke, darunter Weiterleitungen auf https und auf den Host ohne www, haben wir in unseren fertigen Beispielen für 301-Weiterleitungen gesammelt.

Ursache 2. Apache: fehlende .htaccess, mod_rewrite aus oder AllowOverride None

Für diesen Teil haben wir Apache 2.4.58 mit PHP-FPM auf einem separaten Port für dieselbe Kopie der Website installiert. Vier verschiedene Fehler führten fast zum gleichen Ergebnis:

Eine schlichte Apache-Seite „Not Found“ mit leerem Log ist also bei drei der vier Ursachen normal. Drei Prüfungen unterscheiden sie:

ls -la .htaccess                # is the file in the site root
apache2ctl -M | grep rewrite    # expect rewrite_module (shared)
# AllowOverride test: add any random word as the first line of .htaccess

Den Test mit dem zufälligen Wort haben wir ebenfalls geprüft. Mit AllowOverride None lieferte die Website weiter 404, weil die Datei ignoriert wird. Mit AllowOverride All kam sofort 500, und im Log stand „Invalid command“ mit genau diesem Wort. Entfernen Sie die Zeile nach dem Test wieder.

Der Standardblock für eine einzelne Website, wie WordPress ihn auf dem Testsystem selbst erzeugt hat:

# 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

Auf einem VPS, auf dem Sie Apache selbst verwalten, aktivieren Sie das Modul und erlauben die .htaccess für das Verzeichnis der Website (danach lieferte auf dem Testsystem jede URL 200):

sudo a2enmod rewrite
sudo systemctl restart apache2

# in the virtual host config
<Directory /var/www/example.com/public_html>
    AllowOverride All
    Require all granted
</Directory>

Eine Falle bei WP-CLI: wp rewrite flush --hard hat keine .htaccess angelegt, sondern stattdessen eine Warnung ausgegeben:

$ wp rewrite flush --hard --path=/var/www/r10wp
Warning: Regenerating a .htaccess file requires special configuration. See usage docs.
Success: Rewrite rules flushed.

Eine Datei wp-cli.yml mit apache_modules behebt das, aber WP-CLI sucht diese Datei im aktuellen Verzeichnis, nicht im Verzeichnis aus --path. Funktioniert hat nur das:

cd /var/www/example.com/public_html
printf 'apache_modules:\n  - mod_rewrite\n' > wp-cli.yml
wp rewrite flush --hard

Die Datei gehörte danach root, weil der Befehl als root lief. Führen Sie WP-CLI beim Hosting als Benutzer der Website aus oder ändern Sie den Eigentümer; die Rechte der .htaccess sollten 644 sein. Weitere Einstellungen des Webservers beschreiben wir in unserem Leitfaden zur Serverkonfiguration.

Ursache 3. Permalink-Struktur geändert, Regeln nicht neu erzeugt

WordPress speichert die Rewrite-Regeln in der Datenbank (Option rewrite_rules) und erzeugt sie nur bei einem „Flush“ neu: wenn die Seite Permalinks gespeichert wird, wenn manche Plugins das tun oder wenn Sie wp rewrite flush ausführen. Wird die Struktur direkt in der Datenbank oder mit wp option update geändert (das passiert nach Datenbankimporten und Migrationsskripten), sind die Links auf der Website schon neu, die Regeln aber noch alt:

$ wp option update permalink_structure '/%year%/%monthnum%/%postname%/'
Success: Updated 'permalink_structure' option.

/2026/10/post-300/   404  (theme 404 page, wp-content: 4)
/post-300/           301  → /2026/10/post-300/
/sample-page/        200

$ wp rewrite list --match=/2026/10/post-300/ --fields=match,query
(.?.+?)(?:/([0-9]+))?/?$   index.php?pagename=$matches[1]&page=$matches[2]

Alte URLs leiten auf die neuen weiter, und die neuen liefern 404, sodass Besucher bei jedem Menülink auf einen Fehler stoßen. wp rewrite list --match zeigt, welche Regel zuerst gegriffen hat: Hier hat die Regel für Seiten die URL abgefangen, weil die Datenbank keine Regeln für die neue Struktur enthält. Die Lösung:

$ wp rewrite flush
Success: Rewrite rules flushed.
$ wp rewrite list --format=count
96

/2026/10/post-300/   200

Neue Beitragstypen verhalten sich genauso. Wir haben in einem mu-plugin den Beitragstyp book registriert: /book/test-book/ lieferte die 404-Seite des Themes, obwohl /?book=test-book mit 200 öffnete. Nach wp rewrite flush stieg die Zahl der Regeln von 94 auf 111, und der Beitrag öffnete. Deshalb steckt hinter einer 404 nur bei WooCommerce-Produkten oder einem anderen Beitragstyp fast immer ein fehlender Flush. Dieselbe Ursache tritt häufig auf, wenn man WordPress zu einem anderen Hoster umzieht und die Datenbank von Hand importiert.

Ursache 4. Falsche home und siteurl oder Installation in einem Unterverzeichnis

Website von /blog/ ins Stammverzeichnis verschoben, die Datenbank behielt die alte URL

Wir haben home und siteurl auf die URL mit /blog gesetzt, während die Dateien im Stammverzeichnis lagen und Nginx korrekt konfiguriert war. Beiträge öffneten weiterhin mit 200, sowohl unter /post-300/ als auch unter /blog/post-300/: WordPress wertet beide aus. Aber alle Links im HTML zeigten auf /blog/, Styles aus /blog/wp-content/ lieferten 404, und /wp-admin/ leitete auf /blog/wp-login.php weiter, das ebenfalls 404 lieferte. Das Symptom ist hier also ein anderes: eine Website ohne Styles und ohne Login in den Adminbereich.

wp option get home
wp option get siteurl
wp option update home https://example.com
wp option update siteurl https://example.com

Nach den beiden Update-Befehlen lieferten die Styles auf dem Testsystem 200, und /wp-admin/ führte zur richtigen Login-Seite. Kommen Sie nicht in den Adminbereich und haben kein SSH, setzen Sie dieselben Werte über die Konstanten WP_HOME und WP_SITEURL in der wp-config.php. Alte URLs im Inhalt der Beiträge ersetzen Sie mit wp search-replace (zuerst mit --dry-run ausführen); in diesem Test haben wir das nicht ausgeführt.

WordPress im Unterverzeichnis, Nginx fällt auf die index.php im Stammverzeichnis zurück

Die WordPress-Dateien lagen in /blog/, und die Konfiguration enthielt nur location / mit Rückfall auf /index.php. Ergebnis: /blog/ lieferte 200, /blog/post-300/ und /blog/sample-page/ lieferten die 404-Seite von nginx, Styles und wp-login.php lieferten 200. Das ist dasselbe „nur die Startseite funktioniert“, nur für ein Unterverzeichnis: nginx sucht /index.php im Stammverzeichnis, und dort gibt es keine. Die Lösung, nach der jede URL 200 lieferte:

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

Bei Apache ändert eine Installation im Unterverzeichnis zwei Zeilen der .htaccess: RewriteBase /blog/ und RewriteRule . /blog/index.php [L]. Diese Variante haben wir auf dem Testsystem nicht ausprobiert.

Ursache 5. Plugin oder Theme mit einer konkurrierenden Rewrite-Regel

Plugins, die „die Basis aus den URLs entfernen“ (damit Landingpages oder Produkte unter /name/ öffnen), setzen eine eigene Regel an den Anfang der Liste. Wir haben das mit einem mu-plugin nachgestellt, das einen eigenen Beitragstyp und eine Regel registriert:

add_rewrite_rule('^([^/]+)/?$', 'index.php?landing=$matches[1]', 'top');

• Direkt nach der Installation änderte sich nichts: Plugin-Regeln gelangen erst nach einem Flush in die Datenbank. Deshalb zeigt sich der Fehler oft später, wenn jemand die Permalinks speichert oder ein anderes Plugin aktualisiert.
• Nach wp rewrite flush lieferten die Startseite und /category/uncategorized/ 200, /post-300/ und /sample-page/ dagegen die 404-Seite des Themes.
• Nach dem Entfernen des Plugins ohne Flush wurde es schlimmer: /post-300/ lieferte 200, aber mit dem Inhalt der Startseite (Titel der Website, body class „home blog“). Eine Suchmaschine sähe statt der Beiträge Dutzende Duplikate der Startseite.
• Ein weiteres wp rewrite flush brachte alles zurück: 200 und der richtige Beitrag.

Derselbe Befehl findet den Verursacher:

$ wp rewrite list --match=/post-300/ --fields=match,query,source
^([^/]+)/?$                 index.php?landing=$matches[1]                       other
(.?.+?)(?:/([0-9]+))?/?$    index.php?pagename=$matches[1]&page=$matches[2]   page

Die Quelle „other“ bedeutet eine Regel aus dem Code eines Plugins oder Themes, nicht aus dem Core. Deaktivieren Sie danach verdächtige Plugins einzeln (am besten auf einer Kopie der Website) und führen Sie nach jedem Schritt wp rewrite flush aus. Ein interessantes Detail: Dieselbe gierige Regel, die auf normale Seiten zeigt (pagename), hat nichts kaputt gemacht. WordPress überspringt sie, wenn keine Seite diesen Pfad hat, und geht zur nächsten Regel. Kaputt machen die Website Regeln, die auf eigene Query-Variablen zeigen.

Ursache 6. Der Cache liefert nach der Korrektur weiter eine gespeicherte 404

Wir haben fastcgi_cache mit fastcgi_cache_valid 404 10m; aktiviert. Erste Beobachtung: WordPress sendet seine 404 mit Cache-Control: no-cache und einem Expires-Datum aus dem Jahr 1984, deshalb cacht nginx sie standardmäßig nicht (X-Cache: MISS bei jeder Anfrage). Das Problem trat auf, als wir fastcgi_ignore_headers Cache-Control Expires Set-Cookie; hinzufügten, eine Zeile, die für WordPress-Caching oft empfohlen wird:

broken               /post-300/        404  X-Cache: MISS
                     /post-300/        404  X-Cache: HIT
rules fixed          /post-300/        404  X-Cache: HIT
                     /post-300/?utm=1  200  X-Cache: MISS
cache entry deleted  /post-300/        200  X-Cache: MISS
                     /post-300/        200  X-Cache: HIT

Das Erkennungszeichen: Die URL mit einem beliebigen Query-Parameter öffnet, die nackte URL liefert 404 mit X-Cache: HIT. Einen einzelnen Eintrag können Sie ohne Purge-Modul löschen, weil der Dateiname der md5-Hash des Cache-Schlüssels ist. Auf dem Testsystem enthielt diese Datei „KEY: httpGET127.0.0.1/post-300/“ und „Status: 404 Not Found“; nach dem Löschen lieferte der Beitrag 200.

# key = $scheme$request_method$host$request_uri, levels=1:2
KEY="httpsGETexample.com/post-name/"
H=$(echo -n "$KEY" | md5sum | cut -d' ' -f1)
sudo rm -f /var/cache/nginx/wp/${H: -1}/${H: -3:2}/$H

# or the whole cache
sudo find /var/cache/nginx/wp -type f -delete

Den Cache-Pfad finden Sie in Ihrer Direktive fastcgi_cache_path. Leeren Sie den Plugin-Cache und das CDN separat. Damit Fehler nicht hängen bleiben, cachen Sie 404 nur kurz, zum Beispiel fastcgi_cache_valid 404 1m;. Wie sich serverseitiges Caching auf die Geschwindigkeit auswirkt, erklären wir im Artikel über Cache und RAM beim Hosting.

Entscheidungstabelle: Symptom, Ursache, Prüfung, Lösung

Häufige Fragen

Warum funktioniert nach dem Umzug zu einem neuen Hoster nur die Startseite?

Meist ist die versteckte .htaccess verloren gegangen (FTP-Programme blenden Dateien mit einem Punkt am Anfang oft aus und überspringen sie), oder der neue Server läuft mit Nginx ohne das nötige try_files. Auf dem Testsystem ergaben beide Fälle dasselbe Bild: 200 auf der Startseite und 404 bei Beiträgen.

Wie finde ich heraus, ob Nginx oder Apache meine Website ausliefert?

Führen Sie curl -sI https://example.com/ | grep -i server aus. Auf dem Testsystem lautete der Header „Server: nginx/1.24.0 (Ubuntu)“. Manche Hoster blenden ihn aus; dann sehen Sie den Typ des Webservers im Control Panel nach. Arbeitet nginx als Proxy vor Apache, werden die WordPress-Regeln von Apache über die .htaccess ausgeführt.

Hilft eine Neuinstallation von WordPress?

Nein. In keinem der sechs Szenarien lag die Ursache in den Core-Dateien: Die Regeln liegen in der Datenbank, und Anfragen an die index.php weiterzureichen ist Aufgabe des Webservers.

Schaden ein paar Tage mit 404 dem Google-Ranking?

Ein kurzer Ausfall bleibt meist ohne Folgen. Sieht der Crawler aber mehrere Tage lang 404, fallen Seiten aus dem Index. Prüfen Sie nach der Korrektur einige URLs mit dem URL-Prüftool in der Search Console und reichen Sie die Sitemap erneut ein.

Wenn Sie Nginx, Apache und Caching lieber nicht selbst konfigurieren möchten, sehen Sie sich die Hosting-Tarife von RichHost an: NVMe-Festplatten, das Control Panel aus eigener Entwicklung mit KI-Assistent und kostenloses SSL von Let’s Encrypt. Wie man Hosting für WordPress auswählt, erklären wir in einem separaten Leitfaden.