REST API WordPress nie działa – jak naprawić błędy wp-json, edytora i integracji?

REST API jest używane przez WordPressa i wiele rozszerzeń do komunikacji w formacie JSON. Problemy z `/wp-json/` mogą powodować błędy edytora blokowego, Site Health, aplikacji zewnętrznych, integracji i części panelu. Kod odpowiedzi ma znaczenie: 404 sugeruje routing, 401/403 autoryzację lub blokadę, a 500 błąd aplikacji.

Szybka odpowiedź

Otwórz `/wp-json/` i konkretny endpoint, który nie działa. Sprawdź status HTTP i treść odpowiedzi. Następnie porównaj request w DevTools z logiem serwera. Nie „odblokowuj całego REST API” bez potrzeby — część endpointów publicznych jest normalna, a chronione powinny wymagać właściwych uprawnień.

404 i reguły rewrite

Jeżeli `/wp-json/` zwraca 404 po migracji lub zmianie serwera, sprawdź permalinki i routing. Na Nginx potrzebne jest poprawne przekazanie żądania do `index.php`. Jeśli główne strony również mają problem z ładnymi URL-ami, REST API jest prawdopodobnie kolejnym objawem tej samej konfiguracji.

401 i 403 – autoryzacja albo WAF

Chroniony endpoint powinien odrzucać użytkownika bez uprawnień. Problem pojawia się, gdy poprawnie zalogowany edytor lub integracja nadal dostaje blokadę. Sprawdź nonce, cookies, nagłówek Authorization, reguły WAF i wtyczki bezpieczeństwa. Site Health ma osobny test nagłówka autoryzacji, co pomaga wskazać część problemów.

500 – błąd kodu endpointu

Własny endpoint lub wtyczka może generować fatal error. Wtedy analizuj log PHP dokładnie jak przy innym żądaniu. Nie zakładaj, że skoro URL zaczyna się od `/wp-json/`, problem jest „w API WordPressa”. Często błąd znajduje się w callbacku konkretnego rozszerzenia.

CORS przy integracji z inną domeną

Jeżeli przeglądarka wysyła request z innej domeny, dochodzi polityka CORS. Błąd w konsoli nie zawsze oznacza, że serwer nie odpowiedział; odpowiedź może istnieć, ale przeglądarka nie udostępnia jej skryptowi z powodu brakujących nagłówków. Ustaw CORS precyzyjnie dla zaufanych originów zamiast `*` dla endpointów wymagających uwierzytelnienia.

Nie wyłączaj REST API globalnie „dla bezpieczeństwa”

WordPress i nowoczesny edytor korzystają z REST API. Globalna blokada może zepsuć panel i integracje, a nie jest substytutem poprawnej kontroli uprawnień. Lepszy model to zabezpieczenie konkretnych endpointów, poprawne capability checks, nonce/tokeny oraz filtrowanie ruchu na poziomie WAF.

Jak potwierdzić, że naprawa naprawdę działa?

Po naprawie REST API przetestuj zarówno publiczny odczyt, jak i operację wymagającą uwierzytelnienia. Otwórz edytor blokowy, zapisz szkic i sprawdź requesty w Network. Jeżeli problem dotyczył integracji, odtwórz jej realny request z właściwym nagłówkiem Authorization. Samo `GET /wp-json/` 200 nie potwierdza, że chroniony endpoint działa.

Co obserwować po zmianie?

Monitoruj 401/403/5xx dla `/wp-json/` oraz błędy JavaScript w panelu. Po zmianie WAF upewnij się, że nie otworzyłeś endpointów, które wcześniej wymagały uprawnień. Jeśli korzystasz z CORS, testuj z docelowego originu i z nieautoryzowanej domeny — poprawna konfiguracja powinna przepuszczać tylko zamierzony scenariusz.

Kiedy przekazać temat dalej?

Eskaluj, gdy problem dotyczy autoryzacji OAuth/tokenów, niestandardowego endpointu modyfikującego dane albo integracji płatniczej. W tych miejscach „niech zwraca 200” nie jest wystarczającym kryterium; trzeba sprawdzić uprawnienia, integralność danych i obsługę błędów.

Praktyczny scenariusz diagnostyczny

Praktyczny scenariusz: edytor blokowy zgłasza „publikacja nie powiodła się”, a frontend działa. Otwórz Site Health i sprawdź REST API, ale nie kończ na komunikacie. W narzędziach deweloperskich zobacz request do `/wp-json/`, status i treść odpowiedzi. 401/403 kieruje uwagę na uwierzytelnienie lub WAF; 500 na PHP/wtyczkę; 404 na routing; timeout na wydajność. Jeśli problem pojawił się po wdrożeniu zabezpieczeń, przygotuj minimalny wyjątek dla prawidłowego endpointu zamiast wyłączać całą ochronę. Po naprawie przetestuj zapis, media, edycję kilku typów treści i integracje, które używają REST API. WordPress coraz mocniej opiera panel i ekosystem na REST, więc „strona się otwiera” nie jest wystarczającym testem zdrowia aplikacji.

Bezpieczna kolejność działań

1. Sprawdź `/wp-json/` i konkretny endpoint oraz kod HTTP.
2. Porównaj żądanie z logiem access/error.
3. Dla 404 sprawdź rewrite i permalinki.
4. Dla 401/403 sprawdź autoryzację, nonce, WAF i nagłówki.
5. Dla 500 przeanalizuj log PHP i callback endpointu.
6. Po naprawie przetestuj edytor, Site Health i wszystkie integracje korzystające z API.

Czego nie robić

Nie otwieraj wszystkich endpointów bez uwierzytelnienia, aby „zniknął 403”. Nie wyłączaj też całego REST API, bo nowoczesny WordPress i wiele wtyczek realnie go potrzebują.

Powiązane poradniki HeatLogic

• [404 po permalinkach](/blog/wordpress-404-po-zmianie-permalinkow)
• [Błąd 403 WordPress](/blog/blad-403-wordpress)
• [Loopback WordPress](/blog/loopback-request-wordpress)
• [Hosting i opieka](/hosting-i-opieka)

Potrzebujesz pomocy?

Jeżeli REST API blokuje edytor lub integrację, możemy prześledzić endpoint, uwierzytelnienie, WAF i callback PHP, a następnie przywrócić komunikację bez niepotrzebnego otwierania całej aplikacji.

Źródła techniczne

• [Site Health REST tests](https://developer.wordpress.org/rest-api/reference/wp-site-health-tests/)