Errore 503 Service Unavailable: cosa significa e come risolverlo

L’errore 503 Service Unavailable indica che il servizio che sta gestendo la richiesta non è temporaneamente in grado di rispondere. Le cause possono essere molto diverse: sovraccarico, manutenzione, processi esauriti, errori dell’applicazione, problemi con PHP o database, servizi esterni indisponibili oppure un livello intermedio come CDN o reverse proxy.

Il punto importante è questo: il codice 503 descrive la condizione, non identifica automaticamente la causa. Per risolverlo conviene quindi evitare modifiche casuali a plugin, temi o configurazioni e capire prima quale componente della catena sta restituendo l’errore.

Se stai semplicemente visitando un sito, nella maggior parte dei casi puoi solo attendere e riprovare. Se invece il sito è tuo, occorre controllare log, risorse del server, modifiche recenti e stato dei servizi coinvolti.

Errore 503: cosa significa e perché compare

Il codice HTTP 503 Service Unavailable appartiene alla famiglia degli errori server 5xx. Secondo la specifica HTTP, segnala che il server non riesce al momento a gestire la richiesta a causa, tipicamente, di un sovraccarico temporaneo o di una manutenzione programmata.

Questo distingue il 503 da un guasto necessariamente permanente. Un server, un proxy o un altro componente dell’infrastruttura può essere perfettamente funzionante ma non avere, in quel momento, la capacità o le condizioni necessarie per completare una nuova richiesta.

Il messaggio può apparire in forme differenti:

• 503 Service Unavailable
• HTTP 503
• HTTP Error 503
• HTTP Server Error 503
• Service Temporarily Unavailable

Il significato di fondo resta lo stesso.

Se vuoi capire come si inserisce questo codice nell’intero sistema HTTP, trovi una panoramica nella guida ai codici di errore HTTP.

Differenze tra errore 500, 502, 503 e 504

Gli errori 5xx non sono equivalenti. Capire quale codice viene restituito evita di seguire procedure che intervengono sul componente sbagliato.

Codice	Cosa indica	Dove guardare per primo
500 Internal Server Error	il server ha incontrato una condizione imprevista	applicazione, codice, configurazione, log
502 Bad Gateway	un gateway o proxy ha ricevuto una risposta non valida dal server a monte	proxy, CDN, origin, server upstream
503 Service Unavailable	il servizio non può temporaneamente gestire la richiesta	capacità, manutenzione, processi, applicazione, infrastruttura
504 Gateway Timeout	un gateway non ha ricevuto in tempo la risposta dal server a monte	upstream, database, API, timeout, rete interna

Se il codice cambia durante la diagnosi, cambia anche il percorso da seguire. Per questo può essere utile confrontare il problema con le guide dedicate all’errore 500 Internal Server Error, al 502 Bad Gateway e al 504 Gateway Timeout.

Cosa indica l’header Retry-After

Una risposta 503 può includere l’header HTTP Retry-After, con il quale il server suggerisce quando il client dovrebbe riprovare.

La specifica HTTP consente di indicare una data oppure un intervallo espresso in secondi. Per esempio:

HTTP/1.1 503 Service Unavailable
Retry-After: 120

In questo caso il server suggerisce di attendere 120 secondi prima di effettuare un nuovo tentativo. L’header non è obbligatorio, ma è particolarmente utile durante una manutenzione pianificata.

Come risolvere l’errore 503: da dove iniziare

Prima di intervenire devi distinguere due situazioni completamente diverse: stai visitando il sito di qualcun altro oppure amministri il sito che restituisce l’errore?

Se non sei il proprietario, non puoi correggere un problema lato server. Se invece gestisci il sito, il 503 va trattato come un problema diagnostico: bisogna capire quale layer non riesce più a servire correttamente le richieste.

Se il 503 compare su un sito che stai visitando

Se il sito non è tuo, attendi qualche minuto e riprova. Un errore temporaneo può dipendere da manutenzione, sovraccarico o da un disservizio momentaneo dell’infrastruttura.

Puoi anche verificare se il problema riguarda soltanto una pagina oppure l’intero dominio. Se il servizio dispone di una pagina di stato ufficiale, controllala prima di modificare browser, DNS o configurazioni locali.

Svuotare continuamente cache e cookie non è normalmente la prima soluzione a un vero 503, perché il codice viene restituito dal lato server o da un componente che si trova davanti al server. Le verifiche locali hanno senso soprattutto quando il comportamento è anomalo soltanto dal tuo dispositivo o dalla tua rete.

Se il sito è tuo: controlla stato del server, log e risorse

Quando amministri il sito, la prima domanda non dovrebbe essere “quale plugin devo disattivare?”, ma “chi sta restituendo il 503?”.

Una moderna richiesta web può attraversare più componenti:

browser → CDN/WAF → reverse proxy → web server → PHP/applicazione → database/API

Ognuno di questi livelli può essere coinvolto.

Questa tabella aiuta a scegliere il primo controllo:

Sintomo	Primo layer da verificare	Controllo iniziale
Tutto il sito restituisce 503	hosting/server	stato servizio, log, CPU, memoria, processi
Il problema nasce dopo un aggiornamento	applicazione	modifica recente, log, rollback
Compare solo su WordPress	PHP/WordPress	log PHP, plugin, tema, cron
Compare dietro CDN o proxy	edge/origin	stato CDN, origin, log proxy
Avviene durante picchi di traffico	capacità	worker, processi, connessioni, CPU
È una manutenzione programmata	infrastruttura	configurazione del 503 e Retry-After

Se hai accesso alla shell, puoi controllare rapidamente gli header restituiti senza scaricare l’intera pagina:

curl -sS -D - -o /dev/null https://example.com/

Il comando non individua la causa, ma permette di verificare il codice HTTP e gli eventuali header diagnostici.

Subito dopo passa ai log del livello che sta fallendo: web server, PHP, applicazione, database, reverse proxy, CDN o WAF. Un log con un errore coincidente con il momento del 503 vale molto più di una supposizione basata sul solo messaggio visualizzato nel browser.

Verifica modifiche, deploy e configurazioni recenti

La cronologia degli interventi è uno degli indizi più utili.

Se il problema è iniziato immediatamente dopo:

• un aggiornamento;
• un deploy;
• una modifica alla configurazione;
• l’installazione di un’estensione;
• un cambio di versione PHP;
• una modifica al firewall o alla CDN;

prova prima a ripristinare in modo controllato quella singola modifica.

Il rollback è molto più informativo del cambiare contemporaneamente cinque impostazioni: se il servizio torna disponibile, hai ristretto immediatamente il campo della diagnosi.

Su un sito importante è preferibile eseguire questi test in staging o partire da un backup recente, soprattutto quando devi intervenire sui file dell’applicazione.

Le cause più comuni di un errore 503

Non esiste una singola causa valida per tutti i siti. Due pagine che mostrano lo stesso 503 Service Unavailable possono avere problemi completamente diversi.

Sovraccarico e limiti di CPU, memoria, processi o connessioni

Un server può avere risorse insufficienti per gestire le richieste in arrivo, ma “risorse” non significa soltanto RAM.

Il collo di bottiglia potrebbe riguardare:

• CPU;
• memoria;
• processi disponibili;
• PHP worker;
• connessioni simultanee;
• pool del database;
• code interne;
• limiti imposti dal piano hosting.

Per questo un aumento di traffico non dimostra da solo che il problema sia la memoria, così come un traffico apparentemente normale non esclude un limite infrastrutturale.

Un singolo processo bloccato, una query molto lenta o un numero ridotto di worker disponibili può esaurire la capacità del servizio anche senza un incremento evidente delle visite.

