Dati Google: una nuova pagina viene scoperta in circa 20 ore e aggiornata ogni 30 giorni

Gary Illyes di Google ha usato un evento Search Central Live Deep Dive di tre giorni in Europa per mostrare dati interni sui tempi reali di scansione, indicizzazione e pubblicazione. Ne riferisce Barry Schwartz sul Search Engine Roundtable del 5 ottobre. I numeri erano divisi in tempo più rapido, tempo tipico e tempo più lento.

Il dato principale: un nuovo URL viene di solito scoperto in circa 20 ore, ma nel caso più lento si arriva a settimane, o mai.

È su questo scarto che gli editori dovrebbero soffermarsi. Scoperta non significa indicizzazione, e indicizzazione non significa posizionamento o traffico. Illyes ha avvertito che molti di questi processi sono collegati, quindi i ritardi si sommano: una pagina non può essere indicizzata finché non è stata scansionata, e non può ottenere un clic finché non è stata indicizzata e posizionata. Schwartz cita anche il SEO francese Neil McCarthy, che ha pubblicato altro su LinkedIn, e John Campbell di We Are Roast, che nei suoi appunti dall'evento ha definito i dati "brand new information".

Cosa dicono i tempi, voce per voce

La tabella pubblicata da Schwartz copre molto più della scansione. Aggiornare un URL noto richiede di solito circa 30 giorni, con un caso più lento che va da settimane a mai. L'elaborazione della sitemap richiede di solito circa 24 ore ma può arrivare a 14 giorni, o mai per motivi di qualità. Un aggiornamento del robots.txt arriva in circa 24 ore, con 25 ore come caso più lento.

Gli aggiornamenti della capacità di scansione richiedono di solito da 4 ore a 1 o 2 settimane, e da 1 a 3 settimane quando Google è in fase di recupero. Gli aggiornamenti della domanda di scansione richiedono di solito circa 20 ore, da settimane a mesi nei casi estremi. La capacità di scansione stessa può calare in pochi secondi quando Google si ritira, per esempio se un server fatica. È un avvertimento per chi ha un'infrastruttura che vacilla sotto carico.

L'indicizzazione da capo a fondo richiede di solito circa 1,5 ore, ma il caso più lento è di mesi o mai per motivi di qualità. I cambiamenti di canonicalizzazione richiedono di solito da 1 a 3 settimane e mesi con segnali contrastanti. Un trasferimento di sito richiede di solito da 1 a 3 mesi e da 6 mesi a 1 anno o più nei casi estremi. La rimozione dall'indice richiede di solito da 1 a 3 settimane, mesi nel caso più lento.

Sul fronte della pubblicazione, gli aggiornamenti di titolo e snippet richiedono di solito da 1 a 2 giorni, con diverse settimane o mesi nel caso più lento. Le meta annotazioni richiedono di solito da 45 a 90 minuti e da 1 a 4 giorni nei casi estremi. Le annotazioni dei link richiedono di solito da minuti a 1 o 3 settimane e mesi nel caso più lento. Il recupero dopo un core update richiede di solito da 3 a 6 mesi, con da 6 mesi a 1 anno nel caso più lento, cioè il core update successivo.

Illyes è stato prudente su come leggere le slide. "Tenete presente che questo era un esercizio per vedere se il pubblico riesce a riconoscersi nei numeri che abbiamo estratto internamente e messo in quelle slide", ha detto a Schwartz dopo la pubblicazione del post. Sono quindi cifre interne illustrative, non un accordo sul livello di servizio.

Perché gli editori guardano ai tempi di scansione

Per un sito di notizie contano più i numeri del caso peggiore di quelli tipici. Una storia scoperta in 20 ore è già morta sui social. Un ciclo di aggiornamento misurato in circa 30 giorni significa che un titolo corretto o una notizia in sviluppo aggiornata può non comparire per un mese. Un cambio di canonicalizzazione misurato in settimane può lasciare versioni duplicate della stessa storia in competizione per la stessa query.

I dati sulla pubblicazione vanno nella direzione opposta per chi insegue clic. Se un aggiornamento del titolo richiede di solito da 1 a 2 giorni, ritoccare i titoli per la ricerca è una leva lenta, non rapida. Lo stesso vale per gli aggiornamenti dei dati strutturati, che la tabella colloca di solito tra ore e 1 o 2 settimane e, nel caso più lento, a settimane o mai.

La domanda più grande: dove è finito il traffico

I tempi di scansione sono una questione tecnica. La questione commerciale, che il dossier tocca solo indirettamente, è che gli editori stanno già discutendo di un calo dei referral da ricerca. Ora Google consegna loro un documento che spiega l'impianto idraulico senza affrontare il deflusso.

La discussione è arrivata in tribunale. Titoli recenti riportano che un giudice ha respinto le cause presentate da Chegg e Penske sugli AI Overviews, con la motivazione riassunta come un'aspettativa che non è un accordo, e che Google ha ottenuto il rigetto delle cause sull'impatto della ricerca AI sul traffico dei siti. Quei titoli sono contesto dalle agenzie, non fatti stabiliti in questo dossier. Le sentenze alla base vanno lette direttamente prima di citarle come precedente.

Ciò che il dossier stabilisce è che l'industria della misurazione intorno alla ricerca si sta ricostruendo. Search Engine Land ha riportato il 5 ottobre che l'uso dell'AI è sestuplicato per la ricerca locale, frammentando l'ecosistema digitale, e ha trattato separatamente OpenAI che porta annunci visivi e misurazione estesa su ChatGPT. Digital Information World ha riportato che gli AI Overviews di Google sono comparsi nel 13,7% delle ricerche, con l'11% di affermazioni non supportate e potenziali rischi di ricavi per gli editori.

Nessuno di questi numeri viene da Google. Vanno trattati come stime di terzi con metodi propri. Va anche notato che divergono nell'enfasi dalla narrazione di Google, che presenta le funzioni AI come un'aggiunta alla ricerca e non come una sottrazione ai referral.

Cosa può fare davvero un editore con questi dati

La lettura pratica della tabella di Google è che i guadagni facili stanno sul fronte della scoperta. Sitemap, robots.txt e domanda di scansione si risolvono tutti in circa un giorno nel caso tipico, quindi un editore che li sistema per primo vede muoversi qualcosa più in fretta. Il lavoro su canonical e trasferimento di sito è un progetto da trimestre, e va pianificato come tale.

Secondo, l'avvertenza sulla qualità si ripete in tutta la tabella. Elaborazione della sitemap, indicizzazione, dati strutturati e analisi video possono tutti finire in "mai" per motivi di qualità. È il modo cortese di Google per dire che una pagina che non vuole indicizzare non sarà indicizzata, per quanto rapida sia la scansione.

Terzo, nulla nella tabella promette traffico. Descrive come il contenuto entra nell'indice e come si propagano le modifiche. Se una pagina venga mostrata, e se un utente la clicchi invece di leggere un riassunto AI, è un sistema separato con regole separate che Google non ha pubblicato con lo stesso dettaglio.

Il contesto tecnico più ampio nel dossier ricorda quanto dello strato di scoperta del web passi ormai dalle macchine. Cloudflare ha lanciato in beta una Web Search API il 2 ottobre, che consente ad agenti AI e applicazioni di cercare su internet tramite i fornitori Ceramic.ai, Exa e Linkup. Le richieste di ricerca vengono registrate e fatturate tramite il suo AI Gateway, secondo la documentazione per sviluppatori dell'azienda. Ogni fornitore restituisce un link alla fonte di ciascun risultato, afferma Cloudflare.

È una pipeline diversa da Googlebot, e non dipende dal budget di scansione né da un aggiornamento a 30 giorni. È anche, per ora, una beta con tre fornitori.

Per gli editori i due sistemi puntano in direzioni opposte. I dati di Google dicono che l'indice classico è lento ad aggiornarsi e può rifiutarsi del tutto di indicizzare. Lo strato di ricerca per agenti dice che le risposte possono basarsi su risultati live con una sola chiamata API. Quale dei due porti i lettori, e la pubblicità, è la domanda a cui la tabella delle scansioni non può rispondere.