Updating failed. The response is not a valid JSON response

Klikasz Zaktualizuj albo Opublikuj, a na dole edytora wyskakuje czerwony komunikat: Updating failed. The response is not a valid JSON response. W polskim panelu brzmi to mniej więcej tak: „Aktualizacja nie powiodła się. Odpowiedź nie jest prawidłową odpowiedzią JSON”. Zmiany się nie zapisują, a czasem ten sam błąd pojawia się przy wgrywaniu zdjęć.

Dobra wiadomość: to prawie nigdy nie jest problem z samą treścią wpisu ani z WordPressem „jako takim”. Zła: komunikat nic nie mówi o przyczynie. Poniżej pokazuję ścieżkę, którą sam przechodzę u klientów. Zaczyna się od jednego sprawdzenia, które w 2 minuty zawęża listę podejrzanych do jednej, dwóch rzeczy.

W skrócie: najczęściej winne są bezpośrednie odnośniki (.htaccess), zapora hostingu lub wtyczka bezpieczeństwa, błędy PHP wypisywane na ekran, niezgodny adres witryny (http/https) albo wtyczka blokująca REST API. Pierwszy krok zawsze ten sam: sprawdź w narzędziach przeglądarki, jaki kod odpowiedzi zwrócił serwer.

Co właściwie oznacza ten komunikat

Edytor blokowy (Gutenberg) nie zapisuje wpisu „klasycznie”, przez przeładowanie strony. Wysyła w tle zapytanie do REST API, np. na adres /wp-json/wp/v2/posts/123, i oczekuje odpowiedzi w formacie JSON.

Jeśli zamiast JSON-a dostanie cokolwiek innego (stronę błędu 404, blokadę z zapory, przekierowanie, ostrzeżenie PHP doklejone przed danymi), nie umie tego odczytać i pokazuje właśnie ten komunikat. Czyli: serwer odpowiedział, ale nie tym, czego edytor się spodziewał. Naszym zadaniem jest zobaczyć, czym odpowiedział.

Zanim zaczniesz: zabezpiecz treść

• Nie odświeżaj strony. Zaznacz całą treść w edytorze (Ctrl+A, czasem dwa razy) i skopiuj ją do notatnika. Autozapis też korzysta z REST API, więc mógł nic nie zapisać.
• Jeśli masz zamiar grzebać w plikach lub wtyczkach, zrób kopię zapasową. Jak wrócić do działającej wersji, gdy coś pójdzie nie tak, opisałem w tekście o stronie, która rozsypała się po aktualizacji.

Krok 1: zobacz, co naprawdę odpowiada serwer

To najważniejszy krok w całym tekście. Zajmuje 2 minuty i oszczędza godziny zgadywania.

1. W edytorze wpisu naciśnij F12 (lub prawy przycisk myszy → Zbadaj).
2. Przejdź do zakładki Sieć (Network) i w polu filtra wpisz wp-json.
3. Kliknij w edytorze Zaktualizuj, żeby wywołać błąd jeszcze raz.
4. Na liście pojawi się zapytanie, zwykle podświetlone na czerwono. Kliknij je.
5. Zanotuj kod statusu (zakładka Nagłówki) i zajrzyj do zakładki Odpowiedź, czyli tego, co serwer faktycznie odesłał.

Teraz porównaj wynik z tabelą:

Krok 2: sprawdź, czy REST API w ogóle działa

Dwa szybkie testy, bez żadnych wtyczek:

• Narzędzia → Kondycja witryny. Jeśli widzisz komunikat typu „Interfejs REST API napotkał błąd” albo „napotkał nieoczekiwany wynik”, masz potwierdzenie, że problem jest po stronie REST API, a nie edytora. Rozwiń komunikat, często jest tam kod błędu.
• Otwórz w przeglądarce adres https://twojadomena.pl/wp-json/. Powinieneś zobaczyć długi blok tekstu w formacie JSON. Jeśli widzisz stronę 404 albo stronę główną, otwórz jeszcze https://twojadomena.pl/?rest_route=/. Jeśli ten drugi adres działa, a pierwszy nie, winne są przepisywania adresów (przyczyna 1).

Przyczyna 1: bezpośrednie odnośniki i .htaccess (404)

Najczęstsza i najprostsza w naprawie. Zdarza się po migracji strony, zmianie hostingu, „sprzątaniu” pliku .htaccess albo po infekcji, która ten plik nadpisała.

Co zrobić:

1. Wejdź w Ustawienia → Bezpośrednie odnośniki i kliknij Zapisz zmiany, niczego nie zmieniając. WordPress przebuduje reguły przepisywania adresów. W połowie przypadków to koniec problemu.
2. Jeśli nie pomogło, sprawdź plik .htaccess w głównym katalogu strony (serwer Apache lub LiteSpeed). Standardowy blok WordPressa wygląda tak:

# 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

