---
title: "Permalinks und 404-Fehler in WordPress beheben"
date: 2026-09-30T22:06:40+02:00
modified: 2026-11-10T15:06:40+01:00
category: wordpress
type: how_to
author: Marcel Schönfelder
canonical: https://s-edv.com/anleitungen/wordpress-permalinks-404-fehler-beheben-htaccess
keywords:
  - WordPress
  - Permalinks
  - 404
  - htaccess
  - Weiterleitung
reading_time: 10
---

# 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 mit WordPress 7.1.2 auf Apache nachgestellt.

**Kurzfassung:** Zeigt die Fehlerseite das Design Ihres Themes, kennt WordPress die Adresse nicht: Öffnen Sie „Einstellungen > Permalinks“ und klicken Sie ohne Änderung auf „Änderungen speichern“, das schreibt die Regeln neu. Zeigt die Fehlerseite dagegen eine schlichte Meldung „Not Found“ des Webservers, fehlt die `.htaccess` oder der Server ignoriert sie. Bei Nginx fehlt dann die Zeile `try_files`. Beitragsadressen leitet WordPress nach einer Änderung selbst weiter, bei Seiten und bei einer neuen Permalink-Struktur brauchen Sie eigene 301-Weiterleitungen.

## 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 Test 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 Test 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:

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

> **Prüfen:** 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 Beispiel wurde ein eigener Inhaltstyp „Leistungen“ angelegt: 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:

```bash
$ 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.

> **Prüfen:** 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 Test 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:

```plaintext
# 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 Test 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:

Datei: `wp-cli.yml`

```yaml
apache_modules:
  - mod_rewrite
```

Ist die `.htaccess` korrekt und der Fehler bleibt, ignoriert der Server die Datei. Im Test 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.

> **Prüfen:** 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:

```nginx
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.

> **Prüfen:** `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 Test führte `/oeffnungszeiten-buero/` nach der Umbenennung zuverlässig auf `/oeffnungszeiten-2026/`.
- **Titelform einer Seite geändert:** Für Seiten legte WordPress im Test 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 Test 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 Test 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:

```plaintext
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.

> **Prüfen:** 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=80) ü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.

> **Prüfen:** 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 Test 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.

## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=80).

## Weiterführende Anleitungen und Quellen

- [WordPress-Update fehlgeschlagen: weiße Seite und kritischen Fehler beheben](https://s-edv.com/anleitungen/wordpress-update-fehler-beheben-weisse-seite-kritischer-fehler)
- [WordPress auf HTTPS umstellen und Mixed Content beheben](https://s-edv.com/anleitungen/wordpress-https-umstellen-ssl-mixed-content-beheben)
- [Staging-Umgebung für WordPress einrichten](https://s-edv.com/anleitungen/wordpress-staging-umgebung-wp-cli-einrichten)
- [WordPress-Dokumentation: .htaccess](https://developer.wordpress.org/advanced-administration/server/web-server/httpd/)
- [WordPress-Dokumentation: Nginx](https://developer.wordpress.org/advanced-administration/server/web-server/nginx/)
- [WP-CLI: wp rewrite](https://developer.wordpress.org/cli/commands/rewrite/)
- [Entwicklerreferenz: flush_rewrite_rules()](https://developer.wordpress.org/reference/functions/flush_rewrite_rules/)
- [Apache-Dokumentation: AllowOverride](https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride)