WordPress-Beiträge liefern 404, aber die Startseite funktioniert

Wenn deine Startseite problemlos lädt, aber jeder einzelne Beitrag und jede Seite einen 404 liefert, fehlen die URL-Rewrite-Regeln, auf die WordPress angewiesen ist, oder sie sind in deiner .htaccess-Datei beschädigt. Die schnellste Lösung: Gehe im wp-admin auf Einstellungen → Permalinks und klicke auf Änderungen speichern, ohne irgendetwas zu ändern. Das zwingt WordPress, den Rewrite-Block neu zu erzeugen. Wenn die 404-Fehler bestehen bleiben, ist deine .htaccess für den Webserver nicht beschreibbar, Apache ist so konfiguriert, dass es sie ignoriert, oder du bist auf Nginx (das überhaupt keine .htaccess verwendet).

Warum die Startseite funktioniert, die Beiträge aber nicht

Deine Startseite funktioniert, weil eine Anfrage an / direkt aus der index.php im Wurzelverzeichnis ausgeliefert wird. Kein Rewriting nötig.

Eine Anfrage an /2026/mein-beitrag/ ist etwas anderes. Dieser Pfad ist kein echter Ordner auf der Festplatte. Damit WordPress darauf antworten kann, muss Apache die Anfrage intern an die index.php weiterleiten. WordPress liest dann REQUEST_URI aus, gleicht sie mit den Rewrite-Regeln ab, die in der rewrite_rules-Option in der Datenbank gespeichert sind, löst die Query-Variablen auf (WP::parse_request()) und lädt den passenden Beitrag.

Die Übergabe von Apache an die index.php ist der Teil, der kaputtgeht. Sie hängt vollständig von diesem Block in der .htaccess ab:

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

Die beiden RewriteCond-Zeilen besagen: Wenn der angefragte Pfad keine echte Datei ist (!-f) und kein echtes Verzeichnis (!-d), leite ihn an die index.php weiter. Entferne diesen Block, und Apache sucht nach einem echten Verzeichnis /2026/mein-beitrag/, findet keines und liefert seinen eigenen 404 zurück — bevor WordPress die Anfrage überhaupt zu sehen bekommt.

Warum WordPress die .htaccess überschreibt, wenn du die Permalinks speicherst

Das ist der Teil, den die meisten Anleitungen auslassen. Wenn du auf der Permalinks-Seite auf Speichern klickst, ruft WordPress flush_rewrite_rules() auf. Auf Apache mit einer beschreibbaren .htaccess löst das save_mod_rewrite_rules() aus, was den obigen Block über WP_Rewrite::mod_rewrite_rules() neu erzeugt und ihn mit insert_with_markers() zurückschreibt.

insert_with_markers() fasst nur die Zeilen zwischen # BEGIN WordPress und # END WordPress an. Alles außerhalb dieser Markierungen bleibt unberührt. Alles innerhalb wird verworfen und neu geschrieben. Neuere WordPress-Versionen schreiben die Warnung sogar direkt in die Datei:

Any changes to the directives between these markers will be overwritten.

„WordPress überschreibt meine .htaccess” ist also zwar wahr, aber eng gefasst: Es schreibt nur seinen eigenen markierten Block neu, und nur dann, wenn die Datei beschreibbar ist. Ist die Datei nicht beschreibbar, tut das Speichern still und heimlich nichts auf der Festplatte. WordPress zeigt auf der Permalinks-Seite einen gelben Hinweis an, der dich auffordert, die Regeln von Hand einzufügen — und wenn du diesen Hinweis übersiehst, bleibt dein Rewrite-Block weiterhin fehlend und jeder Beitrag liefert weiter einen 404.

So behebst du es, Schritt für Schritt

1. Speichere deine Permalinks neu. Einstellungen → Permalinks → Änderungen speichern. Keine Änderungen nötig. Das führt den Flush erneut aus und schreibt den Block neu. Damit sind die meisten Fälle gelöst, einschließlich veralteter Regeln nach einer Migration.