Jeśli WordPress stoi w podkatalogu (np. /sklep/), RewriteBase i ostatnia reguła muszą ten podkatalog uwzględniać.

Na serwerze nginx plik .htaccess nie działa. Tam w konfiguracji musi być reguła przekazująca adresy do WordPressa, zwykle ustawia ją hosting:

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

Jeśli w .htaccess widzisz dziwne, długie reguły z przekierowaniami na obce domeny, to już nie jest problem z edytorem. Zajrzyj do tekstu jak odwirusować stronę na WordPressie.

Przyczyna 2: zapora blokuje zapis (403)

Typowy objaw: błąd pojawia się tylko przy niektórych wpisach, a inne zapisują się normalnie. Zapora aplikacyjna (ModSecurity na hostingu, Cloudflare WAF, Wordfence, inne wtyczki bezpieczeństwa) widzi w treści coś, co wygląda jak atak, i odcina zapytanie.

Co najczęściej uruchamia blokadę:

• fragmenty kodu we wpisie (<script>, <iframe>, PHP, SQL),
• frazy przypominające zapytania do bazy, np. „select … from”, „union”,
• długie adresy z parametrami, osadzenia z zewnętrznych serwisów,
• bardzo długa treść wklejona na raz z Worda lub innego edytora.

Jak to potwierdzić: utwórz nowy wpis z samym tytułem i zapisz go. Działa? Wklejaj treść problematycznego wpisu po połowie, zapisując za każdym razem. W kilku krokach znajdziesz akapit, który wywołuje blokadę.

Jak naprawić:

• Wtyczka bezpieczeństwa: sprawdź jej log zablokowanych zapytań. Wordfence ma tryb uczenia i możliwość dodania reguły do listy dozwolonych.
• Cloudflare: Security → Events. Zobaczysz, która reguła zadziałała, i możesz dodać wyjątek dla ścieżki /wp-json/ przy zalogowanym użytkowniku.
• ModSecurity na hostingu: napisz do supportu z dokładną godziną błędu i adresem zapytania. Poproś o wyłączenie konkretnej reguły (podadzą jej numer) dla Twojej domeny, a nie całej zapory.

Przyczyna 3: PHP wypisuje błędy do odpowiedzi

Serwer zwraca 200, czyli „wszystko OK”, ale w zakładce Odpowiedź na samym początku widzisz coś takiego:

Deprecated: Creation of dynamic property ... in /wp-content/plugins/...
{"id":123,"date":"...

JSON jest w środku, ale doklejone przed nim ostrzeżenie psuje cały format. Zdarza się to bardzo często po aktualizacji PHP do nowszej wersji, gdy jakaś wtyczka lub motyw nie jest z nią w pełni zgodny, a na serwerze włączone jest wyświetlanie błędów.

Szybka naprawa: przestaw WordPressa tak, żeby błędy trafiały do pliku, a nie na ekran. W wp-config.php, nad linijką „That’s all, stop editing!”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Błędy będą zapisywane w wp-content/debug.log. Edytor zacznie działać, a z logu dowiesz się, która wtyczka je generuje. Zaktualizuj ją albo zgłoś problem autorowi. Po diagnozie ustaw WP_DEBUG z powrotem na false.

Rzadszy wariant: w odpowiedzi jest pusta linia lub niewidoczny znak przed JSON-em. Winne bywają spacje albo znak BOM przed <?php w wp-config.php lub functions.php motywu, najczęściej po edycji pliku w nieodpowiednim edytorze.

Jeśli w odpowiedzi widzisz pełną stronę z komunikatem „Na tej witrynie wystąpił błąd krytyczny”, przejdź od razu do tekstu jak naprawić błąd krytyczny w WordPressie.

Przyczyna 4: adres witryny, SSL i przekierowania (301, 302)

Edytor wysyła zapytanie na adres zapisany w ustawieniach. Jeśli serwer przekierowuje je gdzie indziej, np. z http na https albo z wersji bez www na wersję z www, po drodze gubią się dane zapisu i zamiast JSON-a wraca przekierowanie.

Co sprawdzić:

• Ustawienia → Ogólne: pola Adres WordPressa (URL) i Adres witryny (URL) muszą być identyczne co do protokołu i www, i zgodne z adresem, pod którym faktycznie otwierasz panel.
• Czy certyfikat SSL jest poprawnie zainstalowany i czy panel otwierasz przez https. Więcej o objawach w tekście o brakującym certyfikacie SSL.
• Cloudflare w trybie SSL Flexible w połączeniu z wymuszaniem https na serwerze potrafi tworzyć pętle przekierowań. Tryb Full (strict) jest bezpieczniejszy.

Przyczyna 5: wtyczka lub motyw

Podejrzani w pierwszej kolejności:

• wtyczki, które wyłączają REST API lub ograniczają do niego dostęp (osobne albo jako opcja we wtyczce bezpieczeństwa),
• wtyczki cache i optymalizacji, które buforują adresy /wp-json/ albo „optymalizują” odpowiedzi,
• własny kod w functions.php lub wtyczce „snippets”, który modyfikuje odpowiedzi REST API,
• wtyczki, które przy zapisie wpisu robią coś ciężkiego: generują mapę strony, wysyłają wpis do zewnętrznych serwisów, przeliczają analizy SEO.

Jak testować bezpiecznie: zamiast wyłączać wtyczki na działającej stronie (co w sklepie oznacza ryzyko dla klientów), użyj wtyczki Health Check & Troubleshooting. Jej tryb rozwiązywania problemów wyłącza wtyczki i przełącza motyw tylko dla Ciebie, odwiedzający widzą normalną stronę. Włączaj wtyczki po jednej, aż błąd wróci. Ostatnia włączona to winowajca.

Przyczyna 6: serwer nie wyrabia (500, 502, 504, 413)

• 500: błąd PHP po stronie serwera. Włącz log jak w przyczynie 3 i sprawdź debug.log. Jeśli widzisz Allowed memory size exhausted, przeczytaj jak zwiększyć limit pamięci PHP i kiedy to nie pomoże.
• 502 / 504: zapis trwa za długo i serwer przerywa połączenie. Zwykle przy bardzo długich wpisach albo gdy wtyczki robią ciężkie operacje przy każdym zapisie. Sprawdź to w trybie z przyczyny 5.
• 413: zapytanie jest za duże dla serwera (na nginx limit client_max_body_size). Zdarza się przy ogromnych wpisach lub wklejonych obrazkach zakodowanych w treści. Limit podnosi hosting.

Przyczyna 7: wygasła sesja lub cache w panelu

Jeśli edytor był otwarty przez wiele godzin, token bezpieczeństwa (nonce) mógł wygasnąć. Odpowiedź zawiera wtedy kod rest_cookie_invalid_nonce albo status 401 lub 403.

• Skopiuj treść, odśwież stronę, w razie potrzeby zaloguj się ponownie i wklej treść z powrotem.
• Jeśli problem wraca szybko, sprawdź, czy cache (wtyczka, serwer, Cloudflare) nie buforuje /wp-admin/, /wp-json/ i stron dla zalogowanych.
• Jeśli masz przy tym kłopoty z samym logowaniem, zajrzyj do tekstu o pętli logowania do wp-admin.

A może po prostu zainstalować Classic Editor?

To popularna „rada z forum” i faktycznie działa: klasyczny edytor zapisuje wpisy w inny sposób, bez REST API, więc komunikat znika. Tyle że problem zostaje. Z REST API korzysta dużo więcej rzeczy: panel WooCommerce, kondycja witryny, aplikacja mobilna WordPressa, formularze, integracje, wiele wtyczek. Traktuj to jako rozwiązanie awaryjne na jeden dzień, żeby opublikować pilny wpis, a nie jako naprawę.

Ściągawka: kolejność działań

1. Skopiuj treść wpisu w bezpieczne miejsce.
2. F12 → Sieć → filtr wp-json → zanotuj kod statusu i treść odpowiedzi.
3. Otwórz /wp-json/ i /?rest_route=/, zajrzyj do Kondycji witryny.
4. Zapisz ponownie bezpośrednie odnośniki.
5. Sprawdź, czy adresy w Ustawieniach → Ogólne są zgodne (https, www).
6. Przestaw wyświetlanie błędów PHP do pliku logu.
7. Sprawdź log zapory lub wtyczki bezpieczeństwa (szczególnie gdy błąd dotyczy tylko niektórych wpisów).
8. Przetestuj wtyczki w trybie Health Check & Troubleshooting.
9. Przy 500, 502, 504: sprawdź debug.log i logi serwera.

Kiedy warto oddać to komuś

Większość przypadków da się zamknąć w kwadrans, korzystając z tej listy. Są jednak sytuacje, w których lepiej nie tracić dnia: hosting odpowiada, że „u nich wszystko działa”, a Ty widzisz 403; błąd pojawia się raz na kilka zapisów i nie da się go złapać; albo to sklep, w którym wyłączanie wtyczek na próbę oznacza ryzyko dla zamówień.

W takich sytuacjach pomagam osobiście. Zaczynam od logów serwera i zapory, a nie od wyłączania wszystkiego po kolei, więc zwykle przyczyna jest znana szybko i naprawa nie dotyka reszty strony. Napisz do mnie, opisz, co widzisz w zakładce Sieć, i podeślij kod statusu.

Może Ci się też przydać

• Biała strona (WSOD) w WordPressie: szybka ścieżka diagnostyczna
• Błąd nawiązywania połączenia z bazą danych: ścieżka diagnostyczna
• Przyczyny awarii strony internetowej: 5 najczęstszych problemów