Rendering: cos’è, come avviene e perché serve ai motori di ricerca

SEO Gennaro Mancini 8 Agosto 2023 Tempo di lettura : 14 minuti

Mettici alla prova

Analizza il tuo sito

Seleziona la lingua del database:

La fase di scoperta e analisi delle pagine web da parte dei motori di ricerca non si concretizza solo con il processo di indicizzazione che già conosciamo, ma c’è un altro momento decisivo in cui i crawler entrano in contatto con ciò che pubblichiamo: è il rendering, l’operazione di interpretazione e resa grafica della pagina, che gioca un ruolo cruciale nel modo in cui i siti web vengono visualizzati e indicizzati dai motori di ricerca. Questo processo può sembrare tecnico e complesso, ma è importante comprenderlo (almeno superficialmente) perché è una componente essenziale per garantire che i contenuti del nostro sito web siano facilmente accessibili e visibili sia per gli utenti che per gli stessi motori di ricerca. E quindi, con questa guida rapida scopriamo appunto come funziona il rendering, perché serve ai search engine e come può influenzare la SEO.

Che cos’è il rendering

Letteralmente, rendering deriva dal verbo inglese to render ed è traducibile con rappresentazione o resa grafica: il rendering è proprio la codificazione grafica delle informazioni presenti sulla pagina in linguaggio HTML, che vengono tradotte (rese) in modo da dare una forma comprensibile agli elementi grafici che compongono tutti i siti web, ciascuno con le sue caratteristiche.

In altre parole, in ambito Web il termine rendering si riferisce al processo attraverso il quale i motori di ricerca, come Google, interpretano e visualizzano il codice HTML di un sito web, al fine di “vedere” il sito web in modo simile a come lo vedrebbe un visitatore umano, per poter poi procedere correttamente alla fase dell’aggiunta agli specifici indici.

A consentire questo processo sono gli appositi motori di rendering, i rendering engine, che raccolgono e digeriscono i pacchetti dati in arrivo dal server e trasformano le righe di codice del linguaggio HTML in elementi grafici e funzionali, come ad esempio blocchi di testo con link ipertestuali, immagini, video e altri elementi come file PDF.

Le parole chiave del rendering: definizioni e chiarimenti

In termini più tecnici, il rendering è il processo di esecuzione del codice JavaScript di una pagina web per generare il layout visivo che vediamo quando visitiamo un sito: questo processo può essere eseguito sia dal lato client (ovvero nel browser dell’utente) che dal lato server.

L’HTML renderizzato è più ampiamente conosciuto come DOM, un’abbreviazione di Document Object Model: ogni pagina web ha un DOM, che rappresenta l’HTML iniziale più eventuali modifiche apportate da JavaScript richiamato dall’HTML.

Il rendering lato client significa che il codice JavaScript viene eseguito nel browser dell’utente, il che può richiedere più tempo e risorse; d’altra parte, il rendering lato server significa che il codice JavaScript viene eseguito sul server prima che la pagina venga inviata al browser dell’utente. Questo può accelerare il caricamento della pagina, ma richiede più risorse dal server.

Come spiegano gli esperti di web.dev, però, per comprendere e utilizzare al meglio le diverse architetture è importante conoscere innanzitutto la terminologia precisa da utilizzare quando ne parliamo. In particolare, ci sono alcune “parole chiave” e sigle con cui dobbiamo familiarizzare, che fanno riferimento anche ad approcci tecnici specifici:

Rendering lato server (SSR, Server Side Rendering): rendering di un’app lato client o universale in HTML sul server. Questa tecnica prevede che il server generi l’intera pagina HTML prima di inviarla al browser dell’utente, migliorando i tempi di caricamento della pagina e l’indicizzazione da parte dei motori di ricerca, ma rischiando anche di mettere a dura prova le risorse del server.
Rendering lato client (CSR, Client Side Rendering): rendering di un’app in un browser tramite JavaScript per modificare il DOM. Il browser dell’utente esegue JavaScript per generare la pagina HTML: questo può offrire un’esperienza utente interattiva, ma può rallentare i tempi di caricamento e rendere più difficile per i motori di ricerca indicizzare il sito.
SSG (Static Site Generation): le pagine HTML vengono generate in anticipo, durante la fase di build del sito, e salvate come file statici. Questo può offrire tempi di caricamento molto rapidi e un’ottima SEO, ma può essere meno flessibile per i siti con contenuti dinamici.
ISR (Incremental Static Regeneration): è una tecnica ibrida che combina SSR e SSG. Con ISR, le pagine vengono generate staticamente durante la fase di build, ma possono essere “rigenerate” su base incrementale quando i dati cambiano. Questo offre un buon equilibrio tra prestazioni e flessibilità.
DSR (Distributed Static Rendering): DSR è un’altra tecnica ibrida che combina elementi di SSR e SSG. Con DSR, le pagine vengono generate staticamente e distribuite su una rete di distribuzione dei contenuti (CDN) per un caricamento rapido. Tuttavia, le pagine possono anche essere rigenerate dinamicamente in risposta a specifici eventi o trigger.
ESR (Edge Side Rendering): Questa tecnica prevede che il rendering avvenga “al bordo” (edge), cioè il più vicino possibile all’utente finale, solitamente su un server di una rete di distribuzione dei contenuti (CDN). Questo può migliorare notevolmente i tempi di caricamento della pagina, poiché il contenuto viene renderizzato e servito da un luogo geograficamente vicino all’utente. ESR è particolarmente utile per i siti con un alto grado di personalizzazione utente o contenuti dinamici.
PRPL (Push, Render, Pre-cache, Lazy-load): Questa è una strategia di ottimizzazione delle prestazioni per migliorare il caricamento delle pagine. Consiste nel “spingere” le risorse critiche il più presto possibile, “renderizzare” l’interfaccia utente iniziale, “pre-cachare” le risorse rimanenti e “caricare pigramente” altre risorse man mano che diventano necessarie.
Reidratazione (Rehydratation): “avvio” delle viste JavaScript sul client in modo tale da riutilizzare l’albero e i dati DOM dell’HTML reso dal server.
Prerendering: esecuzione di un’applicazione lato client in fase di compilazione per acquisirne lo stato iniziale come HTML statico.

Dal punto di vista delle prestazioni, invece, le metriche interessate (e interessanti) sono:

Time to First Byte (TTFB), visto come il tempo che intercorre tra il clic su un collegamento e l’arrivo del primo bit di contenuto. Nella maggior parte dei casi, i problemi con TTFB hanno origine da scarse prestazioni del server su cui è ospitato il sito web, ma a volte anche in cui il sito web esegue il rendering di javascript o JS può determinare criticità; più rendering lato server poiché le informazioni devono essere recuperate da un server da una posizione diversa dal computer per eseguire il rendering del contenuto della pagina.
First Contentful Paint (FCP), il momento in cui il contenuto richiesto (corpo dell’articolo, ecc.) diventa visibile. I fastidi prestazionali con il First Paint si verificano in genere quando c’è un grosso problema sul lato CSS e JS delle cose di cui stanno tentando di caricare script e azioni non necessari per caricare il sito in un passato veloce. Tutto questo impatta negativamente su FCP, ad esempio, mentre altri problemi possono derivare dal modo in cui i dati vengono elaborati: SSR in genere ha una velocità di caricamento più costante, sia perché ha un hardware ripetibile rispetto a CSR, sia perché ci sono una varietà di dispositivi che possono influire sulla velocità con cui una pagina può recuperare e caricare il contenuto nel DOM.
Interaction to Next Paint (INP), visto come una metrica rappresentativa che valuta se una pagina risponde in modo coerente e rapido agli input dell’utente.
Time to Interactive (TTI), che misura il momento in cui una pagina diventa interattiva: se qualcosa è fortemente dipendente da JS, può ritardare ulteriormente la velocità della pagina e ostacolare le prestazioni.
Total Blocking Time (TBT), una metrica proxy per INP, che calcola la quantità di tempo in cui il thread principale è stato bloccato durante il caricamento della pagina.

Il rendering e la SEO: perché è necessario fare attenzione

Google non può indicizzare ciò che non può visualizzare: basta questa semplice considerazione per comprendere il valore cruciale dell’interpretazione e resa grafica della pagina rispetto alle sorti del sito sul motore di ricerca.

In realtà, quando pensiamo al ranking delle pagine ci viene in mente subito l’indicizzazione, dice Dave Davies sulle pagine di SEL, e in particolare al momento in cui un motore di ricerca ha già:

Scoperto una pagina tramite sitemap o crawling.
Continuato a visitare la pagina per l’indicizzazione.
Raccolto tutto il contenuto della pagina.
Iniziato a classificare la pagina per le query.

Questa è probabilmente la fase più importante del processo perché sono questi i fattori che influenzano le classifiche, ma non è la fase finale del processo di scoperta e, secondo Davies, il suo peso potrebbe diminuire nel tempo mentre la fase finale – ovvero il rendering – guadagna strada.

Il modo e, soprattutto, dove avviene il processo di rendering può infatti avere un impatto significativo sull’esperienza dell’utente, sulle prestazioni del sito e sull’ottimizzazione per i motori di ricerca (SEO). Come ha detto Martin Splitt di Google, il rendering della pagina Web è ciò che accade tra il browser e la pagina Web, il processo di creazione di una pagina Web: un processo di rendering efficiente si traduce in punteggi Core Web Vitals elevati, mentre al contrario un rendering meno efficiente può influire in una certa misura sulle vendite, sui guadagni pubblicitari e persino sulla scansione delle pagine web.

L’importanza del rendering per la SEO

Il rendering è strettamente legato alla SEO, poiché influisce sul fatto che e sul modo in cui i motori di ricerca interpretano e indicizzano i contenuti di un sito web: estremizzando, un buon rendering può migliorare la visibilità di un sito nei risultati di ricerca, mentre un rendering inefficiente può nascondere contenuti importanti dai motori di ricerca.

Per esempio, se un sito web fa un uso intensivo di JavaScript per generare i suoi contenuti, e questi contenuti non vengono correttamente renderizzati, i motori di ricerca potrebbero non essere in grado di “vedere” e quindi indicizzare questi contenuti, e ciò rischia quindi di determinare una riduzione della visibilità del sito nei risultati di ricerca.

Dobbiamo poi avere anche consapevolezza degli effetti negativi del rendering costoso per gli utenti, perché potrebbe influire sui visitatori che navigano il sito da telefoni più vecchi, provocando problemi a visualizzare la pagina, ma anche su dispositivi più recenti, che potrebbero avere problemi a scaricare una pagina Web se è attiva da giorni e la RAM è distribuita su più finestre del browser aperte.

Anche per questi motivi, è importante ottimizzare il rendering del sito web per la SEO, attraverso l’uso di tecniche come il rendering lato server o il prerendering, che generano una versione statica della pagina che può essere facilmente indicizzata dai motori di ricerca.

In effetti, le opzioni di rendering sono molteplici e sicuramente non vanno usate tutte sullo stesso progetto, anche perché la scelta dipende anche da elementi quali le tecnologie usate, come la piattaforma di hosting e il framework frontend. Inoltre, quando decidiamo un approccio al rendering, dovremmo partire dal misurare e comprendere quali sono i colli di bottiglia, valutando ad esempio se il rendering statico o il rendering lato server possono fare al caso nostro, oppure se spedire principalmente HTML con JavaScript minimo per ottenere un’esperienza interattiva.

Il consiglio che arriva dagli sviluppatori di web.dev è analizzare i pro e i contro e l’adattamento dei diversi approcci di rendering ai nostri progetti e ai tipi di siti che creiamo, così da scegliere in modo più informato strumenti e tecnologie, piuttosto che lasciare che siano queste scelte a dettare il nostro approccio.

Come ottimizzare il Rendering per la SEO, consigli di base

Per ottimizzare il rendering del sito per la SEO, è importante assicurarci che i contenuti cruciali del sito siano facilmente accessibili e indicizzabili da Google.

Un primo metodo per raggiungere l’obiettivo è comprendere, ed eventualmente implementare, tecniche come il rendering lato server (SSR), la generazione di siti statici (SSG) o il prerendering, che generano una versione statica della pagina che può essere facilmente indicizzata da Google. In particolare, le tecniche di rendering statico possono essere particolarmente efficaci, perché generano una versione statica della pagina durante la fase di build del sito, che può essere facilmente indicizzata dai motori di ricerca e offrire tempi di caricamento molto rapidi e un’ottima SEO; l’aspetto critico è che può essere meno flessibile per i siti con contenuti dinamici.

In questi casi, siti con contenuti dinamici, è opportuno valutare le tecniche di rendering ibrido, come il rendering statico incrementale (ISR) e il rendering statico distribuito (DSR), che possono offrire un buon equilibrio tra prestazioni e flessibilità. Queste tecniche combinano elementi di SSR e SSG, generando pagine statiche che possono essere facilmente indicizzate dai motori di ricerca, ma che possono anche essere rigenerate dinamicamente in risposta a specifici eventi o trigger.

Ancora, è fondamentale monitorare e testare regolarmente il sito per assicurarti che il rendering sia ottimizzato per la SEO: strumenti come Google Search Console possono aiutarti a identificare eventuali problemi di rendering e a ottenere suggerimenti su come risolverli.

Un ultimo consiglio generale, e sempre valido, è di minimizzare l’utilizzo di JavaScript che, sebbene sia potente e versatile, può anche rallentare il processo di rendering e indicizzazione di Google. Pertanto, dovresti ridurre al minimo la sua presenza, specialmente per i contenuti e le funzionalità cruciali del sito e, se possibile, cercare di fornire una versione HTML statica dei contenuti, che può essere facilmente indicizzata da Google.

Come funzionano i motori di rendering

Tornando agli aspetti generali, sono essenzialmente tre le fasi in cui si compone il lavoro di un rendering engine:

Decodifica degli input – le informazioni in ingresso.
Elaborazione dei dati.
Rappresentazione grafica delle informazioni.

Provando a semplificare, il motore di rendering web preleva il codice sorgente delle pagine web richieste dall’utente e ne scansiona tutti gli elementi HTML e CSS presenti; queste informazioni sono quindi decodificate per iniziare a costruire la pagina web da visualizzare.

In questo processo sono identificate le varie parti di cui si compone la pagina, come il blocco di testo e la sua formattazione, lo sfondo, il colore, il contenuto, i vari elementi multimediali e così via. Usando le informazioni riportate nel codice sorgente della risorsa e nel file CSS, il motore rielabora e mette in ordine gli elementi e successivamente, insieme alla GPU, trasforma il codice sorgente negli elementi effettivamente visualizzati nella scheda del browser, permettendo finalmente all’utente di accedere e consultare in modo corretto la risorsa desiderata.

Le differenze tra rendering e indexing

La differenza tra rendering e indexing si può rappresentare molto facilmente con un confronto tra due immagini, spiega Davies: in alto abbiamo le righe di codice HTML di una pagina del nostro blog, mentre in basso c’è la rappresentazione grafica della stessa pagina così come visualizzata nel browser.

In sostanza, si tratta dello stesso contenuto, dapprima mostrato per come appare durante l’indicizzazione (HTML) e poi per come viene reso nel rendering (Chrome).

È Jamie Indigo ad approfondire meglio questi concetti, spiegando che il rendering è il processo in cui Googlebot recupera le pagine del nostro sito, esegue il codice e valuta i contenuti per comprendere il layout o la struttura del sito. Tutte le informazioni raccolte da Google durante il processo di rendering vengono quindi utilizzate per classificare la qualità e il valore dei contenuti del sito rispetto ad altri siti e a ciò che le persone cercano con Ricerca Google.

Ogni pagina web ha essenzialmente due stati, e un sito web essere molto diverso tra i due stati:

HTML iniziale, che si verifica per primo. È la risposta del server: contiene HTML e collegamenti a risorse come JavaScript, CSS e immagini necessarie per creare la pagina. Per vedere l’HTML iniziale, basta visualizzare il codice sorgente della pagina.
HTML renderizzato, più ampiamente conosciuto come DOM (abbreviazione di Document Object Model). Ogni pagina web ha un DOM: rappresenta l’HTML iniziale più eventuali modifiche apportate da JavaScript richiamato dall’HTML. Per visualizzare il DOM, dobbiamo aprire gli strumenti per sviluppatori del browser nel nostro browser e fare clic sulla scheda della console.

Perché è importante il rendering

Si potrebbe pensare che il rendering sia importante solo per chi ha siti JavaScript, ma in realtà questo processo riguarda e interessa tutti i siti, come conferma il fatto che i motori di ricerca eseguissero il rendering delle pagine anche prima della recente impulso all’uso di JavaScript per i siti Web.

Essenzialmente, il motivo per cui questo processo conta è che il rendering fornisce la verità.

Attraverso il codice, un motore di ricerca può capire di cosa tratta una pagina e approssimativamente quello che contiene. Con il rendering, possono comprendere l’user experience e avere molte più informazioni su quali contenuti dovrebbero avere la priorità.

Durante la fase di resa grafica il motore di ricerca può dare risposta a tante domande rilevanti per comprendere correttamente una pagina e come dovrebbe essere classificata. Ad esempio, nell’articolo si citano questioni come:

Il contenuto è nascosto dietro un clic?
Un annuncio riempie la pagina?
Il contenuto visualizzato nella parte inferiore del codice viene effettivamente visualizzato nella parte superiore o nella navigazione?
Il caricamento di una pagina è lento?

Quando avviene il rendering

Stando alle informazioni in nostro possesso – e sempre in linea di massima – il rendering si verifica dopo l’indicizzazione e può addirittura richiedere alcuni giorni o settimane, con una sequenza temporale variabile. Ciò significa essenzialmente che i motori di ricerca comprenderanno il contenuto e il contesto di una pagina prima di ottenere una piena comprensione di come ciò deve essere reso prioritario.

Questo ovviamente non significa che i motori di ricerca siano completamente ignoranti fino al rendering, perché ci sono alcune regole e impressioni solide che hanno acquisito nel corso degli anni che consentono loro di fare rapidamente ipotesi su:

Quali elementi sono presenti.
Dove sono posizionati.
Quanto sono importanti per l’utente.

Ma è solo dopo la resa grafica delle pagine che i motori sapranno che i loro presupposti sono corretti e potranno comprendere a pieno una pagina e la sua forma.

I problemi con il rendering

In sintesi, i motori di ricerca inviano un crawler al sito, che rappresenterà la pagina come farebbe un browser.

Se in Bing “sembrano essere un po’ più bravi nel rendering, il che è interessante”, in casa Google Googlebot ha un componente Web Rendering Service (WRS), aggiornato a maggio del 2019, in occasione dell’aggiornamento evergreen del crawler, che ora usa la versione più recente di Chrome anche per il rendering.

Fino ad allora, il WRS utilizzava la versione 41 di Chrome, che era eccezionale per la compatibilità ma “era un incubo per i siti che si basavano su funzionalità moderne, come quelle del moderno JavaScript”, scrive Davies.

In sostanza, ciò significa che “quando la tua pagina è renderizzata da Googlebot è resa più o meno come la vedresti nel tuo browser”. Tuttavia, è sbagliato pensare che sia sufficiente verificare su un browser se la pagina funziona correttamente, perché il senso del rendering è altro.

Se abbiamo un “sito basic con HTML prevedibile e contenuti dinamici quasi nulli, non c’è davvero nulla di cui preoccuparti” e probabilmente non c’erano preoccupazioni neppure con la vecchia configurazione del WRS.

Ma per i siti “con contenuti dinamici offerti tramite JavaScript, c’è un grande avvertimento ed è radicato in un gap”: fino a quando la pagina non viene visualizzata, il motore non sa cosa ci sia sopra. A differenza di un sito con un semplice output HTML – in cui il motore potrebbe perdere un po’ del contesto ma comprende il contenuto – con un sito basato su qualcosa come JavaScript che si basa sul rendering “il motore non saprà quale contenuto è nella pagina fino a quando il WRS non ha completato il suo lavoro”.

E quindi, le “settimane” di lavoro necessarie per raggiungere questo risultato sono piuttosto d’impatto, ed è anche per questo motivo che i motori stanno lavorando per ridurre la latenza. Fino a quel momento, però, gli sviluppatori JavaScript dovranno fare affidamento sul pre-rendering (creazione di una versione statica di ogni pagina per i motori), che non è affatto la soluzione ideale.

Come funziona il Web Rendering Service

Il ciclo di vita del rendering segue questo percorso:

Una pagina viene scoperta tramite sitemap, crawler, ecc.
La pagina viene aggiunta all’elenco delle pagine del sito da sottoporre a scansione quando è disponibile il crawl budget.
Il contenuto della pagina viene sottoposto a scansione e indicizzato.
La pagina viene aggiunta all’elenco delle pagine da renderizzare su un sito quando è disponibile il rendering budget.
La pagina è renderizzata.

L’elemento critico e non detto del processo è la coda di rendering: “Googlebot potrebbe arrivare a una pagina settimane prima del rendering e fino ad allora alcuni contenuti (siti JavaScript) o contesto (tutti i siti) potrebbero mancare”, spiega l’articolo. E quando una pagina raggiunge la cima della rendering queue, il motore invierà ciò che viene definito headless browser, browser senza testa, ovvero un browser senza un’interfaccia utente grafica.

In qualche modo, comunque, il motore di ricerca riesce a capire cosa dove e come appare su una pagina, anche se non ha occhi per vederlo: quando il processo si completa in modo positivo, “la versione renderizzata apparirà uguale a Googlebot e nei browser grafici”, mentre “in caso contrario è probabile che la pagina si basi su una funzione non supportata come una richiesta di autorizzazione dell’utente”.

Il rendering è ancora problematico

Secondo Davies, al momento “possiamo contare sulle capacità di indicizzazione dei motori, ma il lato rendering ha ancora molta strada da fare” per colmare il divario tra ciò che i motori di ricerca vedono e ciò che fa il browser di un utente.

In base all’esperienza dell’autore, c’è la possibilità che nel breve-medio periodo si riduca “drasticamente la latenza tra indicizzazione e rendering, specialmente sui siti che si basano su questo processo”, e ciò potrebbe portare all’apertura di un mondo per i siti che necessitano di resa grafica per essere compresi.

Il rendering di Google: come funziona e che valore ha

Per fare rendering delle pagine web, Google utilizza un processo a due fasi o wave, progettato per aiutare il motore di ricerca a comprendere meglio il contenuto di una pagina web e a indicizzarla in modo efficace.

La prima fase del processo di rendering di Google è l’analisi dell’HTML grezzo di una pagina: durante questa fase, Google esamina l’HTML di una pagina per identificare i contenuti di base e le informazioni strutturali, attraverso una sorta di “lettura rapida” che permette al motore di ricerca di ottenere una visione generale del contenuto della pagina.

La seconda fase del processo di rendering di Google è l’esecuzione e l’analisi del codice JavaScript: in questo processo, che a causa della complessità e delle risorse necessarie per eseguire il JavaScript può avvenire giorni o addirittura settimane dopo il precedente, Google esegue qualsiasi codice JavaScript presente nella pagina per generare e visualizzare i contenuti dinamici.

Il rendering è fondamentale per la SEO perché determina come e quando i contenuti del sito vengono visualizzati e indicizzati da Google: se il sito fa un uso intensivo di JavaScript, è possibile che alcuni contenuti non vengano indicizzati immediatamente durante la prima onda di indicizzazione di Google, a causa di questo lag, e quindi ci potrebbe essere una temporanea visibilità ridotta delle pagine nei risultati di ricerca.

Ancora peggio, ovviamente, se i contenuti non vengono correttamente renderizzati, perché in questo caso Google potrebbe non essere in grado di “vedere” e quindi indicizzare questi contenuti, con conseguente riduzione della visibilità del sito nei risultati di ricerca. Inoltre, un rendering inefficiente può portare a tempi di caricamento più lunghi, che possono influire negativamente sull’esperienza dell’utente e, ancora una volta, sul posizionamento del sito nei risultati di ricerca.

Il Rendering secondo Google: l’analogia con le ricette

Per comprendere meglio come Google gestisce il rendering, possiamo pensare a ciò che avviene quando prepariamo una ricetta, riprendendo un’analogia ideata dal citato Martin Splitt.

La prima onda di indicizzazione di Google è come leggere la lista degli ingredienti di una ricetta: dà a Google una visione generale di ciò che la pagina contiene. Tuttavia, come quando si legge una lista di ingredienti, non ottiene l’immagine completa del piatto finito.

Ecco dove entra in gioco la seconda onda di indicizzazione di Google, che è come seguire i passaggi della ricetta per effettivamente preparare il piatto. Durante questa seconda onda, Google esegue JavaScript per “preparare” la pagina e visualizzare i contenuti basati su JavaScript. Tuttavia, proprio come la preparazione di una ricetta può richiedere tempo, anche la seconda onda di indicizzazione di Google può richiedere tempo, a volte giorni o settimane.

Nell’ottica della SEO, il rendering è fondamentale perché determina come e quando i contenuti del sito vengono “serviti” a Google e, di conseguenza, come e quando appaiono nei risultati di ricerca. Se parti del “piatto” (ovvero il sito web) sono basate su JavaScript e quindi richiedono la seconda onda di indicizzazione di Google per essere “preparate”, potrebbero non essere immediatamente visibili nei risultati di ricerca.

Per assicurarti che il “piatto” sia pronto per essere servito non appena Google legge la “lista di ingredienti”, possiamo utilizzare tecniche come il rendering lato server (SSR) o il prerendering, che preparano in anticipo la pagina, generando una versione statica che può essere facilmente “degustata” da Google durante la sua prima onda di indicizzazione.

Inoltre, proprio come un cuoco farebbe dei test di assaggio durante la preparazione di un piatto, dovremmo testare regolarmente il sito con strumenti come Google Search Console per assicurarti che Google sia in grado di “assaggiare” e indicizzare correttamente i contenuti.

In definitiva, comprendere come Google “prepara” il sito e come ottimizzare il piatto per questo processo può fare la differenza tra un sito che viene facilmente “degustato” e indicizzato da Google, e uno che rimane nascosto nel “frigorifero”.