JavaScript SEO: il difficile e controverso rapporto fra Google e JavaScript

Sempre più spesso si sente parlare di JavaScript e dei progressi compiuti da Google nell’interpretare questo linguaggio, ormai ampiamente utilizzato dagli sviluppatori per creare siti web più interattivi, dinamici e appetibili dal punto di vista della user experience.

Questa tecnologia presenta però alcuni svantaggi, o meglio, aggiunge un ulteriore strato di complessità quando si tratta di garantire una corretta scansione, indicizzazione e posizionamento sui motori di ricerca.

Per comprendere il difficile rapporto tra Google e JavaScript, è necessario prima di tutto distinguere tra due possibili scenari: da una parte, i siti in cui JavaScript viene utilizzato “solo” per aggiungere funzionalità più o meno critiche, e dall’altra i siti interamente basati su JavaScript, come le Single Page Application realizzate in React, Angular, Vue.js o altri framework.

Nel primo caso, è sufficiente circoscrivere gli ambiti in cui Googlebot presenta ancora delle limitazioni e adottare gli opportuni accorgimenti. Nel secondo, gli interventi necessari possono essere molto più impattanti, in quanto va ripensato il modo in cui avviene il processo di indicizzazione dei contenuti.

Capacità e limiti di Googlebot nell’interpretazione di JavaScript

Di seguito i principali aspetti da considerare quando ci si trova di fronte a un sito con una parziale dipendenza da JavaScript:

• Redirect in JavaScript: all’interno delle linee guida ufficiali, Google fa intendere di essere in grado di seguire i redirect in JavaScript. Ciò nonostante, il redirect 301 lato server resta l’opzione migliore quando si tratta di redirezionare una pagina o un sito verso un nuovo indirizzo.
• Link in JavaScript: durante il Google I/O ’18 alcuni esponenti di Google hanno affermato che il motore sarebbe in grado di seguire solo i link che contengono l’URL all’interno dell’attributo HREF. Tuttavia, alcuni esperimenti condotti da Search Engine Land dimostrano che in realtà possono essere seguiti anche i link in JavaScript privi dell’URL all’interno dell’attributo HREF.
• Contenuti generati in seguito ad interazioni: dato che Google non interagisce con la pagina, i contenuti generati tramite JavaScript in seguito a un’azione dell’utente non possono essere visualizzati. Un esempio tipico è l‘infinite scroll: uno scroll infinito SEO friendly deve necessariamente prevedere la presenza di una paginazione con link in HTML.
• Lazy loading: il lazy loading è una tecnica di caricamento differito dei contenuti, in particolare immagini, utilizzata per migliorare la velocità di un sito. Non sempre però le immagini caricate tramite lazy loading sono indicizzabili dai motori di ricerca; per assicurarsi che Google indicizzi i contenuti caricati in modo differito è possibile:
• Aggiungere <noscript> tag a ogni immagine
• Usare i dati strutturati (schema.org/image)
• Utilizzare l’API Intersection Observer

• Contenuti inseriti dinamicamente nel DOM: secondo vari esperimenti, Google sarebbe in grado di visualizzare e indicizzare i contenuti aggiunti dinamicamente tramite JavaScript, quali testo, immagini, meta tag ed altri elementi. Tuttavia, è altamente consigliato (da Google stesso) l’inserimento di contenuti critici direttamente nell’HTML iniziale, in particolar modo:
• Rel=“canonical”
• Status code
• Meta robots
• Tag Title
• Contenuto testuale (main content)
• Dati strutturati

Gli ultimi sviluppi: Googlebot e Bing sono oggi evergreen

Recentemente, sia Google che Bing hanno annunciato l’aggiornamento del browser utilizzato per il rendering. Nel caso di Google, a maggio 2019 si è addirittura passati da Chrome 41 (2015) a Chrome 74 (2019). Esponenti di entrambi i motori di ricerca hanno inoltre affermato che, da ora in poi, i rendering engine saranno oggetto di update regolari per essere costantemente allineati all’ultima versione di Chrome.

Ciò significa che i SEO non dovranno più preoccuparsi di JavaScript?

Non proprio. Prima di dare per scontate le capacità di rendering dei motori, è bene effettuare gli opportuni controlli e verificare, caso per caso, se esistono delle limitazioni. Ma soprattutto, occorre tenere a mente un concetto fondamentale legato al funzionamento dei bot: il crawl budget o, più precisamente, il render budget, ossia l’insieme delle risorse allocate da Googlebot per la scansione di un determinato sito web.

In altre parole, se è vero che oggi Google può scansionare e interpretare correttamente i siti realizzati in JavaScript, non è detto che abbia a disposizione le risorse necessarie per farlo, quantomeno nelle tempistiche desiderate dal webmaster.

Per capire meglio questa affermazione, è utile fare un passo indietro e chiarire come avviene il processo di indicizzazione dei siti interamente basati su JavaScript.

Come Googlebot indicizza i siti interamente basati su JavaScript

Nel caso di applicazioni realizzate interamente in JavaScript il processo di indicizzazione – che per i siti web tradizionali è tendenzialmente immediato – avviene in due fasi, le cosiddette due ondate di indicizzazione.

Nella prima ondata, tutti i contenuti non generati tramite JavaScript, e quindi già presenti nel codice sorgente della pagina, vengono serviti direttamente al motore e subito inseriti nell’indice.

Nella seconda ondata, invece, avviene il rendering dei contenuti generati con JavaScript. Con il termine rendering non si intende la resa grafica della pagina, ma la produzione del codice HTML completo, che avviene popolando il template con i dati provenienti dalle API o dal database.

Tuttavia, dal momento che il rendering è piuttosto oneroso in termini di tempo e risorse, Googlebot potrebbe decidere di effettuarlo in differita. Anche se recentemente Google ha affermato che in un futuro prossimo rendering e indicizzazione avverranno simultaneamente, ad oggi esiste il rischio concreto che i contenuti generati con JavaScript vengano indicizzati in una seconda fase, con la conseguenza di dilatare il tempo necessario per il posizionamento di nuove pagine.

I diversi tipi di rendering

Per evitare che si verifichi questa problematica, è necessario fare in modo che l’onere di effettuare il rendering non ricada interamente sul client, in questo caso Googlebot. Per ottenere questo risultato è possibile implementare diverse soluzioni, tra cui:

• Server side rendering (o SSR): ogni volta che riceve una richiesta, il server esegue JavaScript e genera il codice HTML completo da fornire ai motori. Questa soluzione consente anche di migliorare alcune metriche relative alle performance, tra cui First Paint, First Contentful Paint e Time to Interactive, perché il client non è costretto a scaricare, analizzare ed eseguire JavaScript prima di poter mostrare all’utente i primi contenuti. Può peggiorare però il Time to First Byte, dato che il codice viene eseguito sul server a ogni richiesta.
• Server side rendering + hydration: anche questo approccio ibrido consente l’indicizzazione immediata dei contenuti, in quanto JavaScript viene eseguito lato server per produrre l’HTML completo. La differenza rispetto alla soluzione precedente è che questo stesso codice viene poi riutilizzato dal browser per preservare l’interattività dell’applicazione. Se implementato correttamente, il SSR + hydration ha effetti positivi su First Paint e First Contentful Paint, ma può avere impatti negativi sul Time to Interactive.
• Dynamic rendering: questo approccio consiste nel fornire ai bot – identificati tramite User-Agent – il contenuto pre-renderizzato, e agli utenti (browser) il contenuto “normale” da renderizzare lato client. Si tratta di un vero e proprio cambiamento nelle policy di Google, in quanto sostanzialmente viene effettuata un’azione di cloaking, una prassi precedentemente ritenuta passibile di penalizzazione. Fra le soluzioni open source consigliate per implementare il dynamic rendering troviamo Renderton e Puppeteer, mentre gli strumenti di terze parti più utilizzati sono Prerender.io, SEO4Ajax, SnapSearch e Brombone.

Nonostante il dynamic rendering sia senza dubbio l’alternativa più semplice, Google ha recentemente affermato che è da considerare solamente un workaround, ovvero una soluzione temporanea da utilizzare fino a che non si sarà aggiornata la propria web app in modo da supportare il rendering server side o ibrido.

JavaScript e SEO: quando è necessario intervenire?

Se le soluzioni per risolvere eventuali problematiche legate alla doppia ondata di indicizzazione esistono, è vero anche che determinati interventi sono costosi in termini monetari e/o di effort lato sviluppo. Ne vale sempre la pena?

La risposta è banale: dipende. Se nessun contenuto critico viene generato tramite JavaScript, si può legittimamente decidere di non intervenire.

In determinati casi, invece, l’implementazione di una delle soluzioni descritte in precedenza è fortemente consigliata. Per esempio:

• Se il sito è molto grande e/o si aggiorna frequentemente (es. portali editoriali o e-commerce)
• Se il sito ha una forte presenza sui social media
• Se il sito è presente su mercati internazionali in cui il motore di ricerca più diffuso non è Google

Best practice della SEO per JavaScript

Riassumiamo, in conclusione, le principali best practice da tenere a mente quando si è alle prese con l’ottimizzazione SEO di un sito realizzato in JavaScript:

• Link: non costruire link al di fuori del tag <a> e inserire sempre l’URL all’interno dell’attributo HREF
• Redirect: se non strettamente necessario, evitare i redirect in JavaScript
• Lazy loading: utilizzare il tag <noscript>, i dati strutturati o l’API Intersection Observer
• Contenuti serviti in JavaScript: non generare tramite JavaScript meta tag, meta robots, canonical e main content
• Contenuti generati in seguito ad interazioni: evitare il caricamento di contenuti fondamentali in seguito a interazioni con la pagina
• txt: assicurarsi che il robots.txt non stia bloccando risorse JS che concorrono al rendering
• Testing: verificare se e come Google renderizza le pagine attraverso il Test di Ottimizzazione Mobile, Search Console, Screaming Frog ed eventuali tool esterni
• Rendering: se Google non riesce a visualizzare i contenuti importanti durante la prima ondata di indicizzazione, valutare l’implementazione di una diversa strategia di rendering