500 Internal Server Error: guida agli errori del server

TL;DR — Un 500 Internal Server Error significa che il server si è bloccato mentre cercava di costruire la pagina: non è un problema dell’URL, del browser o del crawler di ricerca. Un 500 isolato in genere viene ritentato da Google e non esiste una regola che dica che ti costi qualcosa. Il pericolo documentato compare quando molte pagine restituiscono 500 per un certo periodo: Google rallenta la scansione e, alla fine, può rimuovere le pagine dai risultati. Per iniziare a risolvere, guarda i log degli errori del server, non il browser.

Che cos’è un errore 500

Un 500 Internal Server Error è la versione web di «qualcosa è andato storto e non posso dirti esattamente cosa». Il server ha ricevuto la richiesta, ha iniziato a costruire la pagina, ha incontrato un problema e si è arreso, restituendo un errore generico invece della pagina. Nella guida ai codici di stato HTTP di Ahrefs l’ho definito così: il server “encounters some kind of issue and doesn’t have a better or more specific error code.” (traduzione) «incontra un problema di qualche tipo e non ha un codice di errore migliore o più specifico». Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

Questo è il punto fondamentale: un 500 è un catch-all. Dice che qualcosa si è rotto sul lato server, ma non dice che cosa. Trovare il «che cosa» è l’intero lavoro.

È un problema del server, non tuo (di solito)

Gli errori 500 appartengono alla famiglia 5xx, cioè agli errori del server. È diverso dagli errori 4xx, come il 404 (pagina non trovata), che riguardano la richiesta (un URL errato o mancante). Con un 500 l’URL può essere perfettamente corretto: è il server che non è riuscito a portare a termine il lavoro. Esistono anche i «cugini» del 500 — 502, 503 e 504 — anch’essi lato server, ma riferiti a situazioni più specifiche (gateway errato, server temporaneamente non disponibile o timeout).

Un errore 500 danneggia la SEO?

Un singolo 500 occasionale su una pagina? In genere Google torna a provarci e, se la pagina si carica correttamente al nuovo tentativo, la questione finisce lì. Google non pubblica una promessa generale secondo cui un errore isolato è innocuo: semplicemente non documenta alcun meccanismo che penalizzi un singolo inconveniente.

Il rischio reale e documentato riguarda i 500 persistenti su molte pagine. Quando succede:

1. Google continua a ritentare, vede che gli errori persistono e rallenta la velocità con cui esegue la scansione del sito.
2. Se gli errori non si risolvono, Google alla fine rimuove quelle pagine dall’indice, cioè smettono di comparire nella ricerca. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

La buona notizia è che la documentazione di Google descrive un recupero graduale quando il problema di fondo è risolto e le scansioni tornano ad avere successo, ma non garantisce tempi o risultati. La documentazione osserva che “Recovery is usually quick” (traduzione) «il recupero è di solito rapido»: è il caso comune, non una promessa.

Come iniziare a risolvere il problema

• Controlla prima i log degli errori del server. È lì che si trova il motivo reale, non nel browser. Un browser ti mostra solo «500»; i log ti mostrano perché.
• Guarda che cosa è cambiato di recente. Un nuovo plugin, tema o modulo? Un deploy recente? Una modifica a un file di configurazione come .htaccess? Le modifiche recenti sono i sospetti abituali.
• Controlla Google Search Console. Il rapporto Indicizzazione delle pagine contiene una sezione «Errore del server (5xx)» che mostra su quali URL Google vede 500.
• Chiedi al tuo host. Soprattutto sull’hosting condiviso, molti 500 derivano dal raggiungimento dei limiti di memoria o di risorse: il tuo host spesso può verificarlo dal proprio lato.

Vuoi la versione più approfondita — esattamente come Google aumenta la severità, la regola empirica dell’~1%, la distinzione tra 500 e 503 e un ordine completo per la diagnosi? Passa alla scheda Advanced.

TL;DR — RFC 9110 definisce il 500 come una condizione imprevista che ha impedito al server di soddisfare la richiesta: questo è l’intero confine del codice di stato; causa, durata e opportunità di ritentare sono aspetti diagnostici, non semantici. La reazione documentata di Google è graduale: i 500 isolati vengono in genere ritentati; i 500 persistenti e diffusi sull’intero sito portano a una scansione più lenta e, se non vengono risolti, alla rimozione dall’indice. Mueller ha proposto una regola empirica, personale e approssimativa: tassi di errore superiori a circa l’1% probabilmente indicano che qualcosa non funziona, ma non è una soglia Google documentata e la sequenza ritenta → rallenta la scansione → rimuove descrive comportamenti documentati, non un timer fisso e sincronizzato. Diagnostica prima dai log degli errori del server, poi dal rapporto «Errore del server (5xx)» di GSC e dalle statistiche di scansione «per risposta». La distinzione 500-503 conta: il 503 è il codice autorizzato per dire «torna più tardi», con una finestra di tolleranza di circa 2 giorni; un 500 incontrollato non ha questa tolleranza.

