HTTP Status Checker

Un codice di stato HTTP è un numero a tre cifre che un server restituisce con ogni risposta per dire al client cosa è successo con la richiesta. 200 significa che la pagina si è caricata con successo. 301 significa che la pagina si è spostata permanentemente. 404 significa che la pagina non è stata trovata. 500 significa che il server è andato in crash. I codici fanno parte della specifica HTTP (RFC 9110) e ogni browser, crawler e client API li usano per decidere cosa fare dopo. Ci sono 63 codici di stato definiti divisi in cinque classi, ma nel lavoro SEO reale ne vedi all'incirca dieci regolarmente: 200, 301, 302, 307, 308, 403, 404, 410, 500 e 503. Questo controllore di status HTTP riporta il codice esatto restituito per ogni URL che invii in modo che tu possa correggere quelli che non dovrebbero esserci.

Le cinque classi sono 1xx, 2xx, 3xx, 4xx e 5xx. I codici 1xx (100-103) sono informativi e dicono al client che la richiesta è stata ricevuta e l'elaborazione continua. Non li vedi quasi mai nei contesti browser o SEO. I codici 2xx (200-226) significano successo. 200 è l'OK standard e l'unico che la maggior parte dei siti utilizza. I codici 3xx (300-308) significano reindirizzamento, dicendo al client di recuperare un URL diverso. 301 è permanente, 302 è temporaneo, 307 preserva il metodo di richiesta su un reindirizzamento temporaneo e 308 lo preserva su uno permanente. I codici 4xx (400-451) significano che il client ha fatto una brutta richiesta, con 404 (non trovato), 403 (vietato) e 410 (scomparso) i più comuni. I codici 5xx (500-511) significano che il server ha subito un errore, con 500 (errore interno) e 503 (non disponibile) quelli che gli SEO incontrano più spesso.

Un 301 è un reindirizzamento permanente che dice ai motori di ricerca di aggiornare il loro indice e passare l'intera equità del link al nuovo URL. Un 302 è un reindirizzamento temporaneo che dice ai motori di ricerca di mantenere l'URL vecchio indicizzato perché il trasferimento non è permanente. Per l'SEO, quasi ogni reindirizzamento dovrebbe essere un 301. Usa 302 solo per casi genuinamente temporanei, come reindirizzamenti geografici durante un rollout regionale o suddivisione del traffico di test A/B. Google ha confermato che i 302 di lunga durata sono eventualmente trattati come 301, ma la transizione può richiedere settimane, durante le quali i ranking possono diminuire. Se hai eseguito una migrazione e i tuoi vecchi URL restituiscono 302, cambiali a 301 oggi. Questo controllore di reindirizzamento mostra il codice esatto restituito, quindi una rapida esecuzione in blocco sul tuo elenco di URL vecchi conferma se la tua mappa di reindirizzamento utilizza il tipo giusto.

Un 307 è un reindirizzamento temporaneo che preserva il metodo HTTP originale, il che significa che un POST rimane un POST quando il client segue il reindirizzamento. Un 302 storicamente ha consentito ai client di cambiare un POST a un GET, il che ha rotto gli invii di moduli. 307 ha risolto questo problema. Per l'SEO, 307 si comporta come 302: temporaneo, non passa l'intera equità del link, mantiene l'URL vecchio indicizzato. Vedrai 307 su siti che usano framework lato server (Next.js, Nuxt, Django) per i reindirizzamenti, poiché questi framework usano come impostazione predefinita 307 per motivi di sicurezza. Se un 307 è destinato a essere permanente, passalo a 308 (l'equivalente permanente) o 301. Il controllore di codice di stato url cattura il codice esatto in modo che tu possa individuare i 307 che dovrebbero essere 308 o 301 al posto.

Un 404 significa che il server non riesce a trovare la pagina in questo momento e il client non dovrebbe presumere nulla sul futuro. Un 410 significa che la pagina è scomparsa permanentemente e non tornerà mai. Per l'SEO, 410 è un segnale più forte a Google per far cadere l'URL dall'indice rapidamente. Se hai deliberatamente rimosso una pagina (prodotto interrotto, articolo del blog cancellato, funzione ritirata) e non hai sostituzione, restituisci 410 invece di 404. Google deindexizza gli URL 410 approssimativamente 2 volte più velocemente degli URL 404 in base a molteplici raccomandazioni di Search Central. Se la pagina è genuinamente mancante per caso o temporaneamente non disponibile, 404 è il codice giusto. Questo controllore 200 301 404 riporta entrambi in modo che tu possa passare gli spazi deliberati da 404 a 410 e pulire l'indice più velocemente.

Un codice di stato 500 significa che il server ha riscontrato un errore interno che non ha potuto gestire. Le cause comuni includono un processo di applicazione in crash, un errore di connessione al database, un'eccezione non gestita nel codice o un server configurato male. 500 è generico, il che significa che il corpo della risposta di solito non ha informazioni diagnostiche utili. Per eseguire il debug, hai bisogno dei log del server. Per l'SEO, i 500 sono spreco di scansione e un segnale di qualità che danneggia i ranking se persistono. Google ritenta i 500 per un po', poi fa cadere l'URL dall'indice se l'errore continua. Se la tua esecuzione del controllore in blocco mostra 500 su URL che dovrebbero funzionare, controlla immediatamente i log del server. Un 500 su una pagina ad alto traffico costa entrate e ranking ogni minuto che rimane interrotto. Esegui il controllore di status HTTP dopo ogni deploy per catturare i 500 introdotti dalle modifiche al codice.

Un 503 significa che il server è temporaneamente non disponibile, di solito a causa di sovraccarico, manutenzione o una degradazione del servizio. A differenza di un 500, che segnala un errore reale, un 503 dice "torna più tardi". I 503 configurati correttamente includono un'intestazione Retry-After che dice ai crawler quando riprovare. Google rispetta Retry-After e mette in pausa la scansione senza far cadere l'URL dall'indice, finché il 503 non si cancella entro poche ore. Se i 503 persistono per più di 48 ore, Google inizia a trattarli come 500 e fa cadere gli URL. Per la manutenzione programmata, restituisci un 503 con un'intestazione Retry-After impostata sul tempo di inattività previsto. Per i 503 inaspettati trovati da questo controllore, indaga la capacità del server, la configurazione CDN o la salute del servizio upstream.

Incolla fino a 50 URL nell'area di testo in questo controllore di status HTTP, uno per riga, con il protocollo completo (https:// o http://). Scegli se seguire i reindirizzamenti, quindi premi Verifica status. Lo strumento recupera ogni URL in parallelo e restituisce una tabella con il codice di stato, la catena di reindirizzamento se presente, l'URL finale dopo i reindirizzamenti e il tempo di risposta in millisecondi. Per elenchi più grandi di 50, dividili in batch. L'approccio in blocco è approssimativamente 30 volte più veloce che controllare ogni URL uno per uno in un browser e fa emergere schemi (ogni URL in una cartella che restituisce 404, ogni pagina di prodotto che si incatena attraverso due reindirizzamenti) che i controlli di singoli URL perdono. Abbina l'output con il sitemap-checker per confermare che la tua sitemap elenca solo i 200.

Estrai un elenco di ogni URL sul tuo sito dalla tua sitemap, dal tuo CMS o da un crawler come Screaming Frog. Dividi l'elenco in batch di 50 ed esegui ogni batch attraverso questo controllore di status HTTP in blocco. Raggruppa i risultati per classe di codice di stato. Ogni 4xx è una pagina interrotta che ha bisogno di una correzione o di un reindirizzamento. Ogni 5xx è un problema del server che ha bisogno di indagine. Ogni 3xx è un reindirizzamento funzionante o una catena che ha bisogno di appiattimento. Per i siti con meno di 1.000 pagine, l'audit completo impiega meno di un'ora. Per i siti più grandi, dai priorità agli URL con link esterni in entrata e alle pagine che ricevono traffico organico, poiché sono quelli che costano una vera visibilità quando interrotti. Riesegui mensilmente per catturare nuovi break prima che si accumulino.

Una catena di reindirizzamento è una sequenza di due o più reindirizzamenti tra l'URL originale e la destinazione finale. URL A reindirizza a URL B, che reindirizza a URL C, che infine restituisce 200 a URL D. Ogni hop aggiunge latenza (tipicamente 100-500ms per reindirizzamento) e diluisce l'equità del link. Google ha confermato che segue fino a 10 hop prima di rinunciare, ma tratta ogni hop come attrito. Le catene lunghe rallentano sia gli utenti che i crawler. Correggi le catene aggiornando l'URL originale (URL A) per puntare direttamente alla destinazione finale (URL D). Questo controllore di reindirizzamento mostra la catena completa quando Segui reindirizzamenti è impostato su Sì, quindi puoi vedere esattamente quanti hop ogni URL attraversa e appiattire quelli più lunghi di due.

Un reindirizzamento sano va in un hop, restituisce 301 (o 308 per richieste non-GET), preserva la struttura del percorso dove possibile e punta a una pagina viva pertinente. La destinazione dovrebbe restituire 200 e canonicalizzare a se stessa. La catena non dovrebbe includere 4xx, 5xx o protocolli misti. Per una migrazione, la mappa di reindirizzamento dovrebbe coprire il 100% degli URL vecchi che hanno ricevuto link esterni o traffico organico negli ultimi 12 mesi. Gli URL che non hanno mai avuto link possono essere autorizzati a 404. Uno studio SEMrush del 2023 di 200 migrazioni di siti ha scoperto che i siti con 301 a singolo hop e zero reindirizzamenti interrotti hanno mantenuto l'89% del traffico organico post-lancio, mentre i siti con catene più lunghe di tre hop o 404 non mappati hanno mantenuto solo il 51%.

Per l'SEO, il tempo di risposta del server (anche chiamato Time to First Byte o TTFB) dovrebbe essere inferiore a 800ms per una buona esperienza utente e inferiore a 200ms per un'eccellente. I dati Google Core Web Vitals mostrano che le pagine con TTFB superiore a 1.500ms si classano in modo misurabilmente più basso in query competitive. Questo controllore di status HTTP riporta il tempo di risposta per URL in modo che tu possa segnalare quelli lenti. Un 200 che impiega 3.000ms a rispondere è tecnicamente attivo ma funzionalmente interrotto. Le cause comuni: query di database non ottimizzate, CDN mancante, HTML renderizzato dal server oversized o distanza geografica tra server e crawler. Correggi il 10% più lento delle pagine per primo poiché di solito condividono una causa sottostante. Abbina questo strumento con il google-crawler-simulator per confermare che Googlebot veda il tempo di risposta che vedi tu.

curl è uno strumento da riga di comando che può recuperare qualsiasi URL e mostrare il codice di stato con i flag giusti (curl -I -L https://example.com). È potente, gratuito e funziona per un URL alla volta. Un controllore di status HTTP in blocco come questo esegue lo stesso recupero su 50 URL in parallelo, cattura la catena di reindirizzamento in una tabella leggibile, cronometra la risposta e visualizza il risultato in un browser senza digitare flag. Per uno sviluppatore a suo agio con la riga di comando, curl va bene per controlli puntiformi. Per gli audit SEO su centinaia di URL, uno strumento in blocco è approssimativamente 30 volte più veloce e molto più facile da condividere con colleghi non tecnici. Entrambi gli strumenti restituiscono gli stessi codici di stato poiché entrambi parlano HTTP.

Sì. Apri la scheda Network in Chrome o Firefox devtools, carica l'URL e guarda la richiesta del documento. Ogni reindirizzamento appare come una riga separata con il codice di stato (301, 302, 307) e l'intestazione Location che punta al prossimo URL. La riga finale è la pagina che restituisce 200. Devtools è eccellente per eseguire il debug di un URL alla volta e vedere le intestazioni esatte di richiesta e risposta. È impraticabile per il controllo di 50 URL perché devi ricaricare ciascuno e leggere manualmente il log di rete. Per gli audit in blocco usa questo controllore di reindirizzamento, che mostra lo stesso dato della catena in una tabella che puoi scansionare in secondi. Usa devtools quando hai bisogno di dettagli intestazione completi e il controllore in blocco quando hai bisogno di scala.

Le migrazioni rompono gli URL. Anche mappe di reindirizzamento attente perdono casi limite: barre finali, sensibilità alle maiuscole, stringhe di query, caratteri codificati, file in sottocartelle che il nuovo server ha dimenticato di copiare. Un'esecuzione del controllore di codice di stato URL in blocco il giorno del lancio cattura la prima ondata di breakage. Una seconda esecuzione due settimane dopo cattura gli URL che i modelli di traffico rivelano. I siti che saltano gli audit post-migrazione di solito perdono il 20-40% del traffico organico nel primo mese e impiegano 3-6 mesi per recuperare. I siti che eseguono l'audit immediatamente e correggono entro 48 ore di solito mantengono l'85%+ del traffico. Esegui questo controllore di status HTTP sulla tua sitemap, sulle tue prime 100 pagine di atterraggio organiche e su qualsiasi URL con backlink esterni. Usa il sitemap-checker per confermare che la nuova sitemap contiene solo 200.

Sì. Questo controllore di status HTTP è gratuito, non richiede iscrizione e non ha limiti giornalieri su quanti batch esegui. L'unico vincolo è 50 URL per esecuzione, il che mantiene la risposta veloce e previene gli abusi. Per batch più grandi, dividi gli URL in gruppi di 50 e incolla ciascuno a sua volta. Lo strumento viene eseguito lato server, il che significa che vede i codici di stato nel modo in cui Googlebot li vede, non nel modo in cui il tuo browser li vede dopo il caching. Usalo tutte le volte che hai bisogno: settimanalmente per i siti attivi, giornalmente durante le migrazioni e dopo ogni deploy per catturare le regressioni. Abbinalo con il canonical-checker, sitemap-checker e google-crawler-simulator per un flusso di lavoro di audit completo a livello di URL.