Permalinks geändert, Beiträge liefern 404: So bekommst du deine Website zurück

Veröffentlicht am

· von Norbert Hofmann

Kurz gesagt: Wenn nach dem Umstellen der Permalinks nur noch die Startseite lädt, fehlen die Umschreibregeln. Auf Apache-Servern steht das fast immer an einer fehlenden oder nicht beschreibbaren .htaccess: Lege sie mit dem WordPress-Standardinhalt im Hauptverzeichnis an (siehe unten) und speichere unter Einstellungen → Permalinks einmal neu. Auf reinen nginx-Servern braucht es stattdessen eine Regel in der Serverkonfiguration. Kommst du gar nicht mehr ins Backend, setzt du die Permalinks per Datenbank oder WP-CLI zurück.

Warum das passiert

Bei „Einfach“-Permalinks (?p=123) ruft der Browser direkt die index.php auf. Bei schönen Adressen wie /mein-beitrag/ muss der Webserver jede Anfrage auf eine nicht existierende Datei an WordPress weiterreichen. Auf Apache erledigt das die .htaccess, die WordPress beim Speichern der Permalinks schreibt. Darf es die Datei nicht schreiben, oder wertet der Server sie nicht aus, liefert er 404. Typisch ist, dass dann auch die REST-API unter /wp-json/ nicht erreichbar ist, wodurch der Block-Editor beim Speichern Fehler meldet.

Anleitung für Apache-Server

  1. Verbinde dich per SFTP und aktiviere die Anzeige versteckter Dateien.
  2. Prüfe, ob im WordPress-Hauptverzeichnis (dort, wo die wp-config.php liegt) eine Datei .htaccess existiert.
  3. Fehlt sie, lege sie an und füge den folgenden Inhalt ein. Existiert sie, prüfe, ob der Block zwischen # BEGIN WordPress und # END WordPress vorhanden ist.
  4. Setze die Rechte der Datei auf 644.
  5. Speichere unter Einstellungen → Permalinks ohne Änderung einmal neu und teste einen Beitrag.
# 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

Liegt WordPress in einem Unterverzeichnis wie /blog/, lauten die Zeilen RewriteBase /blog/ und RewriteRule . /blog/index.php [L]. Die Zeile mit HTTP_AUTHORIZATION sorgt dafür, dass Anmeldungen an der REST-API funktionieren, etwa mit Anwendungspasswörtern.

Hilft das nicht, ist beim Hoster entweder mod_rewrite nicht aktiv oder die Auswertung von .htaccess-Dateien abgeschaltet (AllowOverride None). Bei Plesk prüfst du unter der Domain in den Einstellungen für Apache & nginx, dass nginx nicht allein arbeitet, sondern Anfragen an Apache weiterreicht.

Anleitung für nginx

nginx ignoriert .htaccess-Dateien. Die Weiterleitung an WordPress steht in der Serverkonfiguration. Auf verwalteten Servern trägst du die Regel im Kundenmenü unter „Zusätzliche nginx-Direktiven“ ein oder bittest den Hoster darum:

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

Kein Zugriff mehr aufs Backend

Das Backend unter /wp-admin/ ist ein echtes Verzeichnis und läuft meist auch ohne Umschreibregeln. Klappt es trotzdem nicht, setzt du die Permalinks zurück auf „Einfach“: In phpMyAdmin in der Tabelle wp_options den Wert von permalink_structure leeren. Danach funktioniert die Website mit ?p=-Adressen und du kannst die Ursache in Ruhe beheben.

Für Fortgeschrittene: Permalinks per WP-CLI

# Aktuelle Struktur
wp option get permalink_structure

# Regeln neu erzeugen und .htaccess schreiben lassen
wp rewrite flush --hard

# Notfall: auf "Einfach" zurücksetzen
wp rewrite structure '' --hard

# Prüfen, ob die REST-API antwortet
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-json/

--hard schreibt die .htaccess nur, wenn WordPress die Datei beschreiben darf und WP-CLI weiß, dass mod_rewrite aktiv ist. Auf der Kommandozeile erkennt es das nicht selbst, deshalb legst du im WordPress-Verzeichnis eine Datei wp-cli.yml an:

apache_modules:
  - mod_rewrite

Ohne diesen Eintrag aktualisiert WP-CLI nur die Regeln in der Datenbank. --hard funktioniert außerdem nur bei Einzelinstallationen, nicht in Multisite-Netzwerken. Ein Trick zur Unterscheidung: Funktioniert /?rest_route=/, aber /wp-json/ nicht, läuft WordPress korrekt und nur die Umschreibregeln fehlen.

Wie du die Struktur sauber planst und alte Adressen weiterleitest, steht in Kategorie in der URL und /category/ entfernen, Rechteprobleme in Datei ist nicht beschreibbar.

Frage dazu? Frag im Forum „Fehler & Probleme“: Zum WPDE-Forum

Häufige Fragen

Warum geht die Startseite, aber kein Beitrag?

Die Startseite ruft die index.php direkt auf. Alle anderen Adressen brauchen die Umschreibregeln, die fehlen.

Verliere ich Inhalte, wenn ich auf „Einfach“ zurücksetze?

Nein, nur die Adressen ändern sich vorübergehend. Sobald die Regeln wieder stimmen, stellst du die schöne Struktur erneut ein.

Quellen

Über den Autor: Norbert Hofmann

Norbert betreibt das WPDE-Forum und hat jahrelang im technischen Support eines Webhosters täglich WordPress-Seiten betreut. Heute arbeitet er als Cyber Defense Analyst, hat Sicherheitslücken in WordPress-Plugins gefunden (veröffentlichte CVEs) und engagiert sich mit deepfake.de gegen Betrug mit Deepfakes. Mehr auf norberthofmann.com.

Weitere Antworten