Google quantifica i tempi di crawling, indexing e serving
I tempi tipici dei processi di Search: dalla scoperta di un URL al recovery dopo core update, passando per indicizzazione e migrazioni.
Un URL può entrare nell’indice in circa un’ora e mezza e impiegare mesi prima che un cambiamento di qualità produca un recupero visibile. Non sono scadenze fisse o garantite, perché mancano indicazioni più precise sul campione e sul periodo analizzato, ma i dati presentati da Gary Illyes durante il Search Central Live Deep Dive Europe offrono per la prima volta una base comune per confrontare processi che finora avevano riferimenti sparsi e molto diversi tra loro.
Google scopre un nuovo URL in circa 20 ore, mentre può impiegare circa 30 giorni per tornare su un URL già conosciuto e aggiornarlo. Una sitemap viene elaborata mediamente in 24 ore e anche una modifica al file robots.txt richiede più o meno un giorno. Cambiano invece molto i tempi che regolano il crawling: la frequenza con cui Google decide di tornare sulle pagine può aggiornarsi in circa 20 ore, mentre la capacità di scansione può richiedere da quattro ore a una o due settimane. Se il server mostra problemi, Googlebot può ridurre le richieste nel giro di pochi secondi.
Il rendering vero e proprio può completarsi in pochi secondi, dopo un’attesa in coda che può durare ore. Le informazioni ricavate dai meta tag vengono elaborate mediamente in 45-90 minuti, mentre quelle legate ai link possono richiedere da pochi minuti fino a tre settimane. L’indicizzazione completa, quando tutti i passaggi necessari terminano correttamente, si chiude tipicamente in circa un’ora e mezza; nei casi problematici può però trascinarsi per mesi o non completarsi affatto.
Anche i segnali associati alla pagina seguono calendari propri. Un cambio di canonical viene normalmente recepito in una-tre settimane, mentre segnali in conflitto possono allungare l’attesa per mesi. Gli aggiornamenti dei dati strutturati richiedono da alcune ore fino a una-due settimane; immagini e video si muovono generalmente nell’arco di ore o giorni, con tempi molto più lunghi nei casi che richiedono elaborazioni più complesse.
Lo spostamento di un intero sito porta invece la scala temporale sui mesi. Una migrazione richiede normalmente da uno a tre mesi e nei casi più lenti può arrivare da sei mesi a oltre un anno. I siti più piccoli possono completare il passaggio anche in poche settimane, mentre errori tecnici, segnali contraddittori o ritardi nelle fasi precedenti si trascinano su tutto ciò che viene dopo.
In SERP alcuni cambiamenti diventano visibili molto più velocemente. Title e snippet possono aggiornarsi in uno o due giorni, mentre una rimozione richiesta dal proprietario attraverso Search Console richiede mediamente circa due ore. La revoca di una manual action si muove invece tra una e due settimane nel caso tipico e può richiedere quattro-sei settimane, o ancora di più per siti rimasti inattivi.
Il tempo si allunga nettamente dopo un core update. Il recupero dopo gli interventi richiede mediamente da tre a sei mesi e nei casi più lenti può arrivare a sei-dodici mesi, fino al successivo aggiornamento principale. Per gli spam update il riferimento tipico scende invece a una-due settimane, anche se alcuni recuperi possono attendere aggiornamenti successivi dei sistemi.
Un’ora e mezza per essere indicizzati e sei mesi per recuperare visibilità possono quindi appartenere allo stesso sito senza alcuna contraddizione. Entrare nell’indice significa aver completato soltanto una parte del percorso: il posizionamento, il traffico e la stabilizzazione dei segnali dipendono da valutazioni successive. È per questo che i tempi della SEO cambiano radicalmente a seconda di ciò che stiamo aspettando: scansione, indicizzazione, trasferimento dei segnali, aggiornamento dei risultati o recupero dopo un cambiamento algoritmico.
I passaggi sono inoltre concatenati. Un URL deve essere scoperto prima di poter essere scansionato, deve essere scansionato prima di poter essere indicizzato e soltanto dopo alcuni cambiamenti possono riflettersi nei risultati. Un ritardo nelle prime fasi si trascina quindi anche sulle successive, facendo sembrare lento un processo che magari sta semplicemente aspettando il completamento di quello precedente.
Illyes ha presentato questi valori come dati ricavati dalle analisi interne di Google, precisando che servivano anche a verificare quanto fossero riconoscibili dal pubblico. Non sono stati pubblicati il campione, il periodo di osservazione né una definizione precisa di ciò che viene considerato “tipico”; inoltre, in diversi casi l’intervallo più lento arriva a mesi o perfino al mancato completamento del processo. I numeri vanno quindi letti come punti di riferimento, non scadenze.
Quattro settimane senza recupero dopo un core update restano, per esempio, molto lontane dai tre-sei mesi indicati come finestra tipica. Dopo una migrazione, due settimane di oscillazioni possono ancora rientrare nella normalità, mentre tre mesi rappresentano già il limite alto dell’intervallo più comune. Intervenire di nuovo prima che il processo precedente abbia avuto il tempo di completarsi rischia di aggiungere nuove variabili proprio mentre stiamo ancora cercando di misurare le vecchie.