Introduzione: Google e Javascript
Fino a pochi anni fa uno dei problemi più diffusi nell’ottimizzazione Seo era quello di riuscire a fare indicizzare pagine con contenuti creati dinamicamente tramite Javascript. Il problema era relativo ai Bot dei Motori di Ricerca che non erano in grado di scansionare e indicizzare queste risorse e consideravano solo il contenuto presente nel codice sorgente dell’HTML statico.
Contestualmente a questa problematica c’è stata un evoluzione di framework come AngularJS, React, Vue.JS, applicazioni a pagina singola (SPA) e progressive web app (PWA) che ha portato Google ad evolversi in modo significativo e a raggiungere una maturazione completa nel comprendere le pagine web come un browser moderno.
Tuttavia, nonostante oggi Google è generalmente in grado di scansionare e indicizzare la maggior parte dei contenuti JavaScript, viene raccomandato il rendering lato server, il pre-rendering o il rendering dinamico piuttosto che affidarsi al JavaScript lato client in quanto per i crawler risulta ancora difficile elaborare JavaScript con successo o immediatamente.
Per questi motivi in fase di analisi è fondamentale comprendere le differenze tra il DOM dopo che JavaScript è entrato in gioco e ha costruito la pagina web e la risposta statica dell’HTML.
Javascript, il seo spider e alcune controindicazioni
Per ovviare a questa esigenza ti viene in aiuto Screaming Frog con la modalità “Javascript Rendering” che ha integrato la libreria “Chromium” per riuscire ad emulare al meglio il comportamento dello Spider di Google.
Approfondimento: Google ha aggiornato nel 2019 il Web Rendering Service (WRS) che era precedentemente basato su Chrome 41 con l’ultima versione stabile di Chrome e questo ha permesso di supportare oltre mille funzioni supplementari.
1. Consideriamo alcuni aspetti inerenti a siti in Javascript:
- 1. Abilita il “Javascript Rendering” con attenzione
Sebbene comprendere quali siano le differenze fra il DOM e l’html statico dopo l’esecuzione del Javascript è molto importante ti sconsiglio di abilitare la modalità “Javascript Rendering” indistintamente per ogni sito web.
Il crawling con JavaScript è più lento e più intenso per il server, poiché tutte le risorse (sia JavaScript, CSS, immagini ecc.) devono essere recuperate per il rendering di ogni pagina web. Questa criticità è ininfluente per i siti di piccole dimensioni ma per i grossi portali o ecommerce potrebbe diventare un ostacolo per la tua scansione in termini di tempo e Ram.
- 2. Considera i principi e limitazioni della scansione Javascript
Tutte le risorse di una pagina (JS, CSS, immagini) devono essere disponibili per essere scansionate, renderizzate e indicizzate.
Google richiede ancora URL puliti e unici per una pagina, e i link devono essere in tag di ancoraggio HTML appropriati (è possibile offrire un link statico, così come chiamare una funzione JavaScript).
Lo Spider di Google non interagisce come gli utenti, ad esempio non clicca sulle risorse caricando eventi aggiuntivi dopo il rendering (un clic, un hover o uno scroll per esempio).
L’istantanea della pagina renderizzata viene presa quando si determina che l’attività di rete si è fermata, o oltre una soglia di tempo. C’è il rischio che se una pagina impiega molto tempo per il rendering possa essere saltata e gli elementi non vengano visti e indicizzati.
In generale Google fa il rendering di tutte le pagine, tuttavia non mette in coda le pagine per il rendering se hanno un ‘noindex’ nella risposta HTTP iniziale o HTML statico.
Infine, il rendering di Google è separato dall’indicizzazione. Google inizialmente scansiona l’HTML statico di un sito web, e rimanda il rendering fino a quando non ha risorse.
Quando si inizia lo sviluppo di un sito web conoscere queste condizioni è di vitale importanza per il successo o il fallimento del progetto in ottica di posizionamento organico.
Javascript lato Server e lato Client
Google sconsiglia di affidarsi a JavaScript lato client e raccomanda di sviluppare con il “progressive enhancement”, costruendo la struttura e la navigazione del sito usando solo HTML e poi migliorando l’aspetto e l’interfaccia del sito con AJAX.
Per questo motivo se utilizzi un framework JavaScript, Google raccomanda di predisporre il rendering lato server, il pre-rendering o il rendering ibrido che può migliorare le prestazioni per gli utenti e i crawler dei Motori di Ricerca.
Servendo il rendering lato server (SSR) e il pre-rendering l’esecuzione del JavaScript delle pagine fornisce una versione HTML iniziale renderizzata e pronta alla scansione.
Il rendering ibrido (a volte indicato come “isomorphic”) identifica una versione del rendering che esegue Javascript lato server per il caricamento iniziale della pagina e l’HTML e lato client per gli elementi non critici e le pagine successive.
Molti framework JavaScript come React o Angular Universal permettono il rendering lato server e ibrido.
In alternativa, puoi optare per l’utilizzo del rendering dinamico.
Questo può essere particolarmente utile quando non è possibile apportare modifiche alla codebase del front-end. Il rendering dinamico passa dal rendering lato client per gli utenti al contenuto pre-renderizzato per i Motori di Ricerca.
I Tempi di Crawling di Google
Nonostante optare per le tre soluzioni elencate sopra risolva la gran parte dei problemi di crawling è buona norma considerare un ulteriore aspetto.
Google ha un processo di indicizzazione in due fasi, in cui inizialmente scansiona e indicizza l’HTML statico, e poi ritorna più tardi quando le risorse sono disponibili per il rendering della pagina e per scansionare e indicizzare il contenuto e i link nell’HTML renderizzato.
Il tempo richiesto tra il crawling e il rendering potrebbe essere anche molto lungo (fino a 7 giorni) e questa condizione rappresenta un problema per siti che si basano su contenuti che per loro natura presentano caratteristiche di tempestività o semplicemente scadono (es. sito notizie, eventi etc.); mentre il tempo medio (dichiarato al Chrome Dev Summit del 2019) è di 5 secondi.
Come identificare JavaScript
Identificare un sito costruito usando un framework JavaScript può essere abbastanza semplice, tuttavia, diagnosticare sezioni, pagine o solo elementi più piccoli che sono adattati dinamicamente usando JavaScript può essere molto più impegnativo. Quando ti appresti a definire un Seo Audit è buona norma definire immediatamente se ci sia la presenza di Javascript e cercare di compendere se il sito possa o meno presentare problemi durante i diversi crawl degli User Agent.
Ci sono diversi modi per sapere se il sito è costruito utilizzando un framework JavaScript, vediamone alcuni:
- 1. Identificare Javascript con Screaming Frog
Per impostazione predefinita, il Seo Spider esegue la scansione utilizzando il “vecchio schema di scansione AJAX”, il che significa che JavaScript è disabilitato, e scansiona solo l’HTML Raw.
Se il sito utilizza solo JavaScript lato client allora otterrai come risultato della tua scansione solamente la Homepage con una risposta 200 con pochi file “Javascript e CSS”.
Come puoi vedere anche la Tab “Outlinks” non presenta collegamenti ipertestuali dato che non vengono resi nell’html raw e non possono essere visti dal Seo Spider.
Mentre questo è spesso un segno che il sito web sta usando un framework JavaScript, con rendering lato client – non ti dice se esistono anche altre dipendenze JavaScript nel sito.
Per esempio, un sito web potrebbe avere solo JavaScript per caricare i prodotti nelle pagine delle categorie, o aggiornare gli elementi del titolo.
Come si fa allora a trovarli con facilità?
Per identificare il JavaScript in modo più efficiente, è necessario passare alla modalità di rendering JavaScript (“Config > Spider > Rendering”) e scansionare il sito, o un campione di modelli da tutto il sito.
Il SEO Spider scansionerà sia l’HTML originale che quello renderizzato per identificare le pagine che hanno contenuti o link disponibili solo lato client e segnalare altre dipendenze chiave.
Per orientarti sui problemi comuni dei siti con Javascript lato client hai a disposizione una lista completa di filtri che ti guideranno nella definizione del tuo Seo Audit.
Il Seo Spider ti segnalerà se ci sono contenuti che si trovano solo nell’HTML renderizzato dopo l’entrata in gioco del JavaScript permettendoti una visione completa del comportamento del sito web.
In questo esempio, il 100% del contenuto è solo nell’HTML renderizzato poiché il sito si basa interamente su JavaScript.
In questo caso l’esame ha posto l’attenzione sul numero di parole rinvenute nel contenuto delle pagine ma puoi anche trovare ad esempio, i riferimenti delle pagine con link presenti solamente nell’HTML renderizzato e porvi rimedio seguendo le indicazioni di Google.
Questa funzionalità di Screaming Frog è molto utile anche per controllare se i meta tag o altri elementi Seo siano o meno presenti nell’html statico o vengano serviti e/o modificati solo una volta che il Javascript è stato eseguito.
- 2. Disabilitare Javascript nel browser
Un’alternativa per comprendere la natura dei sito web è quella di disabilitare Javascript direttamente nel browser e ricaricare la pagina. Se si presenterà bianca non ci sono dubbi che il sito web è stato progettato con Javascript.
- 3. Ricercare Javascript direttamente nel codice sorgente
La terza soluzione è quella di cliccare con il tasto destro del mouse sul sito web e visualizzare il codice sorgente esaminando il contenuto Html, se ci sia del testo, ci siano dei link o dei segni delle librerie dei vari framework JS.
Seguendo questo processo stai vedendo il codice prima che venga elaborato dal browser che corrisponderà a quello che il Seo Spider scansiona, quando non è in modalità di rendering JavaScript.
Se provi ad eseguire una ricerca di qualche elemento ma non ottieni alcuna occorrenza all’interno del codice sorgente, allora presumibilmente vengono generati dinamicamente nel DOM e saranno visualizzabili solo nel codice renderizzato.
In questo caso il tag <body> è completamente vuoto, chiaro segnale che il sito presenta JS.
- 4. Fare un Audit del codice renderizzato
La prima domanda da farti dovrebbe essere: quanto è diverso il codice renderizzato dal sorgente HTML statico? Per scoprirlo ti basta cliccare con il tasto destro del mouse e usare “inspect element” in Chrome per vedere l’HTML renderizzato. Puoi spesso vedere il nome del Framework JS nel codice renderizzato, come ‘React’ nell’esempio qui sotto.
Troverai che il contenuto e i collegamenti ipertestuali sono nel codice renderizzato, ma non nel codice sorgente HTML originale. Questo è ciò che il Seo Spider vedrà, quando è in modalità di rendering JavaScript.
Cliccando sull’elemento HTML di apertura, poi “copy > outerHTML” puoi confrontare il codice sorgente renderizzato con quello originale.
Audit con Screaming Frog di siti Javascript
Definita la presenza di JS e comprese le insidie puoi iniziare il tuo Seo Audit con Screaming Frog configurandolo in modalità di rendering JavaScript. Questo ti permette di scansionare siti web dinamici e ricchi di JavaScript e framework, come Angular, React e Vue.js.
- 1. Per scansionare un sito web JavaScript, apri il Seo Spider, clicca su ‘Configurazione > Spider > Rendering’ e cambia ‘Rendering’ in ‘JavaScript’.
- 2. Configura User-Agent & Window Size
Configura lo user-agent
Configurazione > HTTP Header > User-Agent
E la dimensione della finestra
Configurazione > Spider > Rendering
Per default il viewport è impostato su “Google Mobile: Smartphone” seguendo l’orientamento “Mobile Index First” del Motore di Ricerca.
- 3. Controlla le risorse e i link esterni
Assicurati che le risorse come immagini, CSS e JS siano spuntate nella “Configurazione > Spider”. Se le risorse sono su un sottodominio diverso, o su un “root domain” separato, allora abilita anche “controlla i link esterni”, altrimenti non saranno scansionate e quindi renderizzate.
- 4. Esegui la scansione
- 5. Consulta la scheda Javascript
Con la scheda JavaScript hai a disposizione 15 filtri che ti aiutano a considerare le dipendenze JavaScript e isolare i problemi più comuni.
- Pages with Blocked Resources: identifica tutte le pagine con risorse (come immagini, JavaScript e CSS) che vengono bloccate da robots.txt. Questa condizione può essere un problema perché i Motori di Ricerca potrebbero non essere in grado di accedere alle risorse critiche per poter fare il Rendering delle pagine in modo accurato. Ti consiglio di aggiornare il file robots.txt per permettere a tutte le risorse critiche di essere scansionate e utilizzate per il rendering del contenuto del sito. Le risorse che non sono critiche (ad esempio l’embed di Google Maps) possono essere ignorate.
- Contains JavaScript Links : il filtro visualizza le pagine che contengono collegamenti ipertestuali che vengono scoperti nel HTML renderizzato solo dopo l’esecuzione di JavaScript. Questi collegamenti ipertestuali non sono nell’HTML grezzo. E’ buona norma considerare l’inclusione di link importanti lato server nell’HTML statico.
- Contains JavaScript Content: mostra tutte le pagine che contengono il testo del corpo solo nell’HTML renderizzato dopo l’esecuzione di JavaScript. Google è in grado di renderizzare le pagine e vedere solo il contenuto lato client, considera di includere il contenuto importante lato server nell’HTML grezzo.
- Noindex Only in Original HTML: tutte le pagine che contengono un tag noindex nell’HTML statico ma non nell’HTML renderizzato. Quando Googlebot incontra un tag noindex, salta il rendering e l’esecuzione di JavaScript. Poiché Googlebot salta l’esecuzione di JavaScript, usare JavaScript per rimuovere il ‘noindex’ nell’HTML renderizzato non funzionerà.
- Nofollow Only in Original HTML: identifica le pagine che contengono un attributo nofollow nell’HTML statico, e non nell’HTML renderizzato. Questo significa che qualsiasi collegamento ipertestuale nell’HTML grezzo prima dell’esecuzione di JavaScript non sarà seguito. Rimuovi il ‘nofollow’ se i link dovrebbero essere seguiti, scansionati e indicizzati.
- Canonical Only in Rendered HTML: restituisce tutte le pagine che contengono un tag canonical solo nell’HTML renderizzato dopo l’esecuzione di JavaScript. Ti consiglio di includere un link canonico nell’HTML statico (o nell’intestazione HTTP) per assicurarti che Google possa vederlo ed evitare di fare affidamento solo sul canonico nell’HTML renderizzato.
- Canonical Mismatch:identifica le pagine che contengono un link canonico diverso nell’HTML statico rispetto all’HTML renderizzato dopo l’esecuzione di JavaScript. Questa condizione può causare segnali contrastanti e può portare a comportamenti indesiderati da parte del Motore di Ricerca.
- Page Title Only in Rendered HTML: restituisce le pagine che contengono un titolo di pagina solo nell’HTML renderizzato dopo l’esecuzione di JavaScript. Questo significa che un Motore di Ricerca deve renderizzare la pagina per vederli. Considera di includere il contenuto importante lato server nell’HTML grezzo.
- Page Title Updated by JavaScript: identifica le pagine che hanno titoli di pagina modificati da JavaScript. Questo significa che il titolo della pagina nell’HTML statico è diverso dal titolo della pagina nell’HTML renderizzato. Considera di includere il contenuto importante lato server nell’HTML statico.
- Meta Description Only in Rendered HTML: restituisce le pagine che contengono una meta descrizione solo nell’HTML renderizzato dopo l’esecuzione di JavaScript.
- Meta Description Updated by JavaScript: tutte le pagine che hanno meta description che sono modificate da JavaScript. Questo significa che la meta descrizione nell’HTML statico è diversa dalla meta descrizione nell’HTML renderizzato.
- H1 Only in Rendered HTML : le pagine che contengono un h1 solo nell’HTML renderizzato dopo l’esecuzione di JavaScript. Questo significa che un Motore di Ricerca deve renderizzare la pagina per considerare l’heading. Considera di includere gli heading lato server nell’HTML statico.
- H1 Updated by JavaScript: le pagine che hanno h1 modificati da JavaScript. Questo significa che l’h1 nell’HTML grezzo è diverso dall’h1 nell’HTML renderizzato.
- Uses Old AJAX Crawling Scheme URLs: identifica gli URL che stanno ancora utilizzando il vecchio schema di crawling AJAX (un URL contenente un frammento di hash #!) che è stato ufficialmente deprecato a partire da ottobre 2015. Considera il rendering lato server o il pre-rendering dove possibile, e il rendering dinamico come soluzione alternativa.
- Uses Old AJAX Crawling Scheme Meta Fragment Tag: comprende gli URL che includono un meta fragment tag che indica che la pagina sta ancora utilizzando il vecchio schema di crawling AJAX che è stato ufficialmente deprecato a partire da ottobre 2015. Il consiglio è quello di aggiornare gli URL per seguire l’evoluzione del JavaScript sui siti web attuali. Considera il rendering lato server o il pre-rendering dove possibile, e il rendering dinamico come soluzione di workaround. Se il sito ha ancora il vecchio tag meta fragment per errore, allora questo dovrebbe essere rimosso.
- 6. Monitora le risorse bloccate
Tieni d’occhio tutto ciò che appare sotto il filtro “Pages with blocked resources” nella scheda “Javascript”
Le risorse bloccate possono anche essere visualizzate per ogni pagina all’interno della scheda ‘Rendered Page’, adiacente alla schermata renderizzata nel pannello inferiore della finestra. In casi gravi, se un sito JavaScript blocca completamente le risorse JS, allora il sito semplicemente non verrà scansionato.
Ogni risorsa bloccata la puoi vedere anche nella scheda “Response Code”.
Response Codes > Blocked Resource
Le pagine e le singole risorse bloccate possono anche essere esportate in blocco con il rapporto “Bulk Export > Response Code > Blocked Resource Inlinks per essere sbloccate ed ottimizzate.
- 7. Visualizza le pagine renderizzate
Con Screaming Frog è possibile visualizzare la pagina renderizzata scansionata nella scheda ‘Rendered Page’ che appare dinamicamente nella parte inferiore dell’interfaccia utente quando il crawling avviene in modalità di rendering JavaScript.
Nel caso il Rendering delle pagine non si carichi considera di intervenire sul tempo di timeout dell’AJAX direttamente nella configurazione del Seo Spider.
La visualizzazione della pagina renderizzata è vitale quando si analizza ciò che un moderno bot di ricerca è in grado di vedere ed è particolarmente utile quando si esegue una revisione in staging, dove non è possibile utilizzare la funzionalità “Fetch & Render” nativo di Google attraverso la Search Console.
Se hai regolato l’user-agent e la viewport su Googlebot Smartphone, puoi vedere esattamente come ogni pagina viene resa su mobile, per esempio.
- 8. Confronta l’HTML grezzo e renderizzato
Potresti voler memorizzare e visualizzare l’HTML e l’HTML renderizzato all’interno del Seo Spider quando lavori con JavaScript.
Configuration > Spider > Extraction > Store Html/Render Html
Spuntando le opzioni appropriate “Store HTML” e “Store HTML Rendered” puoi avere un facile confronto tra le due versioni ed essere in grado di comparare le differenze per essere sicuro che il contenuto critico o i link siano presenti nel DOM.
Questo è super utile per una varietà di scenari, come il debugging delle differenze tra ciò che viene visto in un browser e nel SEO Spider, o semplicemente quando si analizza come il JavaScript è stato reso, e se certi elementi sono all’interno del codice.
Se il filtro “Contenuto JavaScript” si è attivato per una pagina, è possibile passare dal filtro ‘HTML’ a ‘Contenuto visibile’ per identificare esattamente quale contenuto testuale è solo nell’HTML renderizzato.
- 9. Identificare i link solo JavaScript
Un altro controllo importante riguarda il link presenti solo nel testo renderizzato. Attraverso il filtro “Contiene link JavaScript” puoi identificare quali collegamenti ipertestuali sono scoperti dopo l’esecuzione di JavaScript.
Collezionato i dati è sufficiente cliccare su un URL nella finestra superiore, poi sulla scheda inferiore “Outlinks” e selezionare come filtro “Rendered HTML”.
- 10. Configurare il AJAX Timeout
In base alle risposte del tuo crawl, puoi scegliere l’impostazione del Timeout che di default è impostato a 5 secondi. Molto utile questa funzione nel caso di problemi nel Rendering delle pagine con il Seo Spider.
Configurazione > Spider > Rendering
Il timeout di 5 secondi va generalmente bene per la maggior parte dei siti web, e normalmente Googlebot è più flessibile in quanto si adatta in base a quanto tempo una pagina impiega a caricare il contenuto, considerando l’attività di rete ed eseguendo un sacco di caching.
