Die Antwort ist keine gültige JSON-Antwort

Sie klicken auf „Aktualisieren“ oder „Veröffentlichen“ – und statt zu speichern meldet WordPress: „Aktualisierung fehlgeschlagen. Die Antwort ist keine gültige JSON-Antwort.“ Dieselbe Meldung erscheint manchmal auch beim Hochladen von Bildern. Die Website selbst läuft weiter, aber Sie können nichts mehr ändern. Die gute Nachricht: Ihre Inhalte sind nicht verloren. Die Ursache liegt fast immer an einer von wenigen Stellen – hier prüfen Sie sie in der richtigen Reihenfolge.

Was die Meldung bedeutet

Der Block-Editor (Gutenberg) schickt Ihre Änderungen im Hintergrund an die REST-API von WordPress, erreichbar unter /wp-json/. Die Antwort muss im JSON-Format zurückkommen. Liefert der Server stattdessen eine Fehlerseite, eine Weiterleitung, eine Sperrseite der Firewall oder eine PHP-Warnung, kann der Editor die Antwort nicht lesen – und zeigt „keine gültige JSON-Antwort“.

Schritt 1: REST-API direkt testen

Öffnen Sie in einem neuen Tab https://ihre-domain.de/wp-json/. Das Ergebnis zeigt Ihnen, wo Sie weitersuchen müssen:

• Viel Text in geschweiften Klammern – die API funktioniert grundsätzlich. Weiter mit Schritt 3.
• „Seite nicht gefunden“ (404) – die Weiterleitungsregeln fehlen. Weiter mit Schritt 2.
• „Forbidden“ (403) oder eine Sperrseite – eine Firewall blockiert. Weiter mit Schritt 4.
• Fehlermeldung oder weiße Seite – ein Plugin- oder PHP-Fehler. Weiter mit Schritt 5.

Zusätzlich lohnt ein Blick unter Werkzeuge → Website-Zustand. Steht dort „Die REST-API hat ein unerwartetes Ergebnis geliefert“ oder „Die REST-API-Anfrage ist fehlgeschlagen“, nennt WordPress oft bereits den Fehlercode.

Schritt 2: Permalinks neu speichern

Gehen Sie zu Einstellungen → Permalinks und klicken Sie, ohne etwas zu ändern, auf „Änderungen speichern“. WordPress schreibt dabei seine Weiterleitungsregeln neu in die Datei .htaccess. Danach den Editor neu laden und erneut speichern – in vielen Fällen ist der Fehler damit bereits behoben.

Hilft das nicht, prüfen Sie per FTP die Datei .htaccess im Hauptverzeichnis Ihrer Website. Bei einer Standardinstallation muss sie diesen Block enthalten:

# 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

Laden Sie die Datei vorher herunter, um eine Kopie zu haben. Schon ein einziger Tippfehler in der .htaccess führt zu „500 Internal Server Error“ – dann ist nicht nur der Editor, sondern die ganze Website offline. Liegt WordPress in einem Unterordner, lauten RewriteBase und die letzte Zeile entsprechend anders.

Schritt 3: WordPress- und Website-Adresse prüfen

Unter Einstellungen → Allgemein stehen „WordPress-Adresse (URL)“ und „Website-Adresse (URL)“. Beide müssen exakt so lauten, wie Ihre Website tatsächlich aufgerufen wird – mit https:// und einheitlich mit oder ohne www. Steht dort noch http://, obwohl die Seite längst über HTTPS läuft, wird jede Anfrage des Editors umgeleitet und die Antwort ist kein JSON mehr. Dieser Fall tritt besonders häufig nach der Umstellung auf SSL oder nach einem Umzug auf.

Sind die Felder ausgegraut, sind die Adressen in der wp-config.php fest eingetragen (WP_HOME und WP_SITEURL) und müssen dort korrigiert werden.

Schritt 4: Sicherheits-Plugin oder Firewall des Hosters

Sicherheits-Plugins wie Wordfence, Solid Security oder All-In-One Security können die REST-API einschränken. Auch die Server-Firewall des Hosters (oft „ModSecurity“ oder „Web Application Firewall“) blockiert manchmal Anfragen, deren Inhalt verdächtig aussieht – etwa wenn ein Beitrag Code-Beispiele, bestimmte Skript-Befehle oder eingebettete Inhalte enthält. Typisches Zeichen: Nur einzelne Beiträge lassen sich nicht speichern, andere schon.

1. Prüfen Sie im Sicherheits-Plugin die Einstellungen zur REST-API und das Protokoll der blockierten Anfragen.
2. Deaktivieren Sie das Plugin testweise und versuchen Sie erneut zu speichern.
3. Klappt es dann immer noch nicht, fragen Sie beim Hoster nach, ob die Firewall Anfragen an /wp-json/ blockiert. Nutzen Sie Cloudflare, prüfen Sie dort das Firewall-Ereignisprotokoll.

Schritt 5: Plugin-Konflikt oder PHP-Fehler

Gibt ein Plugin oder das Theme eine PHP-Warnung aus, landet diese vor der eigentlichen JSON-Antwort – und macht sie unlesbar. Deaktivieren Sie unter Plugins alle Plugins und speichern Sie erneut. Funktioniert es, aktivieren Sie die Plugins einzeln wieder, bis der Fehler zurückkehrt. Das zuletzt aktivierte Plugin ist der Verursacher. Testen Sie danach auch kurz mit einem Standard-Theme wie „Twenty Twenty-Five“.

Genauer geht es mit dem Debug-Log: Tragen Sie in der wp-config.php über der Zeile „That’s all, stop editing!“ ein:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Nach dem nächsten Speicherversuch steht der Fehler in wp-content/debug.log. Setzen Sie die Werte danach wieder auf false.

Sonderfall: Fehler beim Hochladen von Bildern

Erscheint die Meldung nur beim Hochladen, ist die Datei oft zu groß für die Grenzen des Servers (upload_max_filesize, post_max_size) oder der Dateiname enthält Umlaute und Sonderzeichen. Benennen Sie die Datei um (z. B. buero-foto.jpg statt Büro Foto (1).jpg) und verkleinern Sie sie testweise. Meldet der Server „413 Request Entity Too Large“, muss das Limit beim Hoster erhöht werden.

Warum der Classic Editor keine Lösung ist

Oft wird empfohlen, einfach das Plugin „Classic Editor“ zu installieren. Damit lässt sich zwar wieder speichern, weil der alte Editor die REST-API nicht nutzt. Die Ursache bleibt aber bestehen – und betrifft weiterhin andere Funktionen, etwa die Mediathek, Formulare, Shop-Plugins oder die WordPress-App. Nutzen Sie den Classic Editor höchstens als kurze Überbrückung.

Wann Sie besser Hilfe holen sollten

Wenn Permalinks und Adressen stimmen, kein Plugin der Auslöser ist und Sie keinen Zugriff auf FTP oder die Firewall-Einstellungen des Hosters haben, wird die Suche schnell zeitraubend. Dasselbe gilt, wenn nach einer Änderung an der .htaccess die ganze Website nicht mehr lädt – dann hilft unter Umständen auch die Anleitung zu kritischen Fehlern oder zur weißen Seite weiter.