Che cos’è davvero un 500

Parti dalla specifica, non dall’abbreviazione usata dai professionisti. RFC 9110 — lo standard della semantica HTTP — definisce un 500 Internal Server Error come una condizione imprevista che ha impedito al server di soddisfare la richiesta. Questo è l’intero confine di ciò che il codice di stato comunica. Non identifica la causa principale, il componente guasto, quanto durerà il problema, se la stessa richiesta avrebbe successo ritentandola o se il recupero è probabile. Tutto ciò che va oltre «il server ha incontrato qualcosa che non è riuscito a gestire» è diagnosi, non semantica del codice di stato; e la diagnosi vive nei log degli errori del server, non nella specifica o nel browser.

Nella guida ai codici di stato HTTP di Ahrefs mantengo deliberatamente brusca la definizione rivolta ai professionisti: il server “encounters some kind of issue and doesn’t have a better or more specific error code.” (traduzione) «incontra un problema di qualche tipo e non ha un codice di errore migliore o più specifico». È una parafrasi in linguaggio semplice dello stesso confine di RFC: ancora un catch-all, ancora un sintomo e non una diagnosi.

Fa parte della famiglia 5xx insieme a 502 (bad gateway), 503 (service unavailable) e 504 (gateway timeout): tutti errori lato server, ma il 500 è quello che significa «non si applica alcun codice migliore». Poiché il codice di stato non contiene dettagli diagnostici, ricaricare la pagina nel browser non ti dice nulla sul perché; i log degli errori del server sono la fonte autorevole.

Come Googlebot tratta un 500

Il crawler di Google è progettato per essere rispettoso: adatta la velocità allo stato del server e considera le risposte 5xx uno dei segnali che significano «rallenta». La documentazione attuale di Google conferma la forma di questa reazione: le risposte 5xx e 429 causano una riduzione temporanea del crawl rate (proporzionata al numero di URL interessati), e gli URL che continuano a fallire possono alla fine essere rimossi dall’indice, mentre i contenuti già indicizzati vengono conservati nel frattempo, in attesa di un aggiornamento riuscito. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers John Mueller ha descritto la stessa progressione con parole sue, in una sessione Google SEO Office Hours riportata da Search Engine Journal:

“We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (traduzione) «La citazione descrive la sequenza di comportamenti documentati: Google ritenta gli URL che restituiscono 500, rallenta la scansione se gli errori continuano e può rimuoverli dall’indice se il problema persiste. Non stabilisce soglie numeriche o tempi fissi.»

Leggila come una descrizione di comportamenti documentati — nuovo tentativo, scansione più lenta, possibile rimozione — non come un timer fisso in tre passaggi con transizioni o tempi garantiti: Google non pubblica soglie esatte per il passaggio da una fase alla successiva. Un 500 isolato su un URL viene in genere ritentato e il successivo recupero riuscito normalmente chiude la questione, ma questa è la descrizione del caso comune, non una garanzia che un singolo errore abbia costo zero. Il rischio reale e documentato riguarda gli errori che non si risolvono.

Perché i 500 sull’intero sito sono peggiori di quelli isolati

Quando una grande parte del sito restituisce 500 contemporaneamente si crea una dinamica più pericolosa. La documentazione attuale di Google conferma che la riduzione del crawl rate aumenta in proporzione al numero di URL interessati: più è ampia la parte del sito che non funziona, più la scansione rallenta. Mueller ha spiegato il ragionamento in termini più specifici, descrivendolo come il sospetto di Google che la propria scansione possa contribuire al sovraccarico:

“But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (traduzione) «La citazione presenta la caratterizzazione di Mueller sul rapporto tra molti errori 500, rallentamento della scansione dell’intero sito e successiva rimozione degli URL. È una spiegazione personale della dinamica, non una soglia o una tempistica ufficiale.»