Controlla quindi le metriche del server nello stesso intervallo temporale in cui sono comparsi i 503. La correlazione fra errore e saturazione di una risorsa è molto più utile del semplice dato sul traffico.

Manutenzione e indisponibilità temporanea

Il 503 è anche il codice corretto per comunicare una indisponibilità intenzionalmente temporanea.

Durante una manutenzione programmata, il sito può mostrare una pagina informativa agli utenti e contemporaneamente restituire un vero status HTTP 503, eventualmente accompagnato da Retry-After.

Il dettaglio conta: mostrare graficamente “sito in manutenzione” restituendo invece 200 OK comunica ai client e ai crawler qualcosa di diverso da una reale indisponibilità temporanea.

Errori dell’applicazione, PHP, database o servizi esterni

L’applicazione può diventare incapace di servire nuove richieste anche se il server web continua a funzionare.

Può succedere, per esempio, quando:

• PHP esaurisce i worker disponibili;
• un processo entra in errore ripetutamente;
• il database smette di rispondere correttamente;
• una query occupa risorse per troppo tempo;
• un servizio esterno indispensabile è indisponibile;
• un job in background consuma una quantità anomala di risorse.

In queste condizioni il 503 è spesso l’effetto visibile di un problema che si trova più in profondità. È per questo che aumentare arbitrariamente memoria o timeout può limitarsi a spostare il problema senza correggerne l’origine.

CDN, reverse proxy, firewall e server upstream

Se utilizzi una CDN, un WAF, un load balancer o un reverse proxy, il messaggio che vedi può essere stato generato prima che la richiesta raggiungesse realmente l’applicazione.

Un 503 può quindi dipendere da un origin non raggiungibile, da un pool di backend senza server disponibili, da regole di protezione o da un meccanismo di rate limiting.

Confronta i log e le metriche dei diversi livelli. Se il proxy registra 503 ma l’applicazione non vede neppure le richieste corrispondenti, la diagnosi cambia completamente.

Questo è anche il motivo per cui non conviene attribuire automaticamente il problema a WordPress solo perché il sito utilizza WordPress.

Picchi di traffico e attacchi DDoS

Un aumento improvviso delle richieste può esaurire la capacità dell’infrastruttura. Il picco può essere legittimo — per esempio una campagna, una newsletter o una menzione importante — oppure derivare da traffico automatizzato e attacchi.

Un attacco DDoS può contribuire a rendere il servizio indisponibile oppure far intervenire sistemi di protezione a monte, ma un 503 da solo non dimostra che sia in corso un attacco.

Per arrivare a questa conclusione servono altri segnali: distribuzione delle richieste, indirizzi IP, user agent, pattern degli endpoint richiesti, log del firewall e andamento delle risorse.

Se l’analisi punta realmente in quella direzione, puoi approfondire le strategie per prevenire e gestire gli attacchi DDoS su WordPress.

Errore 503 su WordPress: cosa controllare

Su WordPress plugin, tema, PHP e processi in background possono certamente contribuire a un 503, ma non vanno considerati automaticamente la causa principale.

Prima controlla hosting e log. Poi restringi la diagnosi a WordPress se gli indizi portano effettivamente all’applicazione.

Plugin e aggiornamenti recenti

Se il problema è comparso immediatamente dopo l’installazione o l’aggiornamento di un plugin, il primo intervento sensato è annullare quella modifica, non cancellare definitivamente il plugin.

Se riesci ad accedere alla dashboard, disattivalo e verifica il comportamento.

Se invece il backend non è raggiungibile e hai già un backup, puoi usare SFTP o il file manager dell’hosting per rinominare temporaneamente la cartella del plugin sospetto.

Quando non sai quale componente sia coinvolto, rinominare temporaneamente l’intera directory wp-content/plugins può essere utilizzato come test di isolamento, ma è un intervento più invasivo: disattiva contemporaneamente le estensioni standard e può modificare altre funzionalità del sito.