2. Prüfe, ob .htaccess existiert und beschreibbar ist. Sie liegt im selben Ordner wie wp-config.php. Es ist eine versteckte Datei (Dotfile), aktiviere also „versteckte Dateien anzeigen” in deinem FTP-Programm oder verwende:

ls -la /path/to/wordpress/.htaccess

Wenn sie fehlt, lege sie an und füge den korrekten Block ein. Wenn deine Installation in einem Unterverzeichnis liegt, müssen RewriteBase und das Ziel der letzten Rewrite-Regel diesem Pfad entsprechen — hier einen Fehler zu machen ist der häufigste Grund, warum ein von Hand eingefügter Block trotzdem einen 404 liefert. Unser .htaccess-Generator erstellt den exakten Block für deinen Installationspfad, damit du nicht raten musst.

3. Stelle sicher, dass Apache die .htaccess lesen darf. Wenn der Virtual Host AllowOverride None gesetzt hat, ignoriert Apache die Datei komplett, unabhängig von ihrem Inhalt. Du brauchst AllowOverride All (oder mindestens FileInfo) für das WordPress-Verzeichnis. Das steht in der Serverkonfiguration, nicht in der .htaccess, erfordert also Serverzugriff:

<Directory /var/www/html>
    AllowOverride All
</Directory>

4. Stelle sicher, dass mod_rewrite aktiviert ist. Unter Debian/Ubuntu:

sudo a2enmod rewrite
sudo systemctl restart apache2

5. Auf Nginx gibt es keine .htaccess. Die Rewrites kommen stattdessen in den Server-Block:

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

Schnelle Diagnose: Wessen 404 ist das?

Schau dir die 404-Seite an. Wenn es eine ungestylte Apache- oder Hoster-Fehlerseite ist, hat Apache WordPress nie erreicht — das ist ein Problem mit der .htaccess oder der Serverkonfiguration (Schritte 2–4). Wenn es der gestylte 404 deines Themes ist, empfängt WordPress die Anfrage, kann sie aber nicht zuordnen — die Regeln in der Datenbank sind veraltet, und die Permalinks neu zu speichern (Schritt 1) ist die Lösung. Diese eine Unterscheidung erspart den meisten Leuten eine Stunde Raterei.

Was du nicht tun solltest

Deaktiviere nicht als Erstes alle deine Plugins. Ein reines Symptom „Beiträge 404, Startseite funktioniert” ist ein Rewrite-Problem, kein Plugin-Konflikt. Plugins zu deaktivieren ist die Reflexantwort in Foren, und sie hat mit diesem Fall so gut wie nie etwas zu tun.

Setze deine .htaccess nicht auf chmod 777. WordPress braucht die Datei beschreibbar durch den Webserver-Benutzer, was nicht dasselbe ist wie für jeden beschreibbar. 644 mit dem richtigen Eigentümer ist in Ordnung und sicher; 777 ist ein Sicherheitsloch, das das Routing ohnehin nicht beheben wird.

Füge keine eigenen Rewrite-Regeln zwischen die Markierungen # BEGIN WordPress / # END WordPress ein. Sie werden beim nächsten Speichern der Permalinks durch irgendjemanden gelöscht. Setze eigene Direktiven oberhalb der Zeile # BEGIN WordPress.

Installiere WordPress nicht neu. Die Core-Dateien sind in Ordnung. Es geht um einen einzigen fehlenden Textblock, nicht um eine beschädigte Installation.

Gib nicht deinem Theme die Schuld. Das Permalink-Routing ist WordPress-Core. Ein Theme kann es weder verursachen noch beheben.

Immer noch festgefahren?

Wenn du die Permalinks neu gespeichert, bestätigt hast, dass der Block vorhanden und beschreibbar ist, und AllowOverride All gesetzt hast, bleibt als Verdächtiger ein Security-Plugin oder eine Regel auf Hoster-Ebene übrig, die die .htaccess hinter deinem Rücken neu erzeugt oder sperrt. Prüfe den Änderungszeitstempel der Datei direkt nach einem Permalink-Speichern — wenn er sich nicht geändert hat, blockiert etwas den Schreibvorgang. Erzeuge einen sauberen Block mit dem .htaccess-Generator, füge ihn ein und teste erneut mit einem harten Neuladen.