È il crawl budget il tema centrale del secondo appuntamento con SEO Mythbusting season 2 (registrato prima dell’emergenza Covid-19, giusto per essere precisi), in cui il Developer Advocate di Google, Martin Splitt, cerca di sfatare miti e chiarire i dubbi frequenti sui topic SEO. E quindi, scopriamo gli spunti interessanti che arrivano sul tema dell’ottimizzazione del budget di scansione che il motore di ricerca dedica a ogni sito!

Capire il crawl budget e riconoscere i falsi miti

Ospite dell’episodio è Alexis Sanders, Senior Account Manager presso l’agenzia di marketing Merkle, che chiede al Googler di soffermarsi su un topic che crea parecchie difficoltà di comprensione ai suoi clienti, per l’appunto il crawl budget, partendo dalle definizioni e dai consigli di gestione di questo aspetto.

Martin Splitt inizia quindi il suo approfondimento dicendo che “quando parliamo di Google Search, di indicizzazione e di crawling, dobbiamo fare una sorta di compromesso: Google vuole sottoporre a scansione la quantità massima di informazioni nel più breve tempo possibile, ma senza sovraccaricare i server”, trovando cioè il crawl limit o crawl rate (se ne parlava già in questo articolo).

La definizione di crawl rate

Per la precisione, il crawl rate viene definito come il numero massimo di richieste parallele che Googlebot può fare in simultanea senza sovraccaricare un server, e quindi in pratica indica la quota massima di stress che Google può esercitare su un server senza portare nulla al crash o generare disagi per questo sforzo.

Google deve controllare anche le sue risorse

Google deve però fare attenzione solo alle risorse altrui, ma anche alle proprie, perché “il Web è enorme e non possiamo sottoporre a scansione tutto per tutto il tempo, ma fare alcune distinzioni”, spiega Splitt.

Ad esempio, prosegue, “un sito di news probabilmente cambia piuttosto spesso, e quindi noi probabilmente dobbiamo stare al suo passo con una frequenza elevata: al contrario, un sito sulla storia del kimchi probabilmente non cambierà così assiduamente, perché la storia non ha lo stesso passo rapido del settore delle notizie di attualità”.

Che cos’è il crawl demand

Si spiega così che cos’è il crawl demand, ovvero la frequenza con cui Googlebot sottopone a scansione un sito (o, meglio, a una tipologia di sito) in base alla sua probabilità di aggiornamento. Come dice Splitt nel video, “cerchiamo di capire se è il caso di passare più spesso o se invece possiamo dare una controllata di tanto in tanto”.

Il processo di decisione di questo fattore si basa sull’identificazione che Google fa del sito alla prima scansione, quando in pratica prende le “impronte digitali” dei suoi contenuti, vedendo il topic della pagina (che sarà usato anche per la deduplicazione, in fase successiva) e analizzando anche la data dell’ultima modifica.

Il sito ha la possibilità di comunicare le date a Googlebot – ad esempio, attraverso i dati strutturati o altri elementi temporali in pagina – che “più o meno tiene traccia della frequenza e della tipologia dei cambiamenti: se rileviamo che la frequenza delle modifiche è molto bassa, allora non sottoporremo il sito a scansione con particolare cadenza”.

La frequenza di scansione non riguarda la qualità dei contenuti

Molto interessante è la puntualizzazione successiva del Googler: questo tasso di scansione non ha nulla a che vedere con la qualità, dice. “Puoi avere contenuti fantastici che si posizionano benissimo, che non cambiano mai”, perché ciò la questione in questo caso è “se Google deve passare di frequente sul sito per un crawling o se può lasciarlo tranquillo per un certo periodo di tempo”.

Per aiutare Google a rispondere in modo corretto a questa domanda, i webmaster hanno a disposizione vari strumenti che danno “suggerimenti”: oltre ai già citati dati strutturati, si possono usare ETag o gli HTTP headers, utili per segnalare la data dell’ultima modifica nelle sitemap. È però importante che gli aggiornamenti siano utili: “Se aggiorni solo la data nella sitemap e ci accorgiamo che non c’è alcuna modifica vera sul sito, o che sono cambiamenti minimi, non ci sei di aiuto” nell’individuare la probabile frequenza di modifiche.

Quando il crawl budget è un problema?

Secondo Splitt, il crawl budget è comunque un tema che prioritariamente dovrebbe interessare o preoccupare i siti enormi, “diciamo con milioni di url e di pagine”, a meno che tu “non abbia un server scadente e inaffidabile”. Ma in quel caso, “più che sul crawl budget dovresti concentrarti sull’ottimizzazione del server”, prosegue.

Di solito, secondo il Googler, si parla di crawl budget a sproposito, quando non c’è un vero problema collegato; per lui, i crawl budget issues capitano quando un sito nota che Google scopre ma non scansiona le pagine di cui gli importa per un periodo ampio di tempo e tali pagine non presentano problemi o errori di sorta.