Una volta capito che i plugin sono effettivamente coinvolti, ripristina il nome della directory e individua il componente specifico in modo progressivo.

Tema e codice personalizzato

Lo stesso principio vale per il tema.

Non eliminare il tema attivo solo per vedere se il 503 sparisce. Se hai una copia di staging, una dashboard accessibile o WP-CLI, passa temporaneamente a un tema predefinito disponibile nell’installazione e verifica nuovamente il sito.

Se l’errore scompare, controlla prima di tutto le modifiche recenti, gli hook personalizzati e il codice PHP del tema.

Anche snippet inseriti in functions.php, mu-plugin e plugin personalizzati devono rientrare nella diagnosi quando la cronologia delle modifiche li rende sospetti.

Aggiornamenti interrotti e modalità manutenzione

Durante gli aggiornamenti, WordPress utilizza un file .maintenance nella directory principale per attivare temporaneamente la modalità manutenzione.

Il core di WordPress restituisce in questa condizione HTTP 503 e invia anche un header Retry-After.

Se un aggiornamento viene interrotto, il file potrebbe restare presente più del previsto. Prima di eliminarlo verifica che non sia ancora in corso un reale processo di aggiornamento. Se il processo è terminato o fallito e il sito rimane bloccato, controlla la directory principale dell’installazione e rimuovi .maintenance, quindi verifica lo stato dell’aggiornamento prima di ripeterlo. WordPress documenta esplicitamente questo comportamento.

Come usare WP_DEBUG e i log senza esporre errori ai visitatori

Se gli indizi portano a PHP o a WordPress, puoi raccogliere informazioni attraverso il sistema di debug.

WordPress consiglia di eseguire le modifiche su staging o dopo un backup e avverte che gli strumenti di debug sono pensati principalmente per ambienti di sviluppo e test, non per restare attivi permanentemente su un sito live.

Nel file wp-config.php puoi usare:

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

WP_DEBUG_LOG registra gli errori normalmente in wp-content/debug.log, mentre WP_DEBUG_DISPLAY impostato su false impedisce di mostrarli direttamente nelle pagine.

Dopo aver riprodotto il problema, controlla il log cercando fatal error, timeout, problemi di memoria o riferimenti al componente modificato di recente.

Una guida più completa è disponibile nell’approfondimento sul debug di WordPress.

Quando hai terminato la diagnosi, disattiva il debug e gestisci il file di log in modo che non rimanga inutilmente accessibile o in crescita.

Quando controllare WordPress Heartbeat

La WordPress Heartbeat API effettua comunicazioni periodiche fra browser e server e supporta funzioni come autosave e aggiornamenti dell’interfaccia amministrativa. Fa parte del funzionamento normale di WordPress.

Non la disabiliterei quindi come soluzione standard a un errore 503.

Ha senso analizzarla soltanto quando log e metriche mostrano realmente un carico anomalo riconducibile a richieste AJAX/Heartbeat. In quel caso puoi valutare frequenza, utenti simultanei nell’amministrazione e altri processi che utilizzano admin-ajax.php.

Disabilitarla globalmente senza evidenza può mascherare il vero collo di bottiglia e interferire con funzioni che ne dipendono.

Errore 503 e SEO: cosa succede se il problema continua

Un 503 occasionale non equivale automaticamente a un problema SEO permanente. Il suo significato è proprio quello di una indisponibilità temporanea.

La situazione cambia quando gli errori diventano frequenti o persistenti. Google documenta che i problemi di disponibilità possono ridurre la quantità di crawling effettuata e che Googlebot rallenta quando rileva che un server sta avendo difficoltà a rispondere.

In pratica, un breve intervento di manutenzione gestito correttamente è molto diverso da un sito che restituisce 503 per periodi prolungati.

Per controllare se Google sta incontrando problemi di disponibilità puoi utilizzare il report Statistiche di scansione di Search Console e confrontarlo con i log server. Per siti grandi o con problemi persistenti di capacità può essere utile approfondire anche come funziona realmente il crawl budget.

Come Google gestisce le risposte 5xx

Quando Googlebot riceve errori di disponibilità, tende a ridurre l’attività di crawling per evitare di aggravare il problema. Se l’indisponibilità continua, l’impatto può estendersi alla presenza degli URL nell’indice. Google raccomanda quindi di usare il 503 come segnale temporaneo, non come stato permanente del sito.

Questo è un altro motivo per cui è importante correggere la causa reale invece di configurare il server affinché restituisca artificialmente un 503 per nascondere un altro problema.

Quando usare volontariamente un 503 per una manutenzione temporanea

Se devi rendere temporaneamente indisponibile un sito, restituire un vero 503 Service Unavailable è più corretto che mostrare semplicemente una pagina di manutenzione con stato 200 OK.

Google ha storicamente raccomandato il 503 proprio perché comunica ai crawler che l’indisponibilità è temporanea e che il contenuto normale dovrebbe tornare disponibile.

Quando conosci una durata indicativa puoi aggiungere anche Retry-After.

Il principio è semplice:

manutenzione temporanea → pagina utile per l’utente + vero status 503 → ritorno a 200 quando il servizio è nuovamente disponibile.

Come prevenire nuovi errori 503

Prevenire tutti i 503 non è realistico: in alcune situazioni il codice è una risposta perfettamente corretta. L’obiettivo è evitare che un’indisponibilità inattesa rimanga invisibile fino a quando viene segnalata dagli utenti.

Monitorare uptime, log e utilizzo delle risorse

Un sistema di monitoraggio dovrebbe almeno permetterti di capire:

• quando il sito ha iniziato a non rispondere;
• quale codice HTTP viene restituito;
• quanto dura l’evento;
• quali risorse erano sature;
• quali errori comparivano nei log;
• quale modifica o processo era attivo nello stesso momento.

La correlazione temporale è essenziale. Sapere che “la CPU è stata alta oggi” serve poco; sapere che i PHP worker erano esauriti esattamente durante i 503 è già un’indicazione diagnostica molto più forte.

Preparare alert, capacità e rollback dopo gli aggiornamenti

Per siti importanti conviene avere una procedura di rollback prima di modificare produzione.

Backup, staging, monitoraggio degli aggiornamenti e log centralizzati riducono il tempo necessario per distinguere rapidamente fra:

problema dell’applicazione → problema dell’infrastruttura → problema di un servizio esterno

Quando il sito cresce, rivedi anche la capacità del piano hosting, il numero di processi disponibili e il comportamento sotto carico reale. Aumentare risorse può essere corretto quando il collo di bottiglia è realmente la capacità; non dovrebbe però sostituire l’analisi di query lente, errori applicativi o processi inefficienti.

Conclusione

L’errore 503 Service Unavailable non ti dice quale componente è guasto: ti dice che, in quel momento, il servizio che risponde alla richiesta non è in grado di gestirla.

Per questo la strategia migliore non è partire subito da plugin o cache, ma individuare il layer che genera il 503, controllare log e risorse e collegare l’errore a eventuali modifiche recenti.

Se il problema è un sovraccarico, devi individuare quale risorsa si esaurisce. Se nasce da un deploy o da un aggiornamento, conviene eseguire un rollback controllato. Se è WordPress, plugin, tema, PHP e processi in background vanno verificati soltanto dopo aver raccolto abbastanza indizi. Se invece l’indisponibilità è pianificata, un 503 correttamente configurato è esattamente il segnale HTTP che serve.

Quando un sito WordPress continua a restituire errori 503 e la causa non emerge chiaramente da log e controlli di base, evitare tentativi distruttivi diventa ancora più importante. In questi casi può avere senso passare a una diagnosi dell’intera installazione e dell’ambiente hosting; il servizio di assistenza WordPress di Creativemotions copre anche analisi di malfunzionamenti, log, risorse e problemi di performance.