504 Gateway Timeout: significato, cause e impatto SEO

TL;DR — Un 504 Gateway Timeout significa che qualcosa davanti al sito — un CDN, un bilanciatore di carico o un proxy — ha atteso la risposta del server e ha rinunciato perché tardava troppo. È un timeout, non una risposta malformata. Un 504 occasionale qua e là va bene; il problema nasce quando continuano a verificarsi, perché i motori di ricerca scansionano meno il sito e, alla fine, rimuovono le pagine.

Cosa significa davvero un 504

Quando carichi una pagina, la richiesta spesso non arriva direttamente al tuo server web. Di solito passa prima da un gateway — un CDN, un bilanciatore di carico o un proxy inverso. Il gateway inoltra la richiesta al server che si trova dietro di esso (l’upstream o l’origin), attende una risposta e te la restituisce.

Un 504 Gateway Timeout è ciò che il gateway restituisce quando ha atteso la risposta dell’upstream e non l’ha ricevuta in tempo. L’origin potrebbe stare elaborando lentamente una query al database, aspettare un’API di terze parti o essere semplicemente sovraccarico; dal punto di vista del gateway, però, il tempo è scaduto. Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

La parola chiave è timeout. Non c’era necessariamente qualcosa di “rotto”. La risposta semplicemente non è arrivata abbastanza velocemente.

Come si distingue dai fratelli 5xx

Le persone li confondono continuamente:

• 502 Bad Gateway — il gateway ha ricevuto una risposta dall’origin, ma era non valida o illeggibile.
• 503 Service Unavailable — il server ha detto esplicitamente “in questo momento non sono disponibile” (spesso intenzionalmente, per esempio durante una finestra di manutenzione).
• 504 Gateway Timeout — il gateway non ha ricevuto una risposta in tempo dall’upstream. È un’affermazione più circoscritta di “non è tornato nulla”: l’upstream potrebbe essere ancora al lavoro, ma non ha risposto entro la finestra di attesa.

Quindi un 504 è quasi sempre un sintomo di prestazioni: qualcosa a monte è troppo lento.

Un 504 danneggia la SEO?

Non direttamente, e non è una penalizzazione. Google non sta giudicando i tuoi contenuti: letteralmente non riesce a recuperare la pagina. Ma esiste un costo indiretto reale:

• Se Googlebot continua a incontrare risposte lente e timeout, rallenta e scansiona meno il sito, così non aggrava il sovraccarico.
• Un singolo 504 durante un picco di traffico viene ritentato e per lo più ignorato.
• I 504 che continuano per giorni sono quelli che fanno uscire le pagine dall’indice, perché Google non riesce a recuperarle in modo affidabile. Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

Cosa fare

• Ricarica una o due volte: un 504 isolato potrebbe essere solo un inconveniente momentaneo.
• Controlla i log del server e degli errori per capire cosa era lento (una query al database, un’API esterna, un processo applicativo sovraccarico).
• Non limitarti ad aumentare il valore del timeout e considerare chiuso il problema: nasconde la risposta lenta invece di correggerla (ne parliamo meglio nella scheda Advanced).
• Mantieni veloce il server: caching, query più rapide e capacità sufficiente sono la vera prevenzione.

Vuoi la versione tecnica completa — dove nasce un 504 nella catena della richiesta, come funziona il throttling della scansione di Googlebot e perché il TTFB è la metrica da osservare? Passa alla scheda Advanced.

TL;DR — Un 504 è un gateway/proxy che comunica che il server upstream non ha risposto entro la finestra di timeout: un timeout, distinto da un 502 (risposta errata) e da un 503 (indisponibilità esplicita). È un problema di accessibilità, non una penalizzazione. I timeout rientrano nella stessa categoria di 429/500/503: Googlebot rallenta quando li vede e 504 persistenti rischiano di causare la deindicizzazione. La soluzione duratura è il tempo di risposta del server (TTFB), non un valore di timeout più alto: aumentarlo di solito maschera un upstream lento e può peggiorare le cose sotto carico.

Dove nasce un 504 nella catena della richiesta

Un percorso moderno della richiesta assomiglia più o meno a questo: browser → CDN/edge → bilanciatore di carico → proxy inverso (per esempio Nginx) → server applicativo (PHP-FPM, Node ecc.) → database / API di terze parti. Un 504 viene generato dal componente che stava aspettando quello dietro di sé quando il suo timeout è scaduto. Questa è la prima domanda diagnostica: Evidence for this claim A 504 response means a gateway or proxy did not receive a timely response from an upstream server. Scope: RFC 9110 defines the timeout semantics; it does not determine why the upstream response was delayed. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.5 — 504 Gateway Timeout

• CDN/edge in timeout sull’origin → la correzione è migliorare le prestazioni dell’origin o aumentare con cautela il timeout upstream del CDN (vedi sotto).
• Bilanciatore di carico in timeout sul server applicativo → controlla lo stato del server applicativo e l’autoscaling.
• Proxy inverso in timeout sul processo applicativo → esamina proxy_read_timeout / fastcgi_read_timeout di Nginx e la query lenta o il processo che si trova effettivamente dietro.

Individuare il livello giusto è importante, perché “correggere il timeout all’edge” e “correggere la query lenta al database dell’origin” sono lavori completamente diversi.

Cosa causa i 504

Il codice di stato da solo non dimostra una causa: dice soltanto che un gateway è andato in timeout aspettando un upstream. Questi sono i sospetti abituali da verificare, non fatti già stabiliti dal 504; confermali con log e trace prima di agire su uno di essi:

• Query lente al database o chiamate a API upstream. Una singola query senza indice o una dipendenza di terze parti lenta può spingere il tempo di risposta oltre il timeout.
• Sovraccarico del server/applicazione ed esaurimento delle risorse. Con un numero sufficiente di richieste concorrenti, le richieste si accodano, i processi worker si riempiono e le risposte smettono di arrivare in tempo.
• Valori di timeout configurati male tra Nginx, Apache, bilanciatore di carico o CDN — spesso non allineati tra i livelli, così uno rinuncia prima dell’altro.
• Picchi di traffico, raffiche di bot o DDoS che superano temporaneamente la capacità.

I 504 sono spesso intermittenti e dipendono dal carico

È questo che li rende insidiosi. A differenza di un’interruzione netta, un 504 compare spesso solo sotto carico: un monitor di disponibilità che invia richieste durante una finestra tranquilla può risultare verde al 100%, mentre Googlebot, durante raffiche di scansione più intense, accumula silenziosamente timeout. In Google Search Console, nell’URL Inspection, potresti vedere questa situazione come condizione “Hostload exceeded” invece che come un errore costante e netto. Se il monitoraggio dice che va tutto bene ma le statistiche di scansione non concordano, i 504 dipendenti dal carico sono un sospetto di primo piano.

Come gestiscono i timeout Googlebot (e Bingbot)

Google non considera un 504 un giudizio sulla qualità dei contenuti: è un segnale di disponibilità e la risposta consiste nel throttling automatico. La documentazione sulla scansione è esplicita: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (traduzione) «Googlebot ridurrà la frequenza di scansione se rileva che i tuoi server hanno difficoltà a rispondere alle richieste di scansione.» La guida al crawl budget per i siti grandi dice la stessa cosa in termini di budget: “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traduzione) «Se il sito rallenta o risponde con errori del server, il limite diminuisce e Google esegue meno scansioni.» Evidence for this claim Google reduces crawling when server errors or slow responses indicate a site is having trouble responding. Scope: Google's documentation supports automatic crawl throttling for server trouble; it does not attribute a specific 504 to any particular bottleneck. Confidence: high · Verified: 2026-07-14 Google: Troubleshoot crawling errors

La formulazione più recente che collega direttamente questo fenomeno alle risposte lente o in timeout viene dall’approfondimento di Google del marzo 2026 Inside Googlebot, nel quale Gary Illyes è citato così: “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (traduzione) «Se il server fatica a servire i byte, i nostri crawler rallenteranno automaticamente per evitare di sovraccaricare la tua infrastruttura e la frequenza di scansione diminuirà.» (Come riferito dalla copertura di Search Engine Land: se la citazione viene usata altrove, conviene verificarla contro la registrazione o la trascrizione originale.) Un 504 rende visibile quella difficoltà.

Una sfumatura importante: Google non vede sempre un “504” letterale come lo vede il browser. Se il timeout avviene prima che Googlebot riceva una riga di stato, nelle statistiche di scansione viene registrato come errore di timeout/rete anziché come un 5XX netto. Ma quando un proxy intermedio o un CDN va in timeout e genera la propria risposta 504, Googlebot riceve un errore server 5XX standard. In entrambi i casi l’effetto è identico: frequenza di scansione ridotta e, se il problema persiste, rimozione dall’indice.

Bing documenta i timeout come una categoria autonoma di errori di scansione, separata dagli errori del server: Bingbot smette di tentare l’accesso alle pagine quando le risposte sono troppo lente. La sua raccomandazione generale è controllare il tempo di risposta del server, mantenere aggiornato il software del server, ottimizzare le risorse lente e leggere i log alla ricerca di schemi sistemici invece di concentrarsi su singoli episodi. Bing non ha pubblicato lo stesso livello di dettaglio sul throttling e sul recupero di Google, quindi considera simili le intenzioni dei due sistemi, non il loro comportamento identico già verificato.

Il ciclo di throttling e recupero

La parte rassicurante è che questo ciclo è automatico e autoregolante. Google riduce la scansione quando vede errori e timeout, poi la aumenta gradualmente quando le risposte tornano sane. Dopo aver corretto il problema sottostante, non devi premere alcun pulsante manuale di «de-throttling»: come ha osservato John Mueller, “Once things settle down on the server, the crawl rate will return to normal automatically.” (traduzione) «Una volta che le cose si stabilizzano sul server, la frequenza di scansione tornerà automaticamente alla normalità.» Ha anche evidenziato l’asimmetria: il rallentamento avviene rapidamente per risolvere un problema immediato, mentre la ripresa procede con cautela.

È la durata a trasformare un episodio in un problema di indicizzazione

I 504 brevi e occasionali — alcuni durante un picco, risolti rapidamente — vengono ritentati e per lo più tollerati. Ciò che rischia la deindicizzazione è uno schema persistente di timeout su una finestra prolungata. I meccanismi documentati da Google del “torna più tardi” — nei quali restituisci intenzionalmente 503 o 429 durante un sovraccarico — descrivono un orizzonte di circa due giorni prima che gli URL inizino a uscire dall’indice, ma quel numero specifico è documentato per 503/429, non per 504. Le indicazioni generali di Google sui 5xx dicono che la frequenza di scansione diminuisce in proporzione al numero di URL in errore e recupera gradualmente quando le risposte tornano sane, senza indicare un orizzonte fisso specifico per i 504. Estendere la soglia di due giorni ai 504 è un’inferenza ragionevole, non un fatto documentato: interpretala così: i 504 brevi sono superabili, mentre uno schema persistente per giorni è l’intervallo in cui preoccuparsi, non una data di attivazione garantita.

Perché conta di più sui siti grandi e di ecommerce

Se hai un sito piccolo e le sue pagine vengono scansionate il giorno stesso in cui le pubblichi, probabilmente non te ne accorgerai quasi mai. Ma sui siti grandi o che cambiano rapidamente — cataloghi ecommerce estesi, notiziari, marketplace — il crawl budget è già il vincolo, e un’ondata di 504 durante il carico di punta può impedire la scansione di pagine che hanno davvero bisogno di essere ricontrollate. Su larga scala, timeout e crawl budget sono la stessa conversazione.

Il tempo di risposta del server e il TTFB sono leve preventive forti — per le cause sul lato origin

Ecco un punto che molti articoli sui 504 trascurano: aspettare che compaiano gli errori e poi cercarli nei log è reattivo. Monitorare continuamente il tempo di risposta del server, così da vedere la deriva prima che si trasformi in un timeout, è proattivo. Un server che oggi è lento ma non ancora in timeout domani può generare 504 con un po’ più di carico o con una dipendenza appena più lenta. Osservare il TTFB (time to first byte) come segnale di allerta precoce continuo — non solo come metrica post-mortem — permette di intercettare quella deriva.

La precisazione: il monitoraggio del TTFB affronta la lentezza sul lato origin. Non rileverà un CDN che va in timeout su un origin sano, un bilanciatore di carico configurato per rinunciare troppo presto o un problema nel percorso di rete tra i livelli: prima devi identificare il livello che emette il 504 (la sezione “Dove nasce un 504” qui sopra o l’albero decisionale sotto). Il TTFB è una correzione reale e duratura per il caso comune di un upstream davvero lento, ma non è universale. Dopo aver confermato che il collo di bottiglia è l’origin, ottimizza con caching (di pagina, oggetti e CDN), query al database più rapide e indicizzate correttamente, autoscaling per il carico e una configurazione sensata del timeout upstream del CDN.

Perché “aumenta semplicemente il timeout” è l’istinto sbagliato

Aumentare proxy_read_timeout o il timeout upstream del CDN può impedire la comparsa del 504, ma non rende più rapida la risposta dell’upstream. Peggio ancora, sotto carico una finestra di timeout più lunga fa accumulare le richieste e tiene occupati più a lungo processi worker e connessioni, potendo peggiorare la spirale del sovraccarico. Aumentare il timeout è talvolta la scelta corretta (per un’operazione realmente lunga e ben compresa), ma come riflesso automatico maschera il problema reale.

Quando l’indisponibilità è pianificata o stai deliberatamente scaricando carico, lo strumento giusto non è lasciare che le pagine restituiscano 504: è restituire un 503 (con un header Retry-After) per inviare ai motori di ricerca un messaggio chiaro e intenzionale di “torna più tardi”, invece di un timeout disordinato.

Diagnosticare un 504 nella pratica

Identifica il livello che emette la risposta prima di ipotizzare una causa: è la differenza tra correggere il problema reale e correggere un sintomo:

• Riproducilo e identifica quale livello ha risposto. Caricalo in un browser; chiamalo con curl e osserva time_starttransfer per il TTFB; eseguilo tramite un crawler come Ahrefs Site Audit o Screaming Frog per vedere se il problema è esteso al sito o isolato. Se possibile, prova direttamente l’origin (bypassando CDN/proxy) per verificare se l’origin stesso completa la richiesta.
• Leggi i log. I log del server e del proxy indicano quale livello è andato in timeout e, idealmente, su cosa: la query lenta, l’upstream bloccato, il pool di worker esaurito. Correla timestamp e ID della richiesta tra i livelli invece di dare per scontato il problema.
• Controlla Search Console. Le statistiche di scansione mostrano picchi nei codici di risposta e il tempo medio di risposta; il rapporto Indicizzazione delle pagine e l’URL Inspection mostrano se Google incontra timeout (incluso “Hostload exceeded”).

È importante riconciliare gli strumenti: un 504 nel browser, un 5xx in Ahrefs Site Audit e un timeout in GSC possono descrivere lo stesso origin lento osservato da punti di vista diversi. Non dare per scontato che tre strumenti significhino tre problemi.

Codici correlati

Un 504 appartiene a una piccola famiglia. Un 500 è un errore server generico senza un codice più specifico; un 502 è una risposta upstream errata o illeggibile; un 503 è un “non disponibile” esplicito e spesso intenzionale. Capire quale codice stai restituendo davvero — e restituire intenzionalmente quello giusto durante un’indisponibilità pianificata — è metà del lavoro.

Riepilogo AI

Una sintesi della versione Advanced:

• Un 504 = un timeout, non una risposta malformata. Un gateway/proxy (CDN, bilanciatore di carico, proxy inverso) ha atteso il server upstream e non ha ricevuto una risposta in tempo: non significa necessariamente che non arriverà mai alcuna risposta. È distinto dal 502 (risposta errata) e dal 503 (indisponibilità esplicita). Il solo codice di stato non dimostra quale livello o quale causa siano coinvolti: identifica il livello che emette la risposta prima di correggere qualsiasi cosa.
• Non è una penalizzazione. È un problema di accessibilità: Google non riesce a recuperare la pagina, quindi la perdita di ranking/indicizzazione è una conseguenza a valle, non una punizione.
• I timeout attivano il throttling della scansione. Google: “Googlebot will scale back its crawling if it detects that your servers are having trouble responding.” (traduzione) «Googlebot ridurrà la frequenza di scansione se rileva che i tuoi server hanno difficoltà a rispondere.» Gary Illyes viene citato (tramite la copertura di Search Engine Land del marzo 2026) mentre descrive i server in difficoltà come causa del fatto che i crawler “automatically back off … which will drop your crawl frequency.” (traduzione) «rallentino automaticamente … e facciano diminuire la frequenza di scansione.»
• La durata conta, ma la cifra dei “2 giorni” non è il numero documentato da Google per i 504. Quell’orizzonte è documentato per 503/429 restituiti intenzionalmente durante un sovraccarico. Le indicazioni generali di Google sui 5xx dicono che la frequenza di scansione diminuisce in proporzione e recupera gradualmente, senza indicare una tempistica fissa specifica per i 504: i 504 isolati vengono ritentati e tollerati; uno schema persistente su una finestra prolungata è quello che rischia la deindicizzazione.
• Il ciclo si autoregola. Quando le risposte tornano sane, la frequenza di scansione ritorna automaticamente: non serve un de-throttling manuale.
• Spesso sono intermittenti e dipendenti dal carico: invisibili ai monitor di disponibilità che interrogano finestre tranquille; possono apparire come “Hostload exceeded” nell’URL Inspection.
• Il tempo di risposta del server (TTFB) è una leva preventiva forte per le cause sul lato origin, se monitorato come segnale di allerta precoce; ma non è universale: un 504 può nascere anche al livello CDN, bilanciatore di carico o proxy, quindi prima conferma quale livello è in timeout. Aumentare il valore del timeout non è una correzione in nessun caso: maschera l’upstream lento e può peggiorare il sovraccarico.
• Quando l’indisponibilità è pianificata, restituisci un 503 con Retry-After, non un 504.

Documentazione ufficiale

Documentazione primaria sui timeout, sugli errori del server e sul modo in cui reagiscono i crawler.

Definizione

• MDN — 504 Gateway Timeout — la definizione autorevole e la differenza rispetto a un 502.

Google

• Risoluzione degli errori di scansione — come Googlebot rallenta quando il server ha problemi e quando restituire 503/429 per un sovraccarico.
• Ottimizzare il crawl budget — come le risposte lente e gli errori del server riducono il limite di scansione.
• Rapporto Statistiche di scansione — le categorie “Errore server (5XX)” e “Timeout pagina” e il modo in cui Googlebot applica il throttling per evitare il sovraccarico.

Bing / Microsoft

• Bing Webmaster Tools — avvisi sugli errori di scansione — come Bing separa errori del server e timeout nelle categorie degli errori di scansione.

Citazioni dalla fonte

Dichiarazioni attribuite ai loro autori. Ogni link è un deep link che porta direttamente al passaggio citato nella pagina sorgente.

MDN — la definizione

• “The HTTP 504 Gateway Timeout server error response status code indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server in order to complete the request. This is similar to a 502 Bad Gateway, except that in a 504 status, the proxy or gateway did not receive any HTTP response from the origin within a certain time.” (traduzione) «Il codice di stato della risposta di errore del server HTTP 504 Gateway Timeout indica che il server, mentre agiva come gateway o proxy, non ha ricevuto in tempo una risposta dal server upstream necessaria per completare la richiesta. È simile a un 502 Bad Gateway, con la differenza che, nel caso di un 504, il proxy o il gateway non ha ricevuto alcuna risposta HTTP dall’origin entro un determinato intervallo.» Vai alla citazione

Google — scansione e timeout

• “Googlebot will scale back its crawling if it detects that your servers are having trouble responding to crawl requests.” (traduzione) «Googlebot ridurrà la frequenza di scansione se rileva che i tuoi server hanno difficoltà a rispondere alle richieste di scansione.» — Google Search Central, Risoluzione degli errori di scansione. Vai alla citazione
• “If the site slows down or responds with server errors, the limit goes down and Google crawls less.” (traduzione) «Se il sito rallenta o risponde con errori del server, il limite diminuisce e Google esegue meno scansioni.» — Google Search Central, Ottimizzare il crawl budget. Vai alla citazione

Gary Illyes, Google

• “If your server is struggling to serve bytes, our crawlers will automatically back off to avoid overloading your infrastructure, which will drop your crawl frequency.” (traduzione) «Se il server fatica a servire i byte, i nostri crawler rallenteranno automaticamente per evitare di sovraccaricare la tua infrastruttura e la frequenza di scansione diminuirà.» Vai alla citazione

John Mueller, Google (su Reddit, riportato da Search Engine Journal, agosto 2025)

• “I’d only expect the crawl rate to react that quickly if they were returning 429 / 500 / 503 / timeouts.” (traduzione) «Mi aspetterei che la frequenza di scansione reagisse così rapidamente solo se venissero restituiti 429 / 500 / 503 / timeout.» Vai alla citazione Search Engine Journal riproduce la risposta Reddit di Mueller e il relativo contesto.

Checklist del tempo di risposta del server / TTFB

L’obiettivo è mantenere le risposte abbastanza rapide da impedire che si attivi un 504 e intercettare la deriva prima che accada. Procedi dall’alto verso il basso:

• Stabilisci il TTFB di base con curl -w "%{time_starttransfer}" (o un monitor sintetico) e registra ciò che è “normale” per ogni template.
• Monitora continuamente il TTFB, non solo dopo un incidente: avvisa quando aumenta, non soltanto in caso di errori netti.
• Esegui load test con concorrenza realistica e di picco: i 504 dipendono di solito dal carico, quindi un controllo in una finestra tranquilla potrebbe non farli emergere.
• Profila il lavoro upstream più lento: query al database senza indice, query N+1 e chiamate bloccanti ad API di terze parti sono i colpevoli abituali.
• Usa il caching in modo aggressivo — cache di pagina, oggetti e edge CDN — così la maggior parte delle richieste non tocca mai il percorso lento.
• Controlla che i valori di timeout siano coerenti tra i livelli (CDN, bilanciatore di carico, proxy_read_timeout / fastcgi_read_timeout di Nginx, app), così un livello non rinuncia prima degli altri.
• Conferma autoscaling e margine di capacità per i picchi di traffico e di scansione.
• Esamina le statistiche di scansione di GSC per picchi di timeout e 5XX e per l’aumento del tempo medio di risposta.
• Controlla i log del server e del proxy per identificare quale livello va in timeout e su quale operazione.
• Verifica che il monitoraggio della disponibilità copra il carico di picco, non solo le richieste fuori orario.
• Usa 503 + Retry-After per l’indisponibilità pianificata invece di lasciare che le pagine restituiscano 504.

Miti e errori sui 504 da evitare

Le trappole più frequenti: molti di questi sono miti ripetuti ovunque che vale la pena correggere:

• “Un 504 è una penalizzazione di Google.” No. È un problema di accessibilità/scansionabilità, non un’azione algoritmica. Google non sta giudicando i contenuti: non riesce a recuperare la pagina. Ogni perdita di ranking è una conseguenza a valle dell’inaccessibilità, non una punizione.
• “Qualsiasi 504 farà uscire subito la mia pagina dall’indice.” No. I 504 brevi e occasionali vengono ritentati e tollerati. È uno schema persistente e frequente di 504 su una finestra prolungata a rischiare la deindicizzazione.
• “504 e 503 sono praticamente uguali: usali in modo intercambiabile.” No. Un 503 può essere un segnale deliberato e controllato (Google supporta esplicitamente il 503 per l’indisponibilità pianificata); un 504 è un timeout, quasi sempre non pianificato e sintomo di un upstream lento. Durante un’indisponibilità pianificata, restituisci 503 con Retry-After: non lasciare che le pagine restituiscano 504.
• “È Googlebot a essere troppo aggressivo.” Di solito è il contrario. Un server che restituisce regolarmente 504 al ritmo di scansione di Googlebot peggiorerà anche per gli utenti reali sotto un carico simile. Il timeout espone un problema concreto di capacità/prestazioni (esistono gli scenari “Hostload exceeded”, ma sono l’eccezione, non la regola).
• “Per risolvere basta aumentare il valore del timeout.” Aumentare proxy_read_timeout maschera un upstream lento invece di correggerlo e, sotto carico, un timeout più lungo tiene occupati più a lungo i processi worker, potendo peggiorare il sovraccarico. Correggi la risposta lenta, non allungare la pazienza.
• “Il monitoraggio della disponibilità è verde, quindi non ho problemi di 504.” I 504 dipendono spesso dal carico. Un monitor che invia richieste in una finestra tranquilla può non vedere i timeout raccolti da Googlebot durante raffiche di scansione più intense. Dai più peso alle statistiche di scansione e ai log che alle richieste fuori orario.

Quale livello va in timeout?

Prompt: classifica un gruppo di incidenti 504

Incolla righe sanificate con URL, timestamp, header di risposta, TTFB o tempo totale, risultato del bordo pubblico, risultato dell’origin diretto, trace dell’applicazione, durata delle query al database e segnali sulle risorse. Non incollare credenziali, cookie, indirizzi privati o dati degli utenti.

You are triaging HTTP 504 Gateway Timeout incidents. Classify each row into one of:
slow application or query, upstream dependency timeout, resource exhaustion,
gateway/origin timeout mismatch, CDN or network path, intermittent with insufficient
evidence, or not actually a 504.

For each row:
- quote the supplied evidence behind the classification;
- identify the missing observation that would most change the conclusion;
- separate response latency from the gateway's configured timeout;
- do not recommend increasing a timeout unless the evidence shows healthy work that
  legitimately needs longer;
- group rows sharing timestamps, routes, upstreams, or resource spikes.

Return a table with URL, likely cause, confidence, evidence, next diagnostic, and
incident group. Then list the first three engineering checks for the highest-impact
group. Do not invent thresholds or monitoring data.

DATA:
[PASTE SANITIZED INCIDENT DATA HERE]

Tratta il risultato come una coda di ipotesi. Confermalo nella telemetria del gateway, dell’applicazione, del database e dell’infrastruttura.

Misurare lo stato e il tempo al primo byte

Esegui questo comando in una shell macOS/Linux. Restituisce il codice della risposta finale e il TTFB per una singola richiesta senza stampare il corpo.

curl -sS -o /dev/null \
  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.example.com/slow-path

Ripetilo alcune volte per capire se il timeout è costante o dipende dal carico:

for i in {1..5}; do
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
    https://www.example.com/slow-path
done

Equivalente PowerShell:

1..5 | ForEach-Object {
  $watch = [System.Diagnostics.Stopwatch]::StartNew()
  try {
    $response = Invoke-WebRequest -Uri 'https://www.example.com/slow-path' -SkipHttpErrorCheck
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = $response.StatusCode; TotalMs = $watch.ElapsedMilliseconds }
  } catch {
    $watch.Stop()
    [pscustomobject]@{ Attempt = $_; Status = 'request-failed'; TotalMs = $watch.ElapsedMilliseconds }
  }
}

La versione PowerShell misura il tempo totale della richiesta, non il TTFB. Usa il comando shell o la telemetria dell’applicazione quando ti serve la scomposizione fino al primo byte.

Strumenti per riprodurre e circoscrivere i 504

• Website Down Checker — verifica la raggiungibilità da un punto di osservazione esterno e acquisisce tempi di risposta, redirect ed evidenze DNS limitate. Serve a stabilire se l’incidente è riproducibile pubblicamente.
• Bulk HTTP Status Code Checker — controlla un insieme rappresentativo di route, confronta la latenza ed esporta il sottoinsieme in errore. Aiuta a distinguere un endpoint lento da un problema upstream esteso al sito.
• Log del CDN/bilanciatore di carico — individua il gateway che ha emesso il 504 e correla il suo request ID e il timeout con il tentativo upstream.
• Tracing dell’applicazione e log delle query lente del database — mostrano quanto tempo ha impiegato la richiesta dopo aver raggiunto l’origin.
• Monitoraggio dell’infrastruttura — confronta la finestra dell’incidente con saturazione di CPU, memoria, pool di worker, connessioni e dipendenze invece di indovinare dal solo codice di stato.

TTFB per route e percentile

Metrica: tempo al primo byte per route rappresentative, segmentato per percentili utili invece che limitato a una sola media.

Cosa indica: la crescita della latenza di coda è un segnale precoce che le richieste si stanno avvicinando a un timeout del gateway, anche prima che inizino a restituire 504.

Come recuperarla: usa il monitoraggio degli utenti reali/del server o i log del gateway; usa lo script curl nella scheda Scripts per controlli puntuali, non come sostituto della telemetria di produzione.

Benchmark / intervallo realistico: stabilisci una baseline per ogni route e percorso dell’infrastruttura. L’avviso significativo è un cambiamento persistente rispetto a quella baseline o un avvicinamento al timeout del gateway effettivamente configurato, non un numero SEO universale.

Cadenza: monitora continuamente; rivedi gli andamenti a livello di route ogni settimana e durante ogni incidente 504.

Tasso di risposta 504

Metrica: richieste che restituiscono 504 divise per tutte le richieste, segmentate per route, gateway, origin e classe di crawler/user agent quando disponibile.

Cosa indica: se i timeout sono isolati, concentrati in un percorso o abbastanza estesi da influire su scansione e utenti.

Come recuperarla: aggrega i log di accesso del CDN, del bilanciatore di carico o del server per codice di stato e dimensioni della richiesta.

Benchmark / intervallo realistico: l’obiettivo di salute è non avere 504 privi di spiegazione. Per la sensibilità degli avvisi, usa la tua baseline normale senza incidenti, perché composizione del traffico e comportamento dei retry cambiano a seconda dello stack.

Cadenza: avvisa continuamente; rivedi ogni giorno durante il recupero e nel normale report settimanale di affidabilità.

Completamento dell’upstream rispetto al timeout del gateway

Metrica: distribuzione dei tempi di completamento dell’upstream confrontata con il timeout configurato per ogni livello.

Cosa indica: se il lavoro lento sta davvero avvicinandosi al limite o se un timeout del gateway più breve sta interrompendo risposte upstream altrimenti sane.

Come recuperarla: unisci i dati temporali del gateway alle trace dell’applicazione usando un request ID o trace ID.

Benchmark / intervallo realistico: mantieni il completamento normale comodamente entro il limite configurato, lasciando spazio alla variabilità attesa. Definisci quello spazio dalle distribuzioni osservate in produzione; non inventare una percentuale generica.

Cadenza: rivedi il dato dopo modifiche alla configurazione o alle dipendenze e ogni volta che aumentano la latenza di coda o il tasso di 504.

Mettiti alla prova: 504 Gateway Timeout

Cinque domande rapide sul significato di un 504 e sui suoi effetti sulla scansione. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

I miei contenuti correlati

• La guida per principianti alla SEO tecnica — dove salute del server e scansionabilità si inseriscono nel quadro più ampio.
• I nuovi web crawler: i bot AI si avvicinano ai bot dei motori di ricerca — chi sta davvero raggiungendo il tuo server e perché il carico conta.

I miei interventi

• Come funziona la ricerca — il mio percorso su scansione, rendering, indicizzazione e posizionamento, compreso il modo in cui le risposte del sito regolano la frequenza di scansione. (La mia precisazione abituale vale: «Questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%.» )

Dal settore

• MDN — 504 Gateway Timeout — la definizione canonica e la distinzione dal 502.
• Google — Risoluzione degli errori di scansione — come Googlebot rallenta quando il server ha problemi.
• Google — Gestire il crawl budget per i siti grandi — come le risposte lente riducono il limite di scansione.
• Google spiega come funziona la scansione nel 2026 (Search Engine Land) — la citazione di Illyes che collega i server in difficoltà alla riduzione della frequenza di scansione.
• Calo della scansione di Googlebot? Mueller indica gli errori del server (Search Engine Journal) — Mueller raggruppa timeout, 429/500/503 tra gli errori che fanno calare rapidamente la frequenza di scansione.
• Come correggere l’errore 504 Gateway Timeout (Kinsta) — una guida tecnica solida, dal lato hosting, sulla catena della richiesta e sulla diagnostica dei log.

Video

• Google Search Central (YouTube) — la serie How Google Search Works e gli approfondimenti di Martin Splitt sulla scansione, utili per capire l’interazione tra risposte del server e frequenza di scansione. Canale

Cronologia modifiche