REST API WordPress non disponibile: diagnosi e ripristino

In breve: La REST API WordPress non disponibile può impedire all’editor a blocchi, a Site Health, alle applicazioni esterne e a molti plugin di comunicare con il sito.

REST API WordPress non disponibile

Questa guida approfondisce REST API WordPress non disponibile con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.

Che cosa significa

Una risposta JSON pubblica per contenuti pubblici è normale. Le operazioni riservate richiedono autenticazione e permessi appropriati.

Bloccare interamente la REST API può rompere funzioni del core. È preferibile limitare endpoint o accessi specifici quando esiste una necessità reale.

Come riconoscere il problema

• Site Health segnala errore REST API.
• L’editor mostra aggiornamento fallito.
• `/wp-json/` restituisce 404, 403 o redirect.
• Un plugin non comunica con WordPress.
• Le richieste autenticate ricevono rest_forbidden.

Cause più frequenti

1. Permalink non rigenerati

Le regole rewrite non instradano `/wp-json/`. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.

2. Plugin di sicurezza

Un componente blocca endpoint o utenti non autenticati.

3. WAF o ModSecurity

Parametri JSON e metodi HTTP vengono filtrati.

4. Redirect

HTTP/HTTPS o www creano loop o cambiano host.

5. Errore PHP

La richiesta REST termina con 500 o output non JSON.

6. Autenticazione o nonce

L’utente non ha permessi o il nonce è scaduto.

Diagnosi passo per passo

1. Apri l’indice. Visita `/wp-json/` e registra codice e contenuto. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
2. Controlla Site Health. Leggi endpoint e messaggio completo. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
3. Rigenera permalink. Salva la struttura dopo backup di.htaccess. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
4. Controlla log. Cerca fatal error e ModSecurity. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
5. Verifica plugin di sicurezza. Prova in staging o disattiva una sola regola. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
6. Controlla redirect e URL. home e siteurl devono essere coerenti. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
7. Testa autenticazione. Distingui endpoint pubblico da operazione riservata. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.

Procedura di risoluzione

1. Ripristina rewrite. Rigenera.htaccess o regole del web server. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
2. Correggi il plugin. Aggiorna o configura l’eccezione minima. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
3. Richiedi analisi WAF. Fornisci endpoint, metodo, orario e rule id. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
4. Allinea URL. Correggi protocollo e hostname. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
5. Risolve l’errore PHP. Intervieni sul componente indicato dal log. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
6. Usa autenticazione supportata. Nonce per sessioni WordPress o Application Passwords su HTTPS per integrazioni compatibili. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
7. Limita senza bloccare il core. Proteggi endpoint sensibili invece dell’intera API. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.

Domande frequenti

Guide Xlogic correlate

• Mixed content in WordPress dopo HTTPS: come risolverlo
• WordPress: risposta non è una risposta JSON valida
• Errore 429 Too Many Requests: cause e rimedi

Fonti tecniche

• WordPress REST API Handbook
• WordPress Application Passwords