Per alcuni rischiano di essere semplicemente dei numeri apparentemente privi di senso, mentre qualcun altro, più esperto, sa che possono nascondere molte insidie per l’efficienza del sito: ormai dovremmo però conoscere quali sono i codici di stato HTTP e cosa significano per le nostre pagine, così come qualche infarinatura l’abbiamo su errori di rete e problemi DNS col server. Per la prima volta, però, è proprio Google a trattare questi temi, con una guida dettagliata e ufficiale su come queste situazioni influiscono sulla SEO e sulle prestazioni del sito in Ricerca Google.

La guida di Google sugli effetti SEO di codici di stato HTTP ed errori DNS e di rete

La risorsa si trova sul sito Search Central, al momento è disponibile solo in lingua inglese e descrive appunto “in che modo i diversi codici di stato HTTP , errori di rete ed errori DNS influiscono sulla Ricerca Google”.

Nello specifico, copre i primi 20 codici di stato che Googlebot ha riscontrato sul Web e gli errori di rete e DNS più importanti: ciò significa, quindi, che non c’è spazio per i codici di stato più particolari e bizzarri, come il 418 I’m a teapot. Inoltre, tutti i problemi menzionati nella pagina generano un errore o un avviso corrispondente nel rapporto Statistiche di scansione di Search Console.

Il documento si divide in tre sezioni – appunto, Codici di stato HTTP, errori di rete ed errori DNS – offre un’introduzione descrittiva sul topic, con informazioni aggiornate e, soprattutto, dettagli interessanti su come Google reagisce alle varie situazioni. Ad esempio:

  • Google proverà 10 hop per i redirect, dopo i quali considererà l’URL con un errore di reindirizzamento in Search Console.
  • Redirect 301 vs 302: per Google, un reindirizzamento 301 è un segnale forte che il target di reindirizzamento dovrebbe essere canonical, mentre un reindirizzamento 302 è un segnale debole che il target del reindirizzamento dovrebbe essere canonical.
  • I codici di stato 200 garantiscono che la pagina vada alla pipeline di indicizzazione, ma non garantiscono che la pagina sia poi effettivamente indicizzata.

Google e codici di stato HTTP

I codici di stato HTTP, ricorda il documento, sono generati dal server che ospita il sito quando risponde a una richiesta effettuata da un client, ad esempio un browser o un crawler. Ogni codice di stato HTTP ha un significato diverso, ma spesso l’esito della richiesta è lo stesso. Ad esempio, esistono più codici di stato che segnalano il reindirizzamento, ma il loro risultato pratico è lo stesso.

Search Console genera messaggi di errore per i codici di stato nell’intervallo 4xx–5xx e per i reindirizzamenti non riusciti (3xx). Se il server ha risposto con un 2xxcodice di stato, il contenuto ricevuto nella risposta può essere considerato per l’indicizzazione (ma, come dicevamo, non c’è garanzia che poi sia effettivamente inserito nell’indice).

Status code 2xx (successo)

Google considera il contenuto per l’indicizzazione. Se il contenuto suggerisce un errore, ad esempio una pagina vuota o un messaggio di errore, Search Console mostrerà un errore soft 404.

  • 200 (success / successo)
  • 201 (created / creato)

In entrambi questi casi, Googlebot passa il contenuto alla pipeline di indicizzazione. I sistemi di indicizzazione possono indicizzare il contenuto, ma ciò non è garantito.

  • 202 (accepted / accettato)

Googlebot attende il contenuto per un tempo limitato, quindi passa tutto ciò che ha ricevuto alla pipeline di indicizzazione. Il timeout dipende dall’user agent: ad esempio, Googlebot Smartphone potrebbe avere un timeout diverso rispetto a Googlebot Image.

  • 204 (no content / nessun contenuto)

Googlebot segnala alla pipeline di indicizzazione di non aver ricevuto alcun contenuto. Search Console potrebbe mostrare un errore soft 404 nel rapporto sullo stato di copertura dell’indice del sito.

Status code 3xx (redirects)

Googlebot segue fino a 10 reindirizzamenti, come accennato: se il crawler non riceve il contenuto entro 10 hop, Search Console mostrerà un errore di reindirizzamento nel rapporto sulla copertura dell’indice del sito. Il numero di passaggi che Googlebot segue dipende dall’user agent, e ad esempio Googlebot Smartphone potrebbe avere un valore diverso da Googlebot Image.

Google segnala, inoltre, che nel caso di robots.txt segue almeno cinque hop di reindirizzamento come definito da RFC 1945, quindi si ferma e lo tratta come errore 404 per il file robots.txt.

Inoltre, anche se la Ricerca Google tratta alcuni di questi codici di stato allo stesso modo, bisogna considerare che sono semanticamente diversi: pertanto, il consiglio è di utilizzare sempre il codice di stato appropriato per il reindirizzamento, in modo che altri client (ad esempio e-reader, altri motori di ricerca) possano trarne vantaggio.

  • 301 (moved permanently / spostato in modo permanente)

Googlebot segue il reindirizzamento e la pipeline di indicizzazione utilizza il reindirizzamento come un segnale forte che il target di reindirizzamento dovrebbe essere canonico.

  • 302 (found / trovatp)
  • 303 (see other / vedi altro)

In entrambi i casi, Googlebot segue il reindirizzamento e la pipeline di indicizzazione utilizza il reindirizzamento come un segnale debole che il target di reindirizzamento dovrebbe essere canonico.

  • 304 (not modified / non modificato)

Googlebot segnala alla pipeline di indicizzazione che il contenuto è lo stesso dell’ultima volta che è stato sottoposto a scansione. La pipeline di indicizzazione può ricalcolare i segnali per l’URL, ma in caso contrario il codice di stato non ha alcun effetto sull’indicizzazione.

  • 307 (temporary redirect / reindirizzamento temporaneo)

Equivale al codice 302.

  • 308 (moved permanently / sostato in modo permanente)

Equivale al codice 301.

Status code 4xx (client errors)

Sono definiti client errors, errori del client, i codici di stato nel range 4xx: in questi casi, la pipeline di indicizzazione di Google non considera per l’indicizzazione gli URL che restituiscono tale status code, e gli URL che sono già indicizzati e restituiscono un codice di stato 4xx vengono rimossi dall’indice.

Più precisamente, tutti gli errori 4xx, tranne 429, vengono trattati allo stesso modo: Googlebot segnala alla pipeline di indicizzazione che il contenuto non esiste. La pipeline di indicizzazione rimuove l’URL dall’indice, se è stato precedentemente indicizzato, mentre le nuove pagine 404 incontrate non vengono elaborate. La frequenza di scansione diminuisce gradualmente.

Google invita inoltre a non utilizzare gli status code 401e 403 per limitare il crawl rate: a parte del 429, i codici di stato 4xx “non hanno alcun effetto sul crawl rate”, chiarisce il documento.

  • 400 (bad request / cattiva richiesta)
  • 401 (unauthorized / non autorizzato)
  • 403 (forbidden / proibito)
  • 404 (not found / non trovato)
  • 410 (gone / rimosso)
  • 411 (length required / lunghezza richiesta)
  • 429 (too many requests / richieste eccessive)

Googlebot tratta il codice di stato 429 come un segnale che il server è sovraccarico, considerandolo un errore del server.

Status code 5xx (server errors)

Gli errori del server 429 e 5xx spingono i crawler di Google a rallentare temporaneamente la scansione; gli URL già indicizzati vengono conservati nell’indice, ma alla fine vengono eliminati.

Inoltre, se il file robots.txt restituisce un codice di stato di errore del server per più di 30 giorni, Google utilizzerà l’ultima copia cache del robots.txt; se non disponibile, Google presume che non ci siano restrizioni alla scansione.

  • 500 (internal server error / errore interno del server)
  • 502 (bad gateway)
  • 503 (service unavailable / servizio non disponibile)

In tutti questi casi, Googlebot riduce la frequenza di scansione del sito: questa diminuzione è proporzionale al numero di singoli URL che restituiscono un errore del server. La pipeline di indicizzazione di Google rimuove dall’indice gli URL che restituiscono in modo persistente un errore del server.

Google ed errori di rete e di DNS

Gli errori di rete e DNS hanno effetti rapidi e negativi sulla presenza di un URL nella Ricerca Google.

Googlebot tratta i timeout di rete, il ripristino della connessione e gli errori DNS in modo simile agli errori del server 5xx. In caso di errori di rete, la scansione inizia immediatamente a rallentare, poiché un errore di rete è un segno che il server potrebbe non essere in grado di gestire il carico di servizio. Gli URL già indicizzati che sono irraggiungibili verranno rimossi dall’indice di Google entro pochi giorni. Search Console può generare errori per ogni rispettivo errore.

Debug degli errori di rete

Gli errori di rete (network errors) si verificano prima che Google inizi la scansione di un URL o durante la scansione dell’URL. Poiché possono verificarsi prima che il server possa rispondere, non esiste un codice di stato che possa suggerire problemi, e quindi la diagnosi di questi errori può essere più impegnativa.

L’errore può essere in qualsiasi componente del server che gestisce il traffico di rete. Ad esempio, dice il documento, le interfacce di rete sovraccariche possono far cadere i pacchetti e portare a timeout (impossibilità di stabilire una connessione) e a resettare le connessioni (RST pacchetto inviato perché una porta è stata chiusa per errore).

Per eseguire il debug degli errori di timeout e ripristino della connessione Google suggerisce di:

  • Guardare le impostazioni e i log del firewall, perché potrebbe esserci un set di regole di blocco troppo ampio.
  • Guardare il traffico di rete. Utilizza strumenti come tcpdumpWireshark è possibile acquisire e analizzare i pacchetti TCP e cercare anomalie che puntano a uno specifico componente di rete o modulo server.
  • Contattare la società di hosting se non si trova nulla di sospetto.

Debug degli errori DNS

Di solito, gli errori DNS dipendono da una configurazione errata.

Per eseguire il debug degli errori DNS, Google invita a procedere in questo modo:

  • Controllare i record DNS, per verificare che i record A e CNAME siano rivolti rispettavamente agli indirizzi IP e hostname corretti, come mostrato nell’immagine.

Verifica dei DNS record

  • Verificare che tutti i name servers puntino agli indirizzi IP corretti del sito, come mostrato nell’immagine.

Verificare name servers per evitare errori

  • Attendere la propagazione delle modifiche: se abbiamo apportato modifiche alla configurazione DNS nelle ultime 72 ore, potrebbe essere necessario attendere che le modifiche si propaghino nella rete DNS globale. Per accelerare la propagazione, possiamo svuotare la cache del DNS pubblico di Google.
  • Controllare il server DNS: se eseguiamo il nostro server DNS privato, dobbiamo assicurarci che sia integro e che non sia sovraccarico.