Uno degli aspetti chiave per la visibilità del tuo sito web riguarda l’interazione con i crawler di Google, i bot che eseguono la scansione del tuo contenuto per indicizzarlo nei risultati di ricerca. Due elementi fondamentali di questa interazione sono le “Statistiche di scansione” di Google e il “Time to First Byte” (TTFB). Entrambi questi fattori possono avere un impatto significativo sulla frequenza con cui Google visita il tuo sito e su quanto velocemente il tuo contenuto viene indicizzato.
Le statistiche di scansione di Google sono un insieme di dati che descrivono come i crawler di Google interagiscono con il tuo sito. Questi dati possono includere il numero di richieste di scansione effettuate, il tempo impiegato per scaricare una pagina, il successo o il fallimento delle richieste e altro ancora. In generale, il tuo obiettivo dovrebbe essere quello di avere un tempo di scansione il più basso possibile. Un tempo di scansione più basso significa che i bot di Google possono eseguire la scansione di più pagine in meno tempo, il che a sua volta può aumentare la frequenza con cui il tuo sito viene indicizzato.
Il Time to First Byte (TTFB) è un’altra metrica fondamentale nel mondo SEO, ne abbiamo ampiamente discusso in questo post. Si tratta del tempo che intercorre tra il momento in cui un client (come un browser web o un crawler di Google) effettua una richiesta HTTP e il momento in cui riceve il primo byte di dati dal server. Anche in questo caso, un TTFB più basso è generalmente migliore: significa che i dati vengono trasmessi più rapidamente, il che può migliorare sia l’esperienza dell’utente che l’efficacia della scansione da parte di Google.
Una convinzione comune è che i Google Bot che eseguono la scansione del tuo sito provengano da data center europei, tuttavia, un’analisi più accurata rivela una realtà diversa. Guardando i file access.log del tuo webserver, è possibile geolocalizzare gli IP dei crawler e scoprire che molti di essi provengono dagli Stati Uniti, in particolare da Mountain View, California. Questo aggiunge un’ulteriore latenza di circa 100ms, come si può vedere effettuando un ping all’IP.
Ad esempio prendiamo in esame questo IP di Google Bot 66.249.64.239 che abbiamo recuperato da un file di log recente:
66.249.64.239 - - [14/May/2023:03:37:25 +0200] "GET /wp-includes/js/jquery/jquery.min.js HTTP/2.0" 200 31017 "https://www.ilcorrieredellacitta.com/news" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/113.0.5672.63 Safari/537.36"
Probabilmente molti di voi sanno che Google è a Mountain View e l’avrete sentito nominare migliaia di volte, tuttavia pochi hanno cognizione di causa di dove sia Mountain View a livello geografico.
Mountain View è una città situata nella regione della Silicon Valley, nella contea di Santa Clara, nello stato della California, negli Stati Uniti d’America. Situata sulla costa occidentale del continente americano, Mountain View si affaccia sull’Oceano Pacifico. La sua posizione geografica è diametralmente opposta rispetto all’Europa: se si considera il viaggio da est a ovest, l’Europa si trova sull’altro lato dell’Oceano Atlantico, a migliaia di chilometri di distanza. Questa distanza è amplificata dalla presenza del continente americano tra i due punti.
La distanza ovviamente comporta un tempo da percorrere ed anche qualora volessimo prendere come mezzo di propagazione la fibra ottica che ha una velocità vicino a quella della luce (ma non quella della luce), vanno necessariamente sommate le tempistiche dei vari dispositivi di rete, come router e switch dei vari HOP come da traceroute seguente ad esempio.
Proviamo ora come test aggiuntivo a pingare l’IP 66.249.64.239 per misurare il tempo di latenza inverso, ovvero dal server web al bot di Google.
Vediamo chiaramente una latenza di 104ms, ed indicativamente rispetto ad una tratta europea efficiente che si pinga in massimo 20 ms, abbiamo un “extra” di circa 80ms.
Questa latenza può sembrare piccola, ma si somma certamente, e nel corso del tempo, specialmente se il tuo sito ha molte pagine o se viene visitato spesso dai crawler.
Una conseguenza diretta di tempi di scansione più alti è una diminuzione visibile delle richieste di scansione da parte di Google. Questo è dovuto a una limitazione nota come “crawl budget”, che è il numero di pagine che Google può e vuole eseguire la scansione in un determinato periodo di tempo. Se il tuo sito richiede troppo tempo per rispondere alle richieste dei crawler, Google potrebbe decidere di limitare il numero di pagine che esegue la scansione, il che potrebbe a sua volta ridurre la visibilità del tuo sito nei risultati di ricerca.
Vediamo ad esempio un report di un nostro ex cliente che da poco ha migrato il suo sito su un noto fornitore di Hosting ad alte performance (almeno loro dicono così), notando cosa abbia comportato in termini pratici.
Risulta lapalissiano ed estremamente evidente, che a seguito del cambio fornitore, la linea arancione del tempo medio di risposta si sia letteralmente impennata, passando da un buon valore di 160 millisecondi a ben 663 millisecondi, ovvero oltre 4 volte più lento. In parole povere a voler fare il conto della serva, i bot di Google impiegano per recuperare i contenuti dal sito, un tempo 4 volte superiore quello che impiegava prima.
Se vediamo infatti le richieste di scansione totali nel prima della migrazione e dopo la migrazione notiamo come siano passate da circa 30 mila ad appena 10 mila, con una perdita di circa 2/3, un valore questo estremamente preoccupante soprattutto su siti di tipo editoriale che tendono a produrre molti contenuti ogni giorno.
Ripetendo l’analisi delle statistiche di scansione di Google, dopo circa 20 giorni, vediamo che il Tempo medio di risposta è passato dagli ottimali 160ms, agli attuali 1550, con punte di oltre 300 millisecondi, con un peggioramento della velocità di scansione dalle 10 alle 20 volte.
Le richieste di scansione sono ovviamente ulteriormente peggiorate, passando da circa 30 mila ad appena 5000, decretando di fatto la morte del sito sui motori di ricerca, su Google News e su Discovery.
In merito al TTFB dei motori di ricerca, possiamo trovare una eloquente testimonianza tramite il tool SpeedVitals che ci riporta le seguenti metriche per ciò che concerne i valori europei:
Nonostante l’importanza di queste metriche, molti proprietari di siti e tecnici non sono pienamente consapevoli del loro impatto. Alcuni potrebbero non sapere cosa siano le statistiche di scansione di Google, mentre altri potrebbero non comprendere la relazione tra il TTFB e la frequenza di scansione. Questa mancanza di consapevolezza può portare a decisioni non ottimali riguardanti l’hosting del sito, la sua struttura e la sua ottimizzazione per i motori di ricerca, nonché a saper valutare correttamente un fornitore di hosting come noi che all’apparenza, agli occhi di un profano o un sedicente esperto “vende hosting come tutti”.
Ad esempio, un proprietario di sito potrebbe scegliere un provider di hosting basato principalmente sul prezzo, o su mirabolanti promesse commerciali e payoff sensazionali, senza tener conto del fatto che al di là del marketing e delle belle promesse, sono i fatti a qualificare la bontà di un fornitore, nonché che i server più lenti o più distanti possono aumentare il TTFB e quindi ridurre l’efficacia delle scansioni di Google. Allo stesso modo, un tecnico potrebbe concentrarsi su aspetti come la scelta delle parole chiave o il design del sito, trascurando il fatto che una struttura del sito complessa o un codice inefficiente possono aumentare il tempo di scansione e ridurre il crawl budget rendendo vane anche le migliori intenzioni.
Le statistiche di scansione di Google e il TTFB sono due fattori critici che possono influenzare notevolmente la visibilità del tuo sito nei risultati di ricerca. Per ottimizzare l’interazione del tuo sito con i crawler di Google, è fondamentale comprendere queste metriche e prenderle in considerazione in ogni decisione relativa al tuo sito. Questo può includere la scelta di un provider di hosting adatto come il nostro, l’ottimizzazione dello stack software lato server ed il monitoring costante delle tue statistiche di scansione e del tuo TTFB.
Servizi CDN come soluzione o palliativi al problema.
Almeno a livello teorico, una delle strategie più efficaci per migliorare il tempo di scansione è l’implementazione di un solido stack software, compreso un sistema di caching lato server adeguatamente configurato con un rapporto di HIT il più alto possibile.
Tuttavia, anche con la migliore configurazione lato server, eseguendo operazioni come l’accelerazione dell’ handshake della sessione SSL, l’abilitazione dell’OCSP Stapling, del TCP BBR e del TCP Fast Open, un tuning certosino del Kernel (come siamo abituali fare in Managed Server S.r.l.) ci troviamo inevitabilmente di fronte al limite imposto dalla distanza fisica. Questo è particolarmente vero soprattutto per i siti ospitati in Europa che devono interagire con i crawler di Google basati a Mountain View, in California.
Per superare questa sfida, molti professionisti del settore si rivolgono ai servizi di Content Delivery Network (CDN) in modalità Platform as a Service (PaaS). Queste soluzioni offrono la possibilità di avere copie cache dei contenuti del sito su nodi più vicini a Mountain View attraverso l’utilizzo del routing AnyCast.
Una CDN è una rete di server distribuiti geograficamente che lavorano insieme per fornire contenuti web in modo rapido. Questi server, noti come punti di presenza (POP), memorizzano copie dei contenuti del sito web. Quando un utente o un bot richiede l’accesso a questi contenuti, la richiesta viene inviata al POP più vicino, riducendo così il tempo necessario per trasmettere i dati.
L’origin, nel contesto di una CDN, è il server o il gruppo di server da cui provengono i contenuti originali. Questi server origin forniscono i contenuti ai POP della CDN, che a loro volta li distribuiscono agli utenti finali.
Il routing AnyCast è un metodo di instradamento del traffico di rete in cui le richieste di un utente vengono instradate al nodo più vicino in termini di tempo di risposta. Questo può aiutare a ridurre significativamente il TTFB poiché i dati non devono viaggiare lunghe distanze prima di raggiungere l’utente o il bot.
Nel contesto delle reti di computer, l’Anycast è un metodo di instradamento del traffico di rete che consente a più dispositivi di condividere lo stesso indirizzo IP. Questo metodo di instradamento è particolarmente popolare nei servizi di Content Delivery Network (CDN) e nei Domain Name System (DNS), in quanto consente di ridurre la latenza e migliorare la resistenza della rete.
Per comprendere come funziona il routing Anycast, immagina una rete di server distribuiti in diverse posizioni geografiche in tutto il mondo. Ciascuno di questi server condivide lo stesso indirizzo IP pubblico. Quando un utente invia una richiesta a quell’indirizzo IP, la richiesta viene instradata al server “più vicino” a quell’utente. Qui, il termine “più vicino” non si riferisce necessariamente alla distanza fisica, ma piuttosto alla distanza in termini di salti di rete o al tempo di risposta più breve. In pratica, ciò significa che l’utente si connetterà al nodo che può rispondere più rapidamente alla sua richiesta.
Il bello del routing Anycast è che è completamente trasparente per l’utente finale. Non importa dove si trova l’utente o quale server risponde alla sua richiesta: l’indirizzo IP è sempre lo stesso. Questo rende il sistema estremamente flessibile e resiliente. Se un server dovesse andare offline o diventare sovraccarico, il traffico può essere facilmente reindirizzato a un altro server senza interruzioni per l’utente.
Tuttavia, è importante sottolineare che “CDN” è un termine generico che può riferirsi a una vasta gamma di servizi, ciascuno con le sue peculiarità. Non tutte le CDN sono create uguali, e per ottenere i massimi benefici da una CDN, è essenziale comprenderne le specifiche e configurarla correttamente.
In molti casi, l’utilizzo di CDN commerciali comuni può non portare i benefici attesi. Ad esempio, sebbene una CDN possa avere POP vicino a Mountain View, una configurazione errata o una progettazione subottimale della CDN può comportare che questi POP non abbiano una copia cache dei contenuti del sito. In questo caso, le richieste dei crawler di Google vengono reindirizzate all’origin, peggiorando potenzialmente la velocità di risposta.
Questo problema può essere particolarmente grave se l’origin non dispone di un sistema di cache locale capace di fornire i contenuti ai crawler in pochi millisecondi. In tal caso, l’uso di una CDN può finire per rallentare le richieste piuttosto che accelerarle, avendo un impatto negativo sul tempo di scansione e, di conseguenza, sulla visibilità del sito nei risultati di ricerca di Google.
Il problema può essere ulteriormente esacerbato se la CDN non è configurata correttamente per il caching. Alcune CDN offrono un gran numero di opzioni di configurazione, ognuna delle quali può avere un impatto significativo sulle prestazioni. Se queste opzioni non vengono configurate correttamente, la CDN potrebbe non essere in grado di servire efficacemente i contenuti in cache, il che può portare a tempi di risposta più lunghi.
Il miglior modo per monitorare le Statistiche di scansione di Google.
Al di là delle tecnologie utilizzate e dei fornitori coinvolti, il modo più efficace per monitorare le statistiche di scansione di Google e il tempo medio di risposta è attraverso l’utilizzo di Google Search Console. Il pannello “Statistiche di scansione” fornisce informazioni dettagliate e aggiornate sulle attività di scansione del tuo sito web da parte di Google. È consigliabile accedere a questa sezione con una frequenza settimanale per monitorare attentamente le prestazioni del tuo sito.
Per un funzionamento ottimale, il tempo medio di risposta dovrebbe essere sempre inferiore ai 200 millisecondi. Questo valore rappresenta il tempo teorico massimo che Googlebot dovrebbe impiegare per ottenere una risposta dal tuo server, e un valore più basso significa che Googlebot può eseguire la scansione delle tue pagine in modo più efficiente, migliorando il tuo crawl budget e la considerazione da parte di Google. Puoi monitorare il tuo tempo medio di risposta attraverso il link alle Statistiche di Scansione di Google Search Console.
Il valore 200ms non è un valore casuale, ma bensì il valore massimo indicato esplicitamente da Google https://developers.google.com/speed/docs/insights/Server?hl=it, e dovrebbe essere una best practices da rispettare a prescindere come indicato nei suggerimenti per migliorare la risposta del server.
Se noti che il tuo tempo medio di risposta è superiore a 200 millisecondi, o se hai problemi con le tue statistiche di scansione, non esitare a contattarci. I nostri esperti sono a disposizione per aiutarti a trovare una soluzione rapida e migliorare le prestazioni del tuo sito web. Ricorda, un sito web veloce e reattivo non è solo benefico per i tuoi utenti, ma è anche un fattore chiave per una buona SEO.
