Vai al contenuto 
Codici di stato HTTP controllare come i crawler effettuano le richieste, caricano i contenuti e se le pagine vengono effettivamente inserite nella ricerca. Mostrerò come risposte come 200, 301, 404 o 503 influenzano l'interazione tra crawling, crawl budget e hosting e dove si trovano i tipici freni.
Punti centrali
- Budget per le strisciate dipende direttamente dalla correttezza delle risposte di stato.
- 2xx/3xx Consentire l'indicizzazione, bloccare 4xx/5xx.
- Inoltro Utilizzare solo senza catene e anelli.
- Orari del server e l'uptime determinano l'affidabilità dei crawler.
- Monitoraggio con log, GSC e crawler.
Perché i codici di stato controllano la scansione
I crawler controllano innanzitutto il Codice di stato, solo dopo seguono il rendering e la valutazione dei contenuti. Pertanto, do la priorità alla correttezza della risposta prima ancora dei tag del titolo o dei link interni. Un 200 OK carica immediatamente i contenuti, mentre 4xx e 5xx costano tempo, budget e fiducia. Se gli errori si accumulano, il bot riduce le richieste e ritarda l'inserimento di nuovi contenuti. Ciò porta a perdite SEO silenziose, che possono essere evitate con regole chiare per Risposte del server evitare.
2xx: La via diretta all'indice
Il 200 OK è per i crawler un Via libera. Fornisco 200 solo a pagine autentiche e complete dal punto di vista dei contenuti e impedisco i soft 404, che inviano 200 ma non offrono alcun valore aggiunto. Contenuti scarsi, H1 mancanti o testi quasi identici sono segnali di allarme per tali configurazioni errate. Chi fa ordine in questo ambito risparmia crawl budget e rafforza la rilevanza tematica. Inoltre, ottimizzo gli snippet e i riferimenti interni in modo che i crawler e gli utenti con un appello raggiungere gli obiettivi giusti.
3xx: reindirizzamenti senza perdita
301 sposta i contenuti in modo permanente e trasferisce i segnali al nuovo URL, mentre 302 rappresenta una soluzione temporanea. Utilizzo il 301 quando i contenuti sono stati effettivamente spostati e rimuovo catene e loop, perché ogni salto in più consuma tempo e budget. Controlla i link interni, perché una catena interna 301 è un ingorgo auto-creato. Per i trasferimenti pianifico regole coerenti, in modo che tutto punti in modo chiaro all'URL di destinazione. Perché questo è così importante, lo mostro su Catene di reindirizzamento, che influiscono in modo misurabile sul tempo di caricamento e sul crawling.
4xx: segnali chiari per contenuti rimossi
Un 404 comunica chiaramente: questo Risorse Non esistono. Lascio il 404 per le pagine realmente rimosse ed evito i soft 404 non inviando mai 200 alle pagine di errore. Il 410 segnala in modo ancora più chiaro che una pagina è stata rimossa in modo permanente; lo utilizzo in modo mirato per gli URL obsoleti che non hanno alternative adeguate. I link interni a 404 sprecano budget, quindi li correggo tempestivamente o li reindirizzo in modo mirato alla migliore alternativa tematica. In questo modo mantengo i crawler sulle pagine che sono realmente Valore consegnare.
5xx: gli errori del server rallentano i bot e gli utenti
5xx significa: il server non è riuscito a elaborare la richiesta. servire. In caso di accumulo, i crawler classificano il sito come inaffidabile e lo visitano meno frequentemente. Per la manutenzione, imposto 503 con „Retry-After“, in modo che i bot sappiano quando è opportuno effettuare un nuovo richiamo. Se un 503 persiste, valuto i log e risolvo i colli di bottiglia relativi a CPU, RAM, database o limiti di velocità. Per WordPress raccolgo consigli pratici in questa guida su Errori 503, in modo che le finestre di manutenzione rimangano controllate e brevi.
Caching, 304 ed ETag: risparmiare sul budget senza rischi
304 Not Modified risparmia Larghezza di banda, perché il client può continuare a utilizzare la propria copia. Imposta ETag o Last-Modified in modo corretto, in modo che i crawler possano utilizzare correttamente If-Modified-Since. In questo modo si riducono le richieste di CSS, JavaScript e immagini invariati. Se la logica non è corretta, il bot carica inutilmente molti file o perde gli aggiornamenti. Per questo motivo provo diverse varianti, controllo gli header di risposta e mantengo le risposte 304 coerenti su tutti i Attività.
Budget di scansione: come mantenerlo elevato
Il budget di scansione dipende da tre fattori: qualità del codice, Prestazioni e struttura interna. Riduco i fattori che causano perdite di tempo, come catene di inoltro, contenuti duplicati e TTFB lento. Indirizzo i link interni verso pochi percorsi chiari, in modo che i bot possano riconoscere più rapidamente le priorità. Correggo rapidamente le pagine errate o orfane prima che consumino budget. Ciò include anche i codici di stato per l'impaginazione, i canonical e gli hreflang, che senza segnali di errore devono correre.
Fattori di hosting che influenzano i codici di stato
Hardware di buona qualità, configurazione server pulita e capacità adeguata Caching Prevenire i picchi 5xx. Mi assicuro che ci siano abbastanza worker PHP, parametri di database, keep-alive e HTTP/2 o HTTP/3. Anche i limiti di velocità per i bot dovrebbero essere impostati in modo sensato, in modo da non bloccare gli utenti reali. In caso di picchi di carico elevati, sono utili le cache edge e le regole per le risorse statiche. Qui mostro perché i codici di stato e le prestazioni di hosting sono correlati: Stato HTTP e potenza del server.
Monitoraggio: utilizzare correttamente log, GSC e crawler
Comincio con i log dei server perché sono autentici Richieste di informazioni e annoto ogni risposta. Successivamente controllo la Search Console per individuare eventuali errori di copertura, sitemap e stato di rendering. Una scansione desktop e mobile con un crawler SEO rileva reindirizzamenti, 4xx e 5xx in un unico passaggio. Per analisi approfondite, correlo gli errori con i momenti di rilascio o i picchi di traffico. Questo mostra se un rollout, un plugin o un insieme di regole CDN ha causato il Risposte è cambiato.
Panoramica rapida: codici di stato e misure
La tabella seguente assegna le risposte tipiche alle fasi appropriate ed evidenzia i punti relativi all'hosting. La utilizzo come guida per prendere decisioni rapide nella vita quotidiana.
| Codice di stato | Reazione del crawler | Azione | Nota sull'hosting |
|---|---|---|---|
| 200 OK | Il contenuto viene richiamato e valutato | Fornire contenuti autentici, evitare i soft 404 | Mantenere basso il TTFB, cache calda |
| 301 Spostato in modo permanente | Segnali all'URL di destinazione | Rimuovere le catene, aggiornare i link interni | Mantenere chiare le regole di riscrittura |
| 302 Trovato | Temporaneo, la sorgente mantiene i segnali | Da utilizzare solo per brevi periodi | Controllare regolarmente |
| 304 Non modificato | Utilizza la cache, nessun download | Impostare correttamente ETag/Last-Modified | Distribuzione delle risorse tramite CDN |
| 404 Non trovato | URL rimosso dall'indice | Correggere i link interni, evitare i soft 404 | Mantenere snella la pagina degli errori |
| 410 Andato | Rimozione più rapida | Da utilizzare per contenuti rimossi in modo permanente | Inoltro solo in caso di alternativa reale |
| 500 Errore interno | Il bot riduce le visite | Controllare i log, risolvere la causa | Aumentare le risorse e i limiti |
| 503 Servizio non disponibile | Modalità manutenzione accettata | „Impostare “Retry-After", mantenere breve la durata | Pianificare la finestra di manutenzione |
Gestione degli errori: cosa controllo per prima cosa
Inizio con il Ambito: L'errore riguarda tutti gli utenti, solo i bot o solo i dispositivi mobili? Successivamente, verifico se l'ultima modifica è stata apportata al server, all'applicazione o al CDN. Se l'errore si verifica solo sotto carico, aumento le risorse a breve termine e cerco eventuali colli di bottiglia nelle tracce. In caso di 5xx ricorrenti, imposto avvisi su modelli di log e endpoint di stato. In questo modo risolvo rapidamente i problemi urgenti e impedisco che Budget per le strisciate ridurre ulteriormente.
Controlli tecnici prima dei rilasci
Prima di ogni rollout, provo i percorsi critici con un Messa in scena-Eseguo il crawl e confronto i codici di stato con la versione live. Tengo pronta una lista di URL importanti: home page, categoria, prodotto, filtro, ricerca, mappa del sito, API. Successivamente controllo le intestazioni come Cache-Control, Vary, regole di reindirizzamento e canonical. Per i feature flag imposto condizioni chiare, in modo che non generino involontariamente 302 o 404. Solo quando i codici di stato, i tempi di caricamento e i risultati di rendering sembrano stabili, do il via libera. Rilascio gratuito.
robots.txt, sitemap e URL secondari
Per prima cosa verifico se robots.txt Stabile con 200 risposte. 5xx o 403 su robots.txt destabilizzano i crawler e rallentano la scansione. Un 404 su robots.txt è considerato „nessuna restrizione“, ma è un segnale negativo per i siti con problemi di scansione. Per Sitemaps Accetto solo 200 e mantengo i file piccoli, puliti, compressi con gzip e con campi lastmod corretti. I 3xx alla mappa del sito sono tecnicamente consentiti, ma li evito a favore di una risposta diretta 200. Per Feed, AMP- o API-Risorse: mi assicuro che non restituiscano 404 o 5xx quando la pagina HTML restituisce 200, altrimenti il rendering o l'analisi dei dati strutturati si interrompe in modo incoerente.
Canonical, Hreflang e impaginazione solo su 200
Segnali come rel=canonical, hreflang o Pagination hanno effetto solo se gli URL di destinazione e di riferimento vengono caricati con 200 finale. Evito i canonical su URL 3xx, 404 o noindex perché confondono il crawler. Per hreflang controllo il riferimento incrociato e che ogni variante finisca con 200. Gli elenchi impaginati (pagina=2,3,…) devono fornire stabilmente 200; impedisco che le pagine vuote attivino Soft-404 offrendo contenuti chiari e percorsi interni in caso di risultati mancanti, ma inviando comunque lo stato corretto.
429 e utilizzare correttamente i limiti di velocità
429 Richieste eccessive è il mio strumento per una limitazione granulare quando i singoli bot sono troppo aggressivi. Impost Riprova dopo con un'indicazione temporale significativa, in modo che i crawler possano scaglionare le loro richieste. Il codice 429 non sostituisce la manutenzione 503 e non dovrebbe mai interessare gli utenti legittimi. Nel WAF o nel CDN, distinguo in base all'user agent, all'IP e ai percorsi, in modo che le risorse multimediali continuino a fornire 200/304, mentre l'HTML viene temporaneamente limitato. Importante: il 429 non deve diventare permanente, altrimenti il bot valuterà il sito come difficilmente accessibile e ridurrà il budget.
401/403/451: bloccato intenzionalmente, ma in modo coerente
401 Lo utilizzo per le aree protette da login, 403 per accessi non autorizzati. Mi assicuro che queste risposte non si applichino accidentalmente a Googlebot, ad esempio tramite filtri bot rigorosi. In caso di blocchi geografici o requisiti legali, imposto 451 e documento internamente i motivi. Rinuncio alle risposte 200 con interstitial („accesso negato“) – tali pagine sembrano dei soft 404. Se esistono alternative, inserisco un link chiaro ai contenuti accessibili e lascio che l'URL bloccato invii lo stato 4xx corretto.
Parità delle risposte: dispositivi mobili, desktop e riproduzione dinamica
Mi assicuro che i bot mobili e desktop abbiano le stesse Codici di stato vedere. Le riproduzioni dinamiche (test A/B, feature flag, geo-content) non devono attivare 302/403 per singoli user agent. Io utilizzo Variare-Utilizza le intestazioni con parsimonia e consapevolezza (ad es. Accept-Language) per evitare inutili divisioni della cache e assicurati che ogni percorso per tutte le varianti termini in modo coerente con 200/304. Le violazioni di parità causano problemi di indicizzazione quando il bot vede un 404 mentre gli utenti ricevono un 200: elimino questi casi con regole chiare e test per ogni variante.
HEAD, OPTIONS e endpoint API
Molti crawler inviano HEAD-Richieste per verificare disponibilità e dimensioni. Il mio server risponde con la stessa logica utilizzata per GET, ma senza body. Evito 405 su HEAD se GET restituisce 200. OPZIONI e CORS Preflights in modo che le risorse provenienti da fonti terze possano essere caricate correttamente. Per Endpoint API, Quando i dati vengono forniti durante il rendering, faccio attenzione a valori stabili 200/304 e chiari 4xx in caso di errori reali. Se le API forniscono sporadicamente valori 5xx, li contrassegno separatamente nei log, perché possono spiegare errori di rendering sotto il cofano, anche se la pagina HTML invia 200.
Regole CDN, strategie Stale e protezione 5xx
Nel CDN memorizzo nella cache 200, 301 e 404 statici in modo controllato, ma impedisco che 503 o le pagine di amministrazione finiscono nella cache. Con stale-if-error posso bypassare temporaneamente gli errori 5xx senza che i bot vedano gli errori. Impostare Controllo surrogato per i segnali Edge e mantengo i TTL per HTML più brevi rispetto agli asset. Configuro gli ETag cluster-sicuro (uguale ovunque o disattivato) affinché 304 funzioni in modo affidabile e non venga invalidato da hash divergenti. Importante: i reindirizzamenti (301/302) non dovrebbero essere memorizzati nella cache del CDN per sempre, altrimenti i vecchi percorsi rimangono come catene.
Casi di e-commerce: esaurito, varianti, filtri
Se i prodotti sono temporaneamente non disponibili, la pagina del prodotto rimane su 200 con una chiara etichettatura e percorsi interni significativi (categoria, alternative). Per i prodotti rimossi in modo permanente, decido tra 301 all'URL sostitutivo migliore (solo in caso di corrispondenza effettiva) e 410, se non ci sono alternative adeguate. Evito i reindirizzamenti di massa alla pagina iniziale, perché hanno lo stesso effetto dei soft 404. Per URL dei filtri e dei parametri Applico regole chiare: solo combinazioni rilevanti per l'indicizzazione su 200, tutto il resto tramite 301 sull'URL canonico o con noindex, ma mai 200 per pagine vuote o quasi identiche che attivano il rilevatore Soft-404.
Separare chiaramente noindex, robot e codici di stato
noindex è un segnale di contenuto, il codice di stato è un segnale di trasporto. Evito forme miste che confondono i crawler: nessun 301 su una pagina noindex, nessun 200 con placeholder „accesso limitato“ se la risorsa non esiste. Una pagina è indicizzabile (200 + index) oppure è stata rimossa (404/410) o temporaneamente non disponibile (503 con Retry-After). robots.txt blocca solo la scansione, non l'indicizzazione di URL già noti. Per questo motivo, per i contenuti realmente rimossi imposto 404/410 anziché blocchi robotici.
Indicatori e valori soglia che osservo
- Tasso 5xx: costantemente ben al di sotto di 0,1%. Esaminare immediatamente i picchi.
- Tasso 4xx: a seconda del tipo di sito, tra 1 e 2%. Gli errori interni 4xx dovrebbero essere indirizzati a 0%.
- Quota 3xx: il più basso possibile; Catene di reindirizzamento a 0.
- Quota 304 per le risorse: alto è buono – indicatore di un caching funzionante.
- TTFB per HTML: stabile basso; correlo i valori anomali con 5xx/429.
- Mappa del sito - Salute: 200, ultimo aggiornamento valido, nessun link non funzionante.
- Parità Mobile vs. desktop: stessi codici di stato e URL finali.
Collego queste metriche alle distribuzioni, ai picchi di traffico e agli eventi infrastrutturali. In questo modo riconosco i modelli che Budget per le strisciate influenzano molto prima che le classifiche reagiscano.
Casi limite: 1xx, 405, 410 vs. 404
1xxLe risposte sono praticamente irrilevanti per la SEO; mi assicuro solo che il server e il CDN effettuino correttamente l'aggiornamento (ad es. HTTP/2/3). 405 Metodo non consentito appare quando HEAD/POST sono bloccati, anche se GET restituisce 200 – questo è innocuo, ma dovrebbe essere configurato in modo coerente. Nella scelta 404 contro 410 Utilizzo il codice 410 per i contenuti rimossi intenzionalmente con carattere permanente, il codice 404 per i percorsi sconosciuti o collegati accidentalmente. È importante che Coerenza, in modo che i crawler possano imparare dai modelli ricorrenti.
Strategie di rollback e affidabilità
Pianifico i rilasci in modo tale da poter tornare rapidamente indietro in caso di codici di stato errati: Blu/verde-Distribuzioni, flag di funzionalità a granularità fine e regole di riscrittura reversibili. Per la manutenzione utilizzo Pagine di manutenzione, che restituiscono un codice 503 mentre sono in esecuzione i lavori in background. A livello di infrastruttura, ho predisposto controlli di integrità, riavvii automatici e limiti di velocità che intercettano gli attacchi senza bloccare la navigazione legittima. Ogni misura è volta a, 200/304 massimizzare e mantenere controllati, brevi e comprensibili i 4xx/5xx in caso di guasto.
Riepilogo: segnali puliti, scansione più veloce
Mi assicuro che tutti Codice di stato trasmette un messaggio chiaro: 2xx per i contenuti, 3xx senza catene, 4xx per le pagine rimosse e 5xx solo in casi davvero eccezionali. Il caching con 304 alleggerisce il carico sul server, mentre risposte 200 coerenti danno fiducia al bot. Affinché ciò funzioni, combino analisi dei log, dati GSC e crawl ricorrenti. Dal lato host, mantengo bassi i tempi di risposta, imposto limiti ragionevoli e pianifico accuratamente la manutenzione. In questo modo aumentano la qualità, l'indicizzabilità e la visibilità. Budget per le strisciate scorre dove porta maggiori benefici.