Nella maggioranza dei casi, invece, Google decide di sottoporre a scansione ma non indicizzare le pagine perché “non ne vale la pena a causa della scarsa qualità del contenuto presente”. In genere, questi url sono marcati come “esclusi” nel rapporto sulla copertura dell’Indice della Google Search Console, chiarisce il video.

La crawl frequency non è un indicatore di qualità

Avere un sito sottoposto a scansione con grande frequenza non rappresenta necessariamente un aiuto per Google perché la crawl frequency non è un segnale di qualità, spiega ancora Splitt, perché per il motore di ricerca è OK anche se “avere qualcosa sottoposto a crawling, indicizzato e che non cambia più” e non richiede altri passaggi del bot.

Qualche consiglio più mirato arriva per gli e-Commerce: se ci sono tantissime piccole pagine molto simili tra loro con contenuti affini, bisognerebbe pensare alla loro utilità chiedendosi innanzitutto se abbia senso la loro esistenza. Oppure, valutare la possibilità di estendere il contenuto per renderlo migliore? Ad esempio, se si tratta solo di prodotti che variano per una piccola caratteristica, si potrebbero raggruppare in una sola pagina con un testo descrittivo che include tutte le variazioni possibili (anziché avere 10 piccole pagine per ogni possibilità).

Il peso di Google sui server

Il crawl budget si collega a una serie di questioni, quindi: tra quelle citate ci sono appunto la duplicazione o la ricerca delle pagine, ma anche la velocità del server è un tema delicato. Se il sito si appoggia a un server che di tanto in tanto crolla, Google potrebbe avere difficoltà a comprendere se questo succeda per le caratteristiche povere del server o a causa di un sovraccarico delle sue richieste.

A proposito di gestione delle risorse del server, poi, Splitt spiega anche come funziona l’attività del bot (e quindi quello che si vede nei log files) nelle fasi iniziali della scoperta di Google o quando, ad esempio, si compie una migrazione del server: inizialmente, un incremento dell’attività di crawling, seguito da una lieve riduzione, che continua creando quindi un’onda. Spesso, però, il cambio di server non richiede una nuova riscoperta da parte di Google (a meno di passare da qualcosa di rotto a qualcosa che funziona!) e quindi l’attività del bot per il crawling resta stabile come prima dello switch.

Crawl budget e migrazione, i consigli di Google

Piuttosto delicata è anche la gestione dell’attività di scansione di Googlebot nel corso delle migrazioni complessive del sito: il consiglio che arriva dal video a chi si trova nel mezzo di queste situazioni è di aggiornare progressivamente la sitemap e segnalare a Google che cosa sta cambiando, così da informare il motore di ricerca che ci sono state modifiche utili da seguire e verificare.

Questa strategia offre ai webmaster un piccolo controllo di come Google scopre i cambiamenti nel corso di una migrazione, anche se in linea di massima è possibile anche attendere semplicemente che l’operazione si completi.

Ciò che conta è assicurare (e assicurarsi) che entrambi i server siano funzionanti e lavorino regolarmente, senza crolli improvvisi momentanei o status code di errore; importante è anche impostare correttamente i redirect e verificare che non ci siano risorse rilevanti bloccate sul nuovo sito attraverso un file robots.txt non adeguatamente aggiornato al nuovo sito post-migrazione.

Martin Splitt e Alexis Sanders parlano di crawl budget

Come funziona il crawl budget

Una domanda di Alexis Sanders ci riporta al tema centrale dell’appuntamento e consente a Martin Splitt di spigare come funziona il crawl budget e su quale livello del sito interviene: solitamente, Google opera sul livello del sito, quindi considera tutto ciò che trova sullo stesso dominio. I sottodomini possono essere scansionati a volte, mentre in altri casi risultano esclusi, mentre per i CDN “non c’è nulla di cui preoccuparsi”.

Un altro suggerimento pratico che arriva dal Googler riguarda la gestione dei contenuti user-generated, o più in generale le ansie sulla quantità di pagine presenti su un sito: “Puoi dirci di non indicizzare o di non scansionare contenuti che sono di bassa qualità”, ricorda Splitt, e quindi per lui la crawl budget optimization è “qualcosa che riguarda più il lato dei contenuti che l’aspetto dell’infrastruttura tecnica”, (approccio che è in linea con quello dei nostri strumenti!).

Non sprecare il tempo e le risorse di Google

In definitiva, lavorare sul crawl budget significa anche non sprecare il tempo e le risorse di Google, anche attraverso una serie di soluzioni molto tecniche come la gestione della cache.

In particolare, Splitt spiega che Google “cerca di essere il più aggressivo possibile quando fa caching di sub-risorse, come CSS, JavaScript, chiamate API, tutto questo genere di cose”. Se un sito ha “chiamate API che non sono richieste GET, allora non possiamo metterli in cache, e quindi bisogna essere molto attenti a fare le richieste POST o simili, che alcune API fanno di default”, perché Google non può “metterle in cache e questo consumerà più rapidamente il crawl budget del sito”.