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ń
- Sprawdź
/wp-json/i konkretny endpoint oraz kod HTTP. - Porównaj żądanie z logiem access/error.
- Dla 404 sprawdź rewrite i permalinki.
- Dla 401/403 sprawdź autoryzację, nonce, WAF i nagłówki.
- Dla 500 przeanalizuj log PHP i callback endpointu.
- 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
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
Najczęściej zadawane pytania
Czy `/wp-json/` powinno być publiczne?
Część informacji i endpointów może być publiczna zgodnie z projektem WordPressa. Operacje wymagające uprawnień powinny być chronione autoryzacją.
Czy blokada REST API zwiększa bezpieczeństwo?
Globalna blokada nie zastępuje poprawnych uprawnień i może zepsuć funkcje WordPressa. Lepiej zabezpieczać konkretne operacje.
Dlaczego edytor blokowy nie zapisuje zmian?
Jedną z przyczyn może być błąd REST API, ale trzeba sprawdzić konkretny request i odpowiedź w DevTools.
Czy WAF może blokować wp-json?
Tak. Reguły bezpieczeństwa mogą fałszywie rozpoznać parametry żądania i zwrócić 403.