Tratta questa specifica descrizione causale — «presumiamo di essere noi a causarlo» — come una caratterizzazione di Mueller, non come una formulazione riportata parola per parola nella documentazione ufficiale attuale di Google. Il meccanismo di fondo è documentato (più URL in errore, maggiore riduzione del crawl rate), anche se il ragionamento causale esatto è più facile da verificare nella sua dichiarazione che nei documenti. In ogni caso vale la pena interiorizzare il circuito pratico: una scansione aggressiva durante l’esaurimento delle risorse può generare più 500 → Google riduce la scansione dell’intero sito → e, se gli errori persistono comunque, le pagine vengono rimosse. Significa anche che un problema 500 non è sempre un bug del codice: a volte il server cede sotto un carico concorrente che si manifesta solo durante picchi di crawler o traffico.

Quanto è «troppo»?

Non esiste una soglia netta: la documentazione ufficiale di Google per la risoluzione dei problemi non pubblica alcuna soglia di tasso di errore. Mueller ha proposto una regola empirica, personale e approssimativa durante SEO Office Hours (riportata ancora una volta da Search Engine Journal, non da una pubblicazione ufficiale di Google):

“My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (traduzione) «La citazione di Mueller propone l’1% come sensazione personale e regola empirica, non come soglia ufficiale o applicata da Google.»

Considera ~1% un test empirico non ufficiale attribuito a Mueller, non un limite Google documentato o applicato. Al di sotto probabilmente va tutto bene; al di sopra vale la pena indagare, ma non trattare il superamento dell’1% come un trigger automatico e non considerare il rimanere sotto quella soglia una garanzia. L’unico numero a cui Google si impegna pubblicamente è l’assenza di un numero: «non abbiamo soglie rigide».

500 vs. 503: la distinzione che conta

È qui che molte persone sbagliano. Un 503 Service Unavailable è il modo autorizzato per dire a un crawler «sono temporaneamente indisponibile, torna più tardi». Google lo tratta come intenzionale e gli concede una finestra di tolleranza. La documentazione di Google per la risoluzione dei problemi di scansione è esplicita:

“Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (traduzione) «La citazione documenta l’uso temporaneo di 503 o 429 quando il server è sovraccarico, il nuovo tentativo per circa 2 giorni e il rischio di rallentare o interrompere definitivamente la scansione se i codici di indisponibilità durano più di pochi giorni.»

Il contrasto è questo: il 503 è intenzionale e riceve circa 2 giorni di tolleranza per i nuovi tentativi; un 500 incontrollato è involontario e non riceve una tolleranza analoga: viene semplicemente ritentato finché Google rinuncia. Conseguenza pratica: per una manutenzione pianificata o una difesa deliberata dal sovraccarico, restituisci 503 (idealmente con un header Retry-After), non un 500 e non una pagina di errore 200. Non camuffare mai una vera interruzione come 200.

Come diagnosticare un 500

Procedi per livelli — applicazione/codice, piattaforma/CMS, infrastruttura e risorse, poi configurazione — iniziando da ciò che costa meno e ha più probabilità di risolvere. I passaggi contrassegnati (specifico per WordPress) sono pratiche comuni di WordPress, non correzioni universali: adattali al tuo stack reale.

1. Log degli errori del server. error.log / access.log (o il visualizzatore dei log della piattaforma). Confronta gli orari con le richieste che falliscono. Qui compaiono il vero stack trace, l’errore fatale PHP o il fallimento della connessione al DB. Tutto ciò che viene dopo è un’ipotesi finché non hai letto questi log.
2. GSC — rapporto Errore del server (5xx). Il rapporto Indicizzazione delle pagine di Google Search Console segnala gli URL sui quali Google vede direttamente i 500. Poi apri Statistiche di scansione e leggi la ripartizione «per risposta» nel tempo: è così che distingui un inconveniente transitorio da un problema di disponibilità reale e persistente.
3. Bing Webmaster Tools. I suoi avvisi sugli errori di scansione raggruppano gli Errori del server (5xx) e indicano gli URL specifici e lo strumento Informazioni sulla scansione.
4. Riproduci il problema come bot, non solo come browser. Una pagina può restituire 500 a Googlebot e caricarsi correttamente per te: il carico attivato dalla scansione, una configurazione errata del rilevamento bot/firewall o limiti di capacità possono manifestarsi solo con traffico bot concorrente. Usa URL Inspection (GSC), Fetch as Bingbot o curl con uno user-agent bot per individuare gli errori solo per i bot. «Funziona nel mio browser» non è il via libera definitivo.
5. Conflitti tra plugin, temi o moduli (caso specifico di WordPress; adattalo altrove). Prima fai un backup: devi sempre poter tornare indietro prima di disattivare componenti. Poi disattiva le estensioni e riattivale una alla volta per isolare quella responsabile, controllando i permessi e la proprietà dei file che tocchi. Le guide di troubleshooting WordPress dei provider di hosting riportano spesso questo schema, ma è un’osservazione specifica dello stack, non la prova che sia la causa principale ovunque: su un altro CMS o su un’app personalizzata l’equivalente può essere un modulo, pacchetto o middleware di terze parti.
6. Esaurimento delle risorse. Limiti della memoria PHP, limiti delle connessioni al database, capacità dell’hosting condiviso, picchi di traffico o di scansione. Il tuo host spesso può confermarlo dal proprio lato.
7. Configurazione e modifiche recenti. Un .htaccess danneggiato, una modifica errata alla configurazione del server, un deploy recente o credenziali DB sbagliate. Le modifiche recenti sono il punto di partenza con il rendimento più alto.

Come risolverlo (adatta la correzione alla causa)

Adatta la correzione al livello indicato dalla diagnosi. Sono schemi comuni riportati in articoli pratici, non un elenco ordinato né universale delle cause più probabili sul tuo stack specifico:

• È stato causato da configurazione/deploy → annulla la modifica e correggi .htaccess, configurazione o credenziali.
• Esaurimento delle risorse → aumenta i limiti (memoria PHP, connessioni DB) o passa a un piano di hosting superiore; se la scansione sta causando il sovraccarico, è anche una questione di crawl rate.
• Conflitto tra plugin/moduli → rimuovi o sostituisci l’estensione responsabile.
• Bug del codice → correggi il codice e aggiungi la gestione degli errori mancante.
• Non riesci a capire la causa → rivolgiti al tuo host con gli orari esatti e le righe dei log. Non fare supposizioni in produzione.

Prevenire il ripetersi del problema

Monitorare e generare avvisi sui tassi 5xx, mettere in staging le modifiche prima di portarle in produzione, eseguire test di carico prima dei picchi di traffico noti e — se la scansione di Googlebot è essa stessa il fattore scatenante — gestire il carico di scansione (e restituire deliberatamente 503/429 durante un sovraccarico reale, invece di lasciare che il server emetta 500 incontrollati).

Domande frequenti

Un errore 500 danneggia la SEO? Il rischio documentato riguarda soprattutto la persistenza su larga scala. I 500 isolati vengono in genere ritentati, senza una penalizzazione documentata per un singolo inconveniente; i 500 persistenti e diffusi sull’intero sito rallentano la scansione e possono portare alla deindicizzazione.

Dopo quanto tempo Google deindicizza una pagina con un 500? Non esiste una tempistica fissa. Google ritenta prima e rallenta la scansione; la rimozione dall’indice avviene solo se gli errori continuano. Risolvi il problema e le pagine generalmente tornano quando le scansioni hanno di nuovo successo.

Perché il mio sito restituisce 500 a Googlebot ma si carica correttamente nel browser? I 500 solo per i bot indicano di solito problemi di capacità o di gestione dei bot: carico attivato dalla scansione, regole firewall/bot o limiti che si manifestano solo con traffico bot concorrente. Fidati dei log, non di un controllo manuale nel browser.

I 500 possono rallentare la scansione dell’intero sito, non solo delle pagine interessate? Sì: la documentazione di Google conferma che la riduzione del crawl rate aumenta con il numero di URL in errore, quindi una grande parte del sito che restituisce 500 rallenta la scansione a livello del sito. Mueller ha inoltre descritto il ragionamento come il sospetto di Google che la propria scansione possa contribuire al sovraccarico: è una sua caratterizzazione, non una formulazione riportata parola per parola nei documenti ufficiali attuali.

Che cosa causa un 500 in WordPress? Nello specifico di WordPress, i provider di hosting e la community WordPress riportano più spesso conflitti tra plugin o temi, un .htaccess corrotto o il raggiungimento del limite di memoria PHP: è ciò che viene riportato per quella piattaforma, non l’affermazione che siano le cause principali universali di ogni 500. L’ordine diagnostico sopra (prima i log, poi ciò che è cambiato) è lo stesso indipendentemente dal CMS.

È sicuro ritentare automaticamente una richiesta dopo un 500? Solo dopo aver verificato prima il metodo e l’idempotenza della richiesta: il codice di stato 500 da solo non autorizza una politica di retry. GET, HEAD, PUT e DELETE sono generalmente sicuri da ritentare perché idempotenti (ripeterli non dovrebbe causare effetti collaterali aggiuntivi); un POST semplice in genere non lo è, a meno che l’API garantisca esplicitamente l’idempotenza (per esempio tramite una chiave di idempotenza): ritentarlo alla cieca rischia di creare un ordine duplicato, un’e-mail duplicata o un doppio addebito. Quando ritenti, usa un backoff esponenziale con jitter, limita il numero di tentativi e imposta un budget di retry, così un server in difficoltà non viene colpito da una tempesta di nuovi tentativi oltre al carico che sta già causando problemi.

Riepilogo AI

Una sintesi condensata della versione Advanced:

• 500 = il confine della condizione imprevista di RFC 9110. È l’intero ambito del codice di stato: nessuna causa principale, nessuna durata, nessuna indicazione sulla possibilità di ritentare. È un sintomo, non una diagnosi; trova la causa nei log del server, non nel browser. È distinto dagli errori 4xx (client/richiesta) e dai suoi fratelli 5xx 502/503/504.
• La reazione documentata di Google è graduale: riduzione temporanea del crawl rate (proporzionata al numero di URL interessati) e possibile rimozione dall’indice degli URL che continuano a fallire, con recupero quando le scansioni tornano riuscite. Mueller la descrive come ritenta → rallenta la scansione → rimuove dall’indice: una descrizione di comportamenti documentati, non un timer fisso e sincronizzato. Un 500 isolato viene in genere ritentato; non c’è promessa che sia privo di costi, ma il rischio reale e documentato è la persistenza su larga scala.
• I 500 sull’intero sito sono peggiori: la riduzione del crawl rate aumenta con il numero di URL in errore. Mueller descrive il ragionamento come il sospetto che la scansione di Google possa contribuire al sovraccarico: è una sua caratterizzazione, non una formulazione verbatim dei documenti ufficiali; in ogni caso si crea un circuito in cui il carico di scansione può generare altri 500.
• Regola empirica, non soglia: Mueller ha detto che tassi di errore superiori a ~1% sono «probabilmente» il segno di qualcosa di rotto, ma è la sua formulazione personale da SEO Office Hours, non un limite Google documentato: Google dichiara di non avere soglie rigide.
• 500 contro 503: il 503 (o 429) è il segnale autorizzato «torna più tardi», con circa 2 giorni di tolleranza per i nuovi tentativi secondo la documentazione Google; un 500 incontrollato non ha questa tolleranza. Usa 503 (con Retry-After) per i tempi di inattività pianificati.
• Ordine della diagnosi (per livello): log del server → rapporto Errore del server (5xx) di GSC + Statistiche di scansione «per risposta» → Bing Webmaster Tools → riproduzione come bot (URL Inspection / un comando HTTP) → conflitti tra plugin/moduli (schema specifico di WordPress; adattalo altrove e fai prima un backup) → esaurimento delle risorse → modifiche di configurazione/deploy.
• La sicurezza del retry dipende dalla richiesta, non dal codice di stato. I metodi idempotenti (GET/HEAD/PUT/DELETE) sono in genere sicuri da ritentare; un POST semplice di solito non lo è senza una chiave di idempotenza. Usa backoff, un limite ai tentativi e un budget di retry.
• Il recupero è in genere rapido dopo la correzione: le pagine rimosse tendono a tornare quando le scansioni riescono di nuovo, anche se Google non garantisce tempi o risultati.

Documentazione ufficiale

Documentazione da fonti primarie dei motori di ricerca e della specifica HTTP.

Google

• Risoluzione degli errori di scansione di Google Search — come Google gestisce gli errori del server e l’uso autorizzato di 503/429 per un sovraccarico temporaneo.
• Guida approfondita al funzionamento di Google Search — lo scheduler della scansione e il fatto che le risposte 5xx vengono interpretate come «rallenta».
• Rapporto Statistiche di scansione — la ripartizione «per risposta» (compreso Errore del server (5xx)) usata per distinguere un inconveniente da un problema persistente.
• Ridurre il crawl rate di Googlebot — il modo corretto e deliberato di rallentare la scansione, invece di lasciare che il server emetta 500 incontrollati.

Bing / Microsoft

• Bing Webmaster Tools — Elenco degli avvisi sugli errori di scansione — come Bing raggruppa gli Errori del server (5xx) e dove controllare gli URL interessati.

Specifica HTTP / riferimento

• MDN — 500 Internal Server Error — la definizione del codice di stato.
• RFC 9110 §15.6.1 — 500 Internal Server Error — la semantica HTTP autorevole.

Citazioni dalla fonte

Dichiarazioni pubbliche. Quando una pagina sorgente è sottoposta a rendering JavaScript o è stata riportata da una fonte secondaria, il fatto è segnalato con una nota <small>.

Google — il percorso di escalation

• “We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (traduzione) «Google non pubblica soglie rigide per il 500; descrive la sequenza ritenta, rallenta la scansione e rimuove dall’indice, mentre Mueller propone circa l’1% come regola empirica personale.» — John Mueller, Google. Leggi la copertura Riportata tramite la trascrizione di Search Engine Journal di un video di Google SEO Office Hours; verifica la formulazione esatta nel video sorgente prima di considerarla definitiva.
• “But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (traduzione) «Se una parte ampia del sito restituisce 500 in modo costante, Google può sospettare che la scansione contribuisca al problema, rallentare la scansione dell’intero sito e infine rimuovere quelle pagine.» — John Mueller, Google. Leggi la copertura Riportata tramite Search Engine Journal; verifica la formulazione parola per parola rispetto al video originale.
• “My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (traduzione) «Secondo la mia impressione, oltre l’uno per cento sembra indicare che qualcosa non funzioni.» — John Mueller, Google, on a rough error-rate rule of thumb. Leggi la copertura Riportata tramite Search Engine Journal; verifica la formulazione parola per parola rispetto al video originale.

Google — il segnale autorizzato «rallenta» (documenti verificati)

• “Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (traduzione) «Restituisci temporaneamente 503 o 429 alle richieste di Googlebot quando il server è sovraccarico: Googlebot ritenterà per circa 2 giorni, ma codici di indisponibilità oltre pochi giorni rallenteranno o fermeranno definitivamente la scansione degli URL.» — documentazione di Google Search Central. Jump to quote

Patrick Stox — la definizione (Ahrefs, verificata)

• “500 Internal Server Error – The server encounters some kind of issue and doesn’t have a better or more specific error code.” (traduzione) «500 Internal Server Error: il server incontra un problema di qualche tipo e non ha un codice di errore migliore o più specifico.» — la mia guida sui codici di stato HTTP nel blog di Ahrefs. Jump to quote

Checklist di triage per gli errori 500

Esegui questi controlli dall’alto verso il basso non appena compaiono i 500:

• Ho recuperato i log degli errori del server e trovato l’errore reale (stack trace / errore fatale PHP / errore DB), non solo il «500» del browser.
• Ho controllato che cosa è cambiato di recente: nuovo plugin/tema/modulo, deploy recente, modifica a .htaccess o alla configurazione del server, credenziali DB cambiate.
• Ho aperto GSC → Indicizzazione delle pagine → Errore del server (5xx) per vedere su quali URL Google sta rilevando 500.
• Ho letto nel tempo le Statistiche di scansione di GSC «per risposta» per distinguere un problema transitorio da uno persistente.
• Ho controllato gli avvisi sugli errori di scansione di Bing Webmaster Tools per gli stessi URL.
• Ho riprodotto il problema come bot (URL Inspection / Fetch as Bingbot / curl con user-agent bot), non solo nel browser.
• Ho escluso l’esaurimento delle risorse (memoria PHP, connessioni DB, capacità dell’hosting) con il mio host.
• Ho isolato eventuali conflitti tra plugin/moduli disattivandoli e riattivandoli uno alla volta.
• Ho verificato di non emettere 500 incontrollati durante un periodo di inattività pianificato: in quel caso uso 503 (con Retry-After).
• Dopo la correzione ho verificato che il tasso di errore sia tornato sotto il test empirico non ufficiale dell’~1% (regola empirica di Mueller, non soglia Google documentata) e che GSC mostri di nuovo scansioni riuscite.

Runbook: «Il sito restituisce 500: che cosa controllo per primo?»

Un ordine operativo senza panico. Esegui i passaggi in sequenza e fermati quando hai trovato e risolto la causa.

0. Definisci l’ambito (2 minuti). È un URL, un template/sezione o l’intero sito? Un solo URL è poco urgente (Google ritenta). Un problema sull’intero sito è l’emergenza: è lo schema che fa rallentare a Google la scansione dell’intero sito.

1. Leggi i log degli errori del server. Prima error.log. Confronta gli orari con i fallimenti. Cerca la causa reale: errore fatale PHP, errore di connessione al DB, segfault o terminazione per memoria insufficiente. Tutto il resto è un’ipotesi finché non hai fatto questo controllo.

2. Collega il problema a «che cosa è cambiato». Ordina per modifiche recenti: ultimo deploy, plugin/tema/modulo aggiunto o aggiornato, modifica a .htaccess, credenziali DB ruotate o modifica di configurazione. La maggior parte dei 500 risale a una modifica delle ultime ore o degli ultimi giorni. Se puoi, annulla prima la modifica e diagnostica dopo: ripristinare il servizio ti fa guadagnare tempo.

3. Conferma la visuale dei motori di ricerca. GSC → Indicizzazione delle pagine → Errore del server (5xx) per gli URL interessati, poi Statistiche di scansione → per risposta per capire se è un inconveniente o un problema persistente. Controlla anche gli avvisi sugli errori di scansione di Bing Webmaster Tools. Questo ti dice quanto è urgente il problema SEO.

4. Riproduci il problema come lo vede il bot. Se per le persone la pagina funziona ma per Googlebot restituisce 500, esegui un test come bot: URL Inspection, Fetch as Bingbot o curl -A "Googlebot" <url>. I 500 solo per i bot indicano problemi di capacità, regole firewall/bot o carico attivato dalla scansione: la correzione è diversa da quella di un bug del codice.

5. Isola i sospetti abituali.

• Plugin/moduli: disattivali tutti e riattivali uno alla volta finché il problema non ricompare.
• Risorse: controlla con il tuo host il limite di memoria PHP, il tetto delle connessioni DB e la capacità dell’hosting, soprattutto se i 500 si concentrano durante picchi di traffico o scansione.
• Configurazione: ripristina .htaccess / configurazione del server a una versione nota come funzionante.

6. Se la scansione è il fattore scatenante, non limitarti ad assorbirla. Quando il volume di scansione di Googlebot ti sovraccarica, la leva temporanea corretta è restituire 503/429 (con Retry-After), non lasciare che il server emetta 500 incontrollati. Google rispetta il 503 come «torna più tardi» per circa 2 giorni; un 500 non ha questa tolleranza.

7. Verifica il recupero. Tasso di errore di nuovo sotto il test empirico non ufficiale dell’~1%, log puliti e Statistiche di scansione di GSC che mostrano di nuovo recuperi riusciti. In genere le pagine rimosse tornano quando le scansioni riescono: non ci sono tempi garantiti, ma di solito è rapido.

Schema di escalation da ricordare: 500 occasionale → in genere ritentato, rischio documentato basso → 500 persistente → la scansione rallenta → ancora persistente → gli URL vengono rimossi dall’indice. Google non pubblica tempi precisi per queste transizioni: il tuo compito è interrompere la catena prima che arrivi a quel punto.

Quale codice del server dovrei restituire?

Usa questa guida quando devi decidere che cosa servire o interpretare ciò che stai osservando.

Il problema è intenzionale (manutenzione/difesa deliberata dal sovraccarico)?

• Sì → restituisci 503 Service Unavailable con un header Retry-After. Google lo tratta come temporaneo e ritenta per circa 2 giorni. Non servire una pagina di errore 200 e non lasciare che la richiesta ricada su un 500.
• No (è un errore reale e imprevisto) → continua.

Tutti ricevono l’errore o solo il crawler?

• Tutti → è un problema di codice/configurazione/DB. Vai ai log degli errori del server e all’elenco di «che cosa è cambiato». Annulla le modifiche recenti.
• Solo Googlebot/Bingbot → sospetta capacità insufficiente, regole di rilevamento bot/firewall o carico attivato dalla scansione. Riproduci il problema come bot, controlla le risorse del server e le regole per i bot.

Riguarda un URL o una grande parte del sito?

• Un URL / occasionale → urgenza bassa. Google ritenta; risolvi con calma, ma verifica che sia davvero isolato.
• Intero sito / persistente → emergenza. È lo schema che fa rallentare a Google la scansione dell’intero sito e alla fine porta alla deindicizzazione. Ripristina prima il servizio (annulla la modifica), trova poi la causa principale.

Il tasso di errore è superiore a ~1%?

• Sì → vale la pena indagare come possibile problema reale: è la regola empirica non ufficiale di Mueller, non una soglia Google documentata.
• No → probabilmente va bene, ma continua a monitorare la tendenza, non solo la fotografia del momento.

Prompt: correlare un 500 con i log e un deploy

Diagnose this HTTP 500 incident from the sanitized evidence I provide. Build a
timeline across deployment events, request IDs, access logs, application errors,
resource signals, and affected URL patterns. Rank likely causes by evidence, separate
the fastest service-restoration action from the root-cause fix, and give exact
validation and rollback checks. Do not invent missing stack traces or thresholds.

[PASTE TIMELINE, HEADERS, LOGS, AND RECENT CHANGES]

Prompt: trasformare uno stack trace in un piano di test sicuro

Explain this stack trace in plain language, identify the failing component and its
inputs, and propose the smallest reversible test that distinguishes code, dependency,
configuration, and resource-exhaustion causes. Include what evidence would falsify
each hypothesis and how to confirm the URL returns a stable non-5xx response afterward.
Redact secrets and do not suggest exposing debug output publicly.

[PASTE SANITIZED STACK TRACE]

Shell: campionare un elenco di URL per le risposte 5xx

Esegui questo comando con un URL assoluto per riga in urls.txt.

while IFS= read -r url; do
  curl -sS -o /dev/null -w '%{http_code},%{time_total},%{url_effective}\n' "$url"
done < urls.txt

L’output separa le route isolate da un problema diffuso e registra la latenza senza scaricare i corpi delle risposte.

PowerShell: esportare lo stesso campione di stati

Get-Content .\urls.txt | ForEach-Object {
  $r = Invoke-WebRequest -Uri $_ -SkipHttpErrorCheck
  [PSCustomObject]@{ Status = $r.StatusCode; Url = $_ }
} | Export-Csv .\status-sample.csv -NoTypeInformation

Shell: contare gli stati 5xx in un access log

Adatta la posizione del campo dello stato al formato di log documentato prima di affidarti al risultato.

awk '$9 ~ /^5[0-9][0-9]$/ { count[$9]++ } END { for (code in count) print code, count[code] }' access.log

Strumenti per trovare e diagnosticare i 500

• Log degli errori del server — error.log / access.log, oppure il visualizzatore dei log del tuo host/piattaforma. È lo strumento più importante: la causa reale vive qui.
• Google Search Console — Indicizzazione delle pagine — la sezione «Errore del server (5xx)» elenca gli URL sui quali Google vede 500.
• GSC — rapporto Statistiche di scansione — la ripartizione «per risposta» nel tempo separa un inconveniente transitorio da un problema di disponibilità persistente.
• GSC — URL Inspection — recupera un singolo URL come Google per riprodurre un 500 solo per i bot.
• Bing Webmaster Tools — gli avvisi sugli errori di scansione raggruppano gli Errori del server (5xx) e rimandano allo strumento Informazioni sulla scansione.
• curl — riproduci il problema con un user-agent arbitrario: curl -I -A "Googlebot" <url> per vedere il codice di stato come lo vede un bot.
• Crawler/audit del sito — Ahrefs Site Audit e Screaming Frog SEO Spider fanno emergere le risposte 5xx in tutto il sito e aiutano a individuare gli schemi (un intero template o una sezione che fallisce).
• Monitoraggio dell’uptime/stato — genera avvisi sui tassi 5xx per sapere che c’è un picco prima che lo scopra Google.

Risorse che meritano il tuo tempo

I miei contenuti correlati

• Codici di stato HTTP: guida al loro impatto su SEO e UX — il mio riferimento completo ai codici di stato, con la definizione del 500 e il quadro più ampio della scansione 5xx.
• Guida per principianti alla SEO tecnica — il posto degli errori del server nel quadro più ampio della SEO tecnica.

I miei interventi

• Come funziona la Ricerca (SlideShare) — la mia panoramica della scansione e del modo in cui lo stato del server si ripercuote su di essa. (Si applica la nota standard: “This is my understanding of systems… not going to be 100% complete or accurate.” (traduzione) «Questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%.»)

Dal settore

• Come gli errori 500 possono influire sull’indicizzazione (Search Engine Journal) — l’articolo di Matt G. Southern con le citazioni di John Mueller sulla sequenza ritenta → rallenta la scansione → rimuove dall’indice e la regola empirica dell’~1%.
• Come correggere il problema di errore del server (5xx) nella Google Search Console (Search Engine Land) — una procedura dettagliata per il rapporto GSC.
• Come risolvere il problema «Server Error (5xx)» nella Google Search Console (Onely) — che cosa sono gli errori 5xx, dove trovarli in GSC e un percorso di risoluzione.
• Come risolvere un 500 Internal Server Error sul tuo sito (Kinsta) — un elenco dettagliato e incentrato sull’hosting WordPress (log del server, plugin/temi, memoria PHP, .htaccess, permessi).
• Errori del server 5xx: guida a individuazione e risoluzione dei problemi 5xx (Lumar) — una prospettiva enterprise/audit tecnico attenta ai file di log e al crawl budget.
• Come risolvere un errore del server 5xx nella Google Search Console (Sitechecker) — un’altra guida pratica al rapporto GSC.

Video

• Google Search Central (YouTube) — l’archivio SEO Office Hours, da cui provengono le indicazioni di John Mueller sugli errori del server e la scansione (il quadro ritenta → rallenta la scansione → rimuove dall’indice citato sopra). Canale

Mettiti alla prova: 500 Internal Server Error

Cinque domande rapide su che cos’è un 500 e su come influisce sulla SEO. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche