Dein Preis in 2 Minuten

WordPress-Fehler404

WordPress 404 bei Beiträgen und Seiten: Permalinks reparieren

Zeigt WordPress die Startseite, aber jeder Beitrag und jede Unterseite endet mit 404, sind fast immer die Permalinks gestört. Der Server leitet die schönen Adressen nicht mehr an WordPress weiter. Ursachen sind eine fehlende oder falsche .htaccess, ein abgeschaltetes mod_rewrite, eine nginx-Konfiguration ohne try_files oder veraltete Umschreibregeln nach einem Umzug. Meist reicht es, unter Einstellungen → Permalinks einmal zu speichern. Hilft das nicht, prüfst Du .htaccess und Server-Konfiguration.

So sieht die Meldung aus

  • 404 Not Found
  • Not Found
  • The requested URL was not found on this server.
  • HTTP ERROR 404

Woran es liegt.

Veraltete Umschreibregeln

WordPress speichert seine Regeln für schöne Adressen in der Datenbank. Nach einem Umzug, einem neuen Plugin mit eigenen Inhaltstypen oder einer geänderten Struktur passen sie nicht mehr. Dann findet WordPress zu vielen Adressen keinen Inhalt.

.htaccess fehlt oder ist leer

Auf Apache-Servern braucht WordPress den Block „BEGIN WordPress“ in der .htaccess. Fehlt die Datei nach einem Umzug oder kann WordPress sie mangels Schreibrechten nicht anlegen, kennt der Server nur die Startseite.

mod_rewrite aus oder .htaccess wird ignoriert

Auf eigenen Servern ist das Apache-Modul mod_rewrite manchmal nicht aktiv. Oder in der Konfiguration steht „AllowOverride None“, dann liest Apache die .htaccess gar nicht. Die Regeln sind vorhanden, wirken aber nicht.

nginx ohne passende Regel

nginx kennt keine .htaccess. Fehlt im server-Block die Zeile mit try_files, die unbekannte Adressen an index.php weitergibt, liefert nginx für jeden Beitrag direkt 404, ohne WordPress zu fragen.

Unterordner oder geänderte Adresse

Liegt WordPress in einem Unterordner oder wurde die Domain gewechselt, stimmen RewriteBase, WordPress-Adresse (URL) oder Website-Adresse (URL) oft nicht mehr. Die Startseite lädt, die Unterseiten zeigen aber auf einen falschen Pfad.

So behebst Du den Fehler.

Leg vor jeder Änderung eine Sicherung von Dateien und Datenbank an. Geh die Schritte der Reihe nach durch und prüf nach jedem, ob die Seite wieder lädt.

  1. Mit einfachen Permalinks testen

    Sichere zuerst die .htaccess und die Datenbank. Stelle dann unter Einstellungen → Permalinks die Struktur kurz auf „Einfach“ und rufe einen Beitrag auf. Lädt er mit einer Adresse wie ?p=123, ist der Inhalt da und nur die Umschreibung defekt. Stell danach Deine bisherige Struktur, etwa „Beitragsname“, wieder ein.

  2. Umschreibregeln neu erzeugen

    Geh zurück zu Einstellungen → Permalinks und speichere die Seite, ohne etwas umzustellen. WordPress erzeugt so seine Regeln frisch und schreibt die .htaccess, sofern es darf. Kann es die Datei nicht schreiben, zeigt es unten die Zeilen an, die Du selbst einfügen musst. Per WP-CLI klappt das Neuaufbauen auch ohne Dashboard.

    Terminal (WP-CLI)
    wp rewrite flush

  3. .htaccess mit dem Standardblock anlegen

    Öffne per FTP die .htaccess im WordPress-Hauptordner oder lege sie an, falls sie fehlt. Der WordPress-Block muss darin stehen. Liegt WordPress in einem Unterordner wie /blog/, passe RewriteBase und die letzte RewriteRule auf diesen Pfad an.

    .htaccess
    # 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

  4. mod_rewrite und AllowOverride prüfen (Apache)

    Wirkt die .htaccess nicht, obwohl sie stimmt, fehlt auf dem Server meist mod_rewrite oder die Freigabe für .htaccess-Dateien. Auf einem eigenen Debian- oder Ubuntu-Server erlaubst Du im VirtualHost AllowOverride All und schaltest das Modul ein. Auf Shared Hosting erledigt das der Hoster.

    Apache (VirtualHost und Terminal)
    # 1. im VirtualHost .htaccess erlauben
<Directory /var/www/html>
    AllowOverride All
</Directory>

# 2. Modul einschalten und Apache neu starten
sudo a2enmod rewrite
sudo systemctl restart apache2

  5. try_files in nginx ergänzen

    Läuft Deine Seite auf nginx, gehört in den server-Block eine location-Regel, die alles Unbekannte an index.php gibt. Nach dem Eintragen testest Du die Syntax mit nginx -t. Erst wenn sie stimmt, lädst Du nginx neu. Bei Managed Hosting mit nginx ist diese Regel meist gesetzt, dort hilft der Support.

    nginx (server-Block)
    location / {
    try_files $uri $uri/ /index.php?$args;
}

  6. Plugins mit eigenen Adressen prüfen

    Kommt der 404 nur bei bestimmten Inhalten wie Produkten, Veranstaltungen oder Portfolio-Einträgen, gehören sie zu einem Plugin mit eigenem Inhaltstyp. Deaktiviere und aktiviere dieses Plugin einmal und speichere danach die Permalinks. Auch Plugins für Weiterleitungen oder Mehrsprachigkeit können Adressen umbiegen.

  7. Einzelne Seiten gezielt prüfen

    Fehlt nur eine einzelne Seite, prüfe ihren Status: Entwürfe, private Inhalte und Einträge im Papierkorb liefern für Besucher 404. Hat sich die Adresse geändert, richte eine 301-Weiterleitung von der alten auf die neue Adresse ein, damit Links und Google sie finden.

  8. Den Hoster prüfen lassen

    Bleiben alle Unterseiten trotz korrekter .htaccess bei 404, lass den Hoster prüfen, ob mod_rewrite aktiv ist und .htaccess-Dateien gelesen werden. Bei nginx-Hosting fragst Du nach der try_files-Regel für WordPress.

Zuletzt geprüft am 25. September 2026.

So kommt er nicht wieder.

  • Nach jedem Umzug und jedem neuen Plugin mit eigenen Inhaltstypen die Permalinks einmal speichern.
  • Die Permalink-Struktur einer bestehenden Seite nicht ändern. Wenn doch, alle alten Adressen per 301 weiterleiten.
  • Die .htaccess vor Änderungen durch Plugins sichern, damit sich der letzte Stand schnell zurückholen lässt.
  • In der Search Console regelmäßig nach neuen 404-Fehlern schauen, dann fallen kaputte Links früh auf.

Fragen zu 404 bei Beiträgen und Seiten

Warum funktioniert nur die Startseite, aber keine Unterseite?
Die Startseite ruft direkt index.php auf und braucht keine Umschreibung. Alle anderen Adressen muss der Server erst an WordPress weiterreichen. Klappt das nicht, weil .htaccess, mod_rewrite oder try_files fehlen, endet jeder Beitrag mit 404.
Sind meine Beiträge nach dem 404 noch da?
Ja. Die Inhalte stehen unverändert in der Datenbank. Nur der Weg dorthin ist unterbrochen. Sobald die Permalinks wieder funktionieren, sind alle Beiträge unter ihren bisherigen Adressen erreichbar.
Welche Permalink-Einstellung ist die richtige?
Für die meisten Seiten passt „Beitragsname“: kurz, lesbar und gut für Google. Wichtiger als die Wahl ist, sie nach dem Start nicht mehr zu ändern. Jeder Wechsel erzeugt neue Adressen und braucht Weiterleitungen.
Wie leite ich alte Adressen weiter, die jetzt 404 liefern?
Mit einer 301-Weiterleitung, entweder über ein Plugin wie Redirection oder als Regel in der .htaccess. Leite jede alte Adresse auf die inhaltlich passende neue Seite, nicht pauschal auf die Startseite.

Verwandte Fehler

Alle WordPress-Fehler

Lieber eine Website, die einfach läuft?

Wir bauen Websites, die schnell laden und ohne Update-Stress laufen. Oder wir übernehmen Deine WordPress-Seite samt Pflege. Erst Dein Paket, dann ein Termin per Video.

Kevin Baum im Videocall an seinem Schreibtisch, im Hintergrund eine Holzlattenwand mit farbigem Licht.

Erst Dein Paket, dann der Termin

Im Preisrechner tippst Du an, was Dich bremst. Du siehst sofort Dein Paket mit Preisspanne. Danach wählst Du direkt einen Termin, das Gespräch läuft per Video.

Dein Preis in 2 Minuten