JavaScript SEO: la guida definitiva per ottimizzare un sito JS

Fin dal 2014, Google ha dichiarato di essere piuttosto abile nel rendering di siti web JavaScript. Tuttavia, ha sempre consigliato prudenza a proposito di questo argomento. Diamo un’occhiata a questo estratto tratto dall’articolo del Webmaster Central Blog di Google, intitolato “Understanding Web Pages Better”:

“Sometimes things don’t go perfectly during rendering, which may negatively impact search results for your site. […] Sometimes the JavaScript may be too complex or arcane for us to execute, in which case we can’t render the page fully and accurately […] Some JavaScript removes content from the page rather than adding, which prevents us from indexing the content.”

“A volte le cose non vanno perfettamente durante il rendering, il che può avere un impatto negativo sui risultati di ricerca per il tuo sito. […] Il JavaScript può essere troppo complesso o arcano da eseguire, caso in cui non è possibile fare rendering su una pagina in maniera completa e accurata […] Alcuni JavaScript rimuovono contenuti dalla pagina piuttosto che aggiungerne, il che impedisce di indicizzare il contenuto.”

Ci sono tre fattori che entrano in gioco: 1) crawlability (Google dovrebbe essere in grado di scansionare il tuo sito web con una struttura adeguata); 2) renderability (Google non dovrebbe avere difficoltà nel renderizzare il tuo sito); e 3) crawl budget (in quanto tempo Google riesce a scansionare e a renderizzare il tuo sito web).

Nel discutere sulla capacità di Google di fare crawling e rendering con JavaScript, dobbiamo anche affrontare due concetti molto importanti: il rendering lato server (Server-Side Rendering, SSR) e il rendering lato client (Client-Side Rendering). È necessario che ogni esperto SEO che ha a che fare con il JavaScript abbia piena comprensione di questa distinzione.

Nell’approccio tradizionale (ovvero il Server-Side Rendering), un browser o Googlebot riceve un HTML che descrive in maniera completa una pagina web. Una copia del contenuto è già qui compresa e il tuo browser (o Googlebot) ha solamente bisogno di scaricare il CSS e “illustrarne” il contenuto sullo schermo. Solitamente i motori di ricerca non hanno alcun problema con questo tipo di contenuti.

Il sempre più popolare approccio Client-Side Rendering, invece, è leggermente differente e, talvolta, mette in difficoltà i motori di ricerca. Infatti, è abbastanza comune che durante il caricamento iniziale un browser o Googlebot riceva una pagina HTML vuota (con poco contenuto, se non nessuno). Poi, la magia: il JavaScript scarica asincronicamente una copia del contenuto dal server e aggiorna il tuo schermo (e cambia il DOM, Document Object Model).

Se hai un sito web renderizzato lato client, dovresti assicurarti che Google riesca a fare crawling e rendering correttamente.

HTML e JavaScript sono completamente differenti per ciò che riguarda la gestione degli errori. Un singolo errore nel tuo codice può rendere Google incapace di fare il rendering della tua pagina.

Per citare Mathias Schäfer, l’autore dell’e-book “Robust JavaScript”:

“The JavaScript parser is not that polite. It has a draconian, unforgiving error handling. If it encounters a character that is not expected in a certain place, it immediately aborts parsing the current script and throws a SyntaxError. So one misplaced character, one slip of the pen can ruin your script.”

“Il parser JavaScript non è così gentile. È dotato di un sistema di gestione dell’errore draconiano e intransigente. Se si ritrova in presenza di un carattere che non è previsto in una determinata posizione, l’analisi dello script viene immediatamente interrotta a causa di un errore di sintassi. Dunque, basta un carattere sbagliato, un solo passo falso, per rovinare tutto il tuo script.”

A volte lo sviluppatore compie errori

Potresti aver sentito parlare dell’esperimento jsseo.expert che Bartosz Góralewicz, CEO di Onely, ha condotto per verificare la capacità di Google nel gestire siti web costruiti usando alcuni dei framework JavaScript più comuni.

All’inizio, è risultato che Googlebot non era in grado di renderizzare Angular 2. Un risultato insolito, dal momento che Angular è stato creato dal team di Google; così Góralewicz ha cercato di spiegare questo fenomeno:

“And it turned out that there was an error in Angular 2’s QuickStart, a kind of tutorial for how to set up Angular 2-based projects, which was linked in the official documentation. All that research to discover that the Google Angular team had made a mistake. On April 26, 2017, that mistake was corrected.”

“Si è scoperta la presenza di un errore nel QuickStart di Angular 2, una sorta di tutorial per imparare a creare progetti basati su Angular 2, linkato all’interno della documentazione ufficiale. Tutta quella ricerca per scoprire che il team di Google Angular aveva commesso un errore. Il 26 aprile 2017 quell’errore è stato corretto.”

Infine, in seguito alla correzione degli errori, è stato possibile indicizzare un sito di prova costruito con Angular 2, insieme a tutto il suo contenuto. Questo esempio illustra perfettamente la situazione che si verifica quando un singolo errore impedisce al Googlebot di renderizzare una pagina. Bisogna sottolineare che l’errore non è stato commesso da sviluppatori alle prime armi. Tutt’altro: è stato fatto dagli stessi developer che hanno contribuito allo sviluppo di Angular, il secondo framework JavaScript in ordine di popolarità.

Gli esempi, ad ogni modo, non si limitano a questo. Vediamone un altro, particolarmente indicativo. Nel dicembre del 2017, Google ha deindicizzato alcune pagine di Angular.io (un sito web Javacript renderizzato lato client e basato su Angular 2+). La domanda sorge spontanea: perché l’ha fatto? La ragione è sempre la stessa: un singolo errore nel codice ha reso impossibile renderizzare la pagina e ciò ha causato un’enorme deindicizzazione.

L’errore, da allora, è stato corretto. Igor Minar di Angular.io ha spiegato che:

“Given that we haven’t changed the problematic code in 8 months and that we experienced significant loss of traffic originating from search engines starting around December 11, 2017, I believe that something has changed in crawlers during this period of time which caused most of the site to be de-indexed, which then resulted in the traffic loss.”

“Dal momento che il codice che presentava problemi non è stato modificato in 8 mesi e che abbiamo registrato una rilevante perdita di traffico proveniente dai motori di ricerca intorno all’11 di dicembre 2017, credo che in questo periodo di tempo sia cambiato qualcosa nel funzionamento dei crawler, il che ha causato la deindicizzazione di gran parte del sito, che si è poi tradotta in perdita di traffico.”

Porre rimedio al suddetto errore di rendering su Angular.io fu possibile grazie a un esperto team di sviluppatori JavaScript e all’implementazione di un sistema di segnalazione degli errori. La correzione ha permesso di far nuovamente indicizzare le pagine che avevano presentato il problema.

Nel caso dell’HTML tradizionale, tutto è semplice e chiaro:

1. Googlebot scarica un file HTML;
2. Estrae i link dal codice sorgente e può visitarli simultaneamente;
3. Scarica i file CSS;
4. Invia tutte le risorse scaricate all’indexer (chiamato Caffeine);
5. L’indexer (Caffeine) indicizza la pagina.

L’intero processo è estremamente rapido. Le cose però si complicano quando si ha a che fare con siti web basati sul linguaggio JavaScript. Infatti, accade che:

1. Googlebot scarica un file HTML;
2. Scarica i file CSS e JavaScript;
3. In seguito, deve usare il Google Web Rendering Service (una parte dell’indexer Caffeine) per analizzare, elaborare ed eseguire un codice JavaScript;
4. Il Web Rendering Service (WRS) recupera dati da Application Programming Interface (API) esterne, dal database, ecc.
5. Finalmente, l’indexer può indicizzare il contenuto.
6. Ora Google può scoprire nuovi link e aggiungerli alla coda crawling di Googlebot.

Questo processo è molto più complicato del crawling HTML. I punti seguenti dovrebbero essere sempre presi in considerazione:

• L’analisi, l’elaborazione e l’esecuzione di file JavaScript è estremamente dispendiosa in termini di tempo.
• Nel caso di un sito web JavaScript, Google deve attendere il completamento di tutti gli step prima di poter procedere con l’indicizzazione.
• Il processo di rendering non è il solo fattore che influisce nel rallentamento del processo. C’è da considerare anche la scoperta di nuovi link. Con siti web JavaScript capita di frequente che Google non possa trovare nuove URL senza attendere che la pagina sia completamente renderizzata.

Passiamo ora a illustrare il problema che si presenta a causa della complessità del linguaggio JavaScript. Moltissimi utenti visualizzano i siti web da dispositivi mobili, come smartphone o tablet: al giorno d’oggi, infatti, il loro uso è estremamente diffuso e frequente. Pensiamo a quanto tempo è necessario per analizzare 1 MB di JavaScript su un dispositivo mobile: secondo Sam Saccone di Google, il Samsung Galaxy S7 impiegherebbe circa 850 ms, mentre il Nexus 5 impiegherebbe circa 1700 ms.

Dopo l’analisi, il JavaScript deve essere anche elaborato ed eseguito. Ogni secondo è importante.

Google, in ogni caso, ha ufficialmente dichiarato che “Il rendering di siti web basati su JavaScript in Google Search viene rinviato fino al momento in cui Googlebot ha le risorse necessarie per processare quel contenuto.”

Quindi, tutto sommato, è necessario molto più tempo per fare crawling e indexing di siti JavaScript piuttosto che HTML (il processo di renderizzazione richiede parecchio tempo e la pagina deve attendere nella coda di rendering).

Ci sono due fasi nell’indicizzazione. Nella prima fase, Google indicizza il codice sorgente della pagina. Tuttavia, per i moderni siti JavaScript accade spesso che la sorgente non contenga alcuna copia del contenuto. In questo caso, il motore di ricerca virtualmente non indicizza nulla. Poi, nella seconda fase, quando le risorse per il rendering diventano disponibili, renderizza una pagina e finalmente può indicizzare il vero contenuto e permettere al sito web di posizionarsi tra i risultati di ricerca.

Questo, tuttavia, ha forti implicazioni. Se possiedi un sito web JavaScript ampio e in continuo cambiamento, Google potrebbe avere difficoltà a scansionarlo e indicizzarlo.

Facciamo qualche esempio e poniamo che tu abbia un sito web immobiliare. Solitamente, gli agenti immobiliari pubblicano uno stesso annuncio in vari siti web. Se Google indicizzasse le offerte nei siti dei tuoi competitor nell’arco di poche ore e le tue offerte venissero indicizzate in una settimana o più, perderesti un sacco di soldi. Insomma, per farla breve, verresti facilmente surclassato dai tuoi concorrenti. Ma che senso ha far sì che Google indicizzi l’ennesima pagina con lo stesso contenuto? Per rispondere, consideriamo un altro esempio: i siti web di advertising per automobili usate. Qui gli annunci possono scadere entro pochi giorni dalla data di pubblicazione. Considerando che Google può indicizzare una nuova offerta entro 2 o 3 giorni, potrebbe essere troppo tardi! Non ha senso che indicizzi contenuti scaduti e ne ha ancora meno presentare quegli stessi contenuti agli utenti. Gli esempi sono infiniti. Basta pensare a siti con offerte di lavoro, per la prenotazione di hotel, ecc.

È importante considerare anche le limitazioni tecniche di Google, fondamentali per capire in che modo affronta i siti web JavaScript.

La maggior parte di noi utilizza browser costantemente aggiornati, quindi nella loro versione più recente. Ma questo discorso non vale per Googlebot, che utilizza Chrome 41 per il rendering dei siti web. Questo browser è stato rilasciato nel marzo del 2015, ben 9 anni fa: IT e JavaScript si sono evoluti enormemente nel frattempo e, dunque, ci sono molte moderne funzionalità che non sono accessibili.

Alcune delle maggiori limitazioni includono:

• Chrome 41 supporta la moderna sintassi JavaScript ES6 solo parzialmente. Per esempio, non supporta costruzioni come “let” fuori dalla “strict mode”;
• Interfacce come IndexedDB e WebSQL sono disabilitate;
• Cookie, local e session storage vengono ripuliti attraverso il caricamento della pagina;
• Non dimentichiamo che si tratta di un browser rilasciato quasi un decennio fa.

Un buon metodo per capire se i tuoi siti web possono essere renderizzati correttamente da Google, è quello di scaricare la versione di Chrome 41 e verificarlo tu stesso, per capire le cause di un eventuale fallimento del rendering.

La popolarità del linguaggio JavaScript è cresciuta rapidamente e ora è in ascesa. Tuttavia, alcune feature non sono implementate nei browser più vecchi (non a caso, Chrome 41 è un esempio di vecchio browser) e, come risultato, il rendering non va a buon fine. Per gestire il problema, i webmaster usano una tecnica che è stata definita “graceful degradation”. Ciò significa che per implementare alcune moderne feature, supportate solo da alcuni dei più recenti browser, dovresti assicurarti che il tuo sito web vada a “degradarsi” all’interno un browser più vecchio. Attuando il rilevamento delle feature, potrai controllare se il browser supporta una funzionalità in qualsiasi momento. Se ciò non accadesse, dovresti piuttosto utilizzarne una che sia supportata dal browser, un cosiddetto polyfill. Inoltre, se vuoi che il tuo sito web sia renderizzato da Google Search, dovresti procedere a un processo di transpiling verso l’ES5 (che tradurrà il JavaScript non comprensibile dal Googlebot in uno che, invece, riuscirà a comprendere). Per esempio, quando un traspiler incontra un “let x=5” (sintassi che molti vecchi browser non comprendono), questo si tradurrà in “var x=5” (espressione che è invece pienamente comprensibile da questi browser, incluso Chrome 41). Se stai usando una moderna funzionalità JavaScript e ti interessa che il tuo sito sia renderizzato correttamente, dovresti assolutamente attuare un processo di transpiling a ES5 e i polyfill.

Googlebot non agisce come un vero browser

Quando navighi su internet, il tuo browser (Chrome, Firefox, Opera, o qualunque sia quello che utilizzi) scaricherà tutte le risorse (immagini, script, fogli di stile) e ti mostrerà la versione renderizzata. Però, Googlebot agisce diversamente rispetto, poiché mira a scansionare tutto il web e a prendere solo le informazioni di valore. Il World Wide Web comunque è enorme, per questo Google ottimizza i suoi crawler per performance. Questo è il motivo per cui Googlebot, a volte, non visita tutte le pagine che il webmaster vorrebbe. Ancor più importante, gli algoritmi cercano di individuare se una risorsa è necessaria dal punto di vista del rendering. Se non lo è, probabilmente non verrà recuperata dai Googlebot.

Quindi Google potrebbe non prendere alcuni dei tuoi file JavaScript perché il suo algoritmo ha deciso che non sono necessari per ciò che riguarda il rendering, o semplicemente a causa di problemi di prestazione (per esempio, ci è voluto troppo tempo per eseguire uno script).

Sebbene le esatte tempistiche non siano specificate, si dice che Google non possa attendere più di 5 secondi per uno script.

Sul gruppo Google JavaScript SEO, John Mueller ha detto:

“There’s no specific timeout value that we define, mostly because the time needed for fetching the resources is not deterministic or comparable to a browser (due to caching, server load, etc). 5 seconds is a good thing to aim for, I suspect many sites will find it challenging to get there though”

“Non c’è uno specifico valore di tempo definibile, perlopiù perché il tempo necessario per il recupero delle risorse non è deterministico o paragonabile a un browser (a causa del caching, il caricamento del server, ecc.). Cinque secondi è una buona cosa a cui mirare, ma temo che molti siti troverebbero complicato raggiungere questo risultato.”

È difficile trovare valide informazioni sulle tempistiche di Google, ma si potrebbe dire che è importante prendere in considerazione fattori come:

• Importanza della pagina;
• Attuale carico dei server di Google;
• Numero di URL nella coda di rendering;
• Altre euristiche avanzate.

Se il tuo sito web carica molto lentamente, gli svantaggi sono molto significativi:

• Gli utenti potrebbero innervosirsi e lasciare il tuo sito;
• Google potrebbe avere difficoltà legate al rendering dei tuoi contenuti;
• Il processo di crawling potrebbe essere rallentato. Se la pagina è lenta, Googlebot può notare che i suoi crawler rallentano il tuo sito e decidere di diminuire il crawl rate.

Assicurati che il tuo sito sia leggero e che il tuo server risponda rapidamente, ma anche che il server non fallisca nel momento in cui il carico aumenta. Non rendere il lavoro di Googlebot più difficile di quanto dovrebbe essere. Un tipico errore di performance fatto dagli sviluppatori è quello di porre tutti i componenti del codice in un unico file. Se gli utenti navigano nella homepage, non hanno bisogno di scaricare anche il codice usato solamente nell’area admin.

Se vuoi adottare la stessa prospettiva di Google e vedere il web (e specialmente il tuo sito) nello stesso modo in cui lo vede il sommo motore di ricerca, ci sono due vie che puoi percorrere:

• Usare Google Search Console e il suo strumento Fetch & Render. Bada bene, però: non affidartici al 100%. Il vero Googlebot può avere tempi differenti rispetto al Fetch & Render.
• Usare Chrome 41. È confermato che Google usa questo browser per il rendering. Questa opzione porta con sé diversi vantaggi rispetto allo strumento di Google Search Console:
  • Grazie a Chrome 41 puoi vedere il console log. Se vedi errori in Chrome sarai quasi sicuro che anche Googlebot registrerà gli stessi errori;
  • Fetch & Render non mostra il DOM renderizzato, ma Chrome 41 sì. Usando Chrome 41 puoi essere certo che Googlebot veda i tuoi link, i tab content, ecc.;
  • Usa lo strumento di testing Rich Results. Questo strumento, infatti, può mostrarti come Google interpreta la tua pagina. Ti mostra il DOM renderizzato, il che è molto utile. Google pianifica di aggiungere l’output per il DOM renderizzato al proprio strumento Fetch & Render. Dal momento che ancora non è presente, John Muller ha consigliato di usare lo strumento Rich Result per questo. Non è chiaro se Rich Result segua le stesse regole di render usate dall’indexer di Google;
  • Usa il test Google Mobile friendly, che può mostrarti il DOM renderizzato e gli errori che Google incontra durante il rendering della tua pagina.

Google Search Console Fetch&Render non è uno strumento affidabile per controllare il tempo degli indexer

Lo strumento Fetch & Render di Google Search Console può solo dirti se Google è tecnicamente capace di fare il rendering del tuo sito; tuttavia, non affidarti ad esso quando si tratta delle tempistiche. Spesso, infatti, Google Fetch&Render è capace di renderizzare una pagina, ma il Google indexer non riesce a indicizzare il contenuto a causa del lungo lasso di tempo necessario per farlo.

Vediamo una dimostrazione pratica, offerta da Tomasz Rudzki di Onely. Partendo da una pagina web di prova, si è notato che il primo file JavaScript incluso al suo interno ha ritardato di 120s. Non c’era alcuna opzione tecnica per evitare il ritardo. Il server Nginx era programmato per attendere 2 minuti.

È risultato che Fetch&Render ha atteso 120s per uno script e per renderizzare correttamente la pagina.

Ma l’indexer è stato meno paziente:

In questo caso, il Google Indexer ha semplicemente omesso il primo script (ritardato di 120 secondi) e ha renderizzato il resto delle pagine. Insomma, sicuramente Google Search Console è un ottimo strumento, ma lo si dovrebbe usare solo per controllare che Google sia tecnicamente capace di renderizzare una pagina.

Usa il comando "site" invece della cache di Google

Molti SEO Specialist sono soliti individuare problematiche di rendering utilizzando la cache di Google. Tuttavia, questa tecnica non è valida per i siti JavaScript, perché la cache memorizza solo l’HTML di base che Googlebot riceve dal server. Ciò che vedi quando clicchi sulla cache è come il tuo browser interpreta l’HTML “raccolto” da Googlebot. Non è assolutamente correlato alla modalità tramite cui renderizza una pagina web.

Per il momento, una delle migliori opzioni per controllare se alcuni contenuti sono indicizzati è il comando “site”. Per farlo bisogna semplicemente copiare un frammento di testo dalla pagina web e digitare il seguente comando su Google: site:{il tuo sito} “{frammento}”. Se appare uno snippet con il tuo frammento ciò significa che il contenuto è stato indicizzato. Un consiglio è quello di provare la ricerca “site:” nella modalità incognito. Succede, infatti, che in alcuni casi – quando gli editor modificano il contenuto – per qualche ragione la ricerca “site” mostra ancora il vecchio contenuto come quello presente nella pagina. Dopo aver inserito la modalità incognito nel browser, invece, la ricerca “site” dovrebbe mostrare il risultato corretto.

"Visualizza sorgente" non è sufficiente quando si controllano siti JavaScript

HTML è un formato di file che rappresenta solo le informazioni di base usate dal browser per analizzare una pagina. Un documento di questo tipo contiene alcuni marcatori, come paragrafi, immagini, link e riferimenti ai file JS e CSS. Puoi vedere l’HTML iniziale della tua pagina semplicemente cliccando con il tasto destro e poi su “visualizza sorgente pagina”. Tuttavia, in questo modo non vedrai alcun contenuto dinamico (caricato tramite JavaScript). Per farlo dovresti piuttosto guardare il DOM e puoi farlo cliccando con il tasto destro e poi su “ispeziona” o “analizza elemento” (in base al browser utilizzato).

• L’iniziale HTML dal server (clic tasto destro – visualizza sorgente pagina) è solo una ricetta. Fornisce informazioni sugli ingredienti che dovresti utilizzare per fare la tua torta. Insomma, contiene una serie di istruzioni.
• Il DOM (clic tasto destro – ispeziona) è il processo di realizzazione della torta. All’inizio è solo una ricetta (un documento HTML) e poi, dopo un po’, assume una forma e finalmente è pronta (la pagina è completamente caricata).

Dal momento che Googlebot è capace di fare crawling con il JavaScript e renderizzare il contenuto, dovresti assicurarti che ogni risorsa interna ed esterna richiesta per il rendering non sia bloccata.

Nel caso in cui tu veda un significativo calo di ranking in un sito ben strutturato, dovresti controllare Fetch & Render per vedere se Google può ancora renderizzare il sito web. Generalmente, è buona norma usare questo strumento per un campione casuale di URL, di tanto in tanto, per assicurarsi che il sito sia renderizzato correttamente.

Ricorda che Googlebot non è un vero user, quindi puoi dare per scontato che non cliccherà, non compilerà i form. Ciò ha molte implicazioni pratiche:

• Se hai un negozio online e i contenuti nascosti sotto un bottone “visualizza altro” non appaiono nel DOM prima di cliccarci, questo non sarà recuperato da Google. E ciò si riferisce anche ai link nei menù.
• Tutti i link dovrebbero contenere il parametro “href”.

Inserire tag canonici tramite JavaScript

Quando vuoi utilizzare tag canonici, assicurati che siano posizionati in formato tag HTML/X-robots. I tag canonici inseriti in questo modo sono considerati meno affidabili e ci sono alte probabilità che Google li ignori. Nonostante tutto, comunque, ci sono ottimi esperimenti SEO condotti da Eoghan Henn per dimostrare che è possibile per il motore di ricerca rispettare tag canonici inseriti tramite JavaScript.

Usare il simbolo cancelletto negli URL

È ancora comune per molti JavaScript framework generare URL con un cancelletto. Tuttavia, c’è il pericolo che questi URL non vengano scansionati da Googlebot:

• URL scorretto: esempio.com/#/prova-uno/
• URL scorretto: esempio.com#URL
• URL corretto: esempio.com/prova-uno/

Potrebbe sembrare un dettaglio insignificante e trascurabile: in fondo si tratta solo di un carattere all’interno dell’URL, giusto? Sbagliato. È un elemento molto importante. Ancora John Mueller, infatti, ha dichiarato:

“For us, if we see the kind of a hash there, then that means the rest there is probably irrelevant. For the most part we will drop that when we try to index the content (…). When you want to make that content actually visible in search, it’s important that you use the more static-looking URLs.”

“Per noi di Google, vedere un simbolo del genere in quel punto significa intendere che il resto è probabilmente irrilevante. Nella maggioranza dei casi, quindi, lo lasceremmo perdere nel momento in cui si prova a indicizzare il contenuto (…). Quando vuoi che il tuo contenuto sia effettivamente visibile nelle ricerche, è importante usare URL che abbiano un aspetto più statico.”

Devi assicurarti che il tuo URL non sia di questo tipo: esempio.com/risorsa#abcd. Angular 1 di default usa degli URL basati su hashtag. Fortunatamente Angular 2 usa URL Google friendly di default.

Script lenti, API lente

Molti siti basati su JavaScript falliscono perché Google deve attendere troppo a lungo per uno script (scaricare, elaborare, eseguire). Ecco perché dovresti aspettarti che consumi rapidamente il suo crawl budget. Verifica che i tuoi script siano veloci e che il motore di ricerca non debba attendere troppo per recuperarli.

Cattiva SEO vs JS SEO

È importante ricordare che la JavaScript SEO è fatta a un livello superiore rispetto alla SEO tradizionale, ed è impossibile essere bravi in una senza essere bravi nell’altra. A volte quando incontri un problema SEO il tuo primo istinto potrebbe essere quello di collegarlo al JavaScript, ma in realtà è tutto collegato alla SEO tradizionale.

Google ha annunciato di non voler più utilizzare lo schema per crawling AJAX a partire dal secondo trimestre del 2018. Significa che ha smesso di fare crawling usando AJAX (Asynchronous JavaScript)? Non è esattamente così.

Come funzionava questo AJAX Crawling Scheme? Google si era reso conto che sempre più siti web stavano utilizzando JavaScript, ma al tempo non era in grado di renderizzarli. Quindi si è chiesto ai webmaster di creare una versione “spider-friendly” (cioè senza JavaScript) per ogni pagina web, al fine di renderla accessibile, aggiungendo _=escaped_fragment_= all’URL. Quindi, quando gli utenti visualizzavano esempio.com, Googlebot visualizzava il suo “brutto” equivalente: esempio.com?_=escaped_fragment_=. In questo modo, i webmaster riuscirono a prendere due piccioni con una fava. Sia gli utenti che i crawler erano accontentati: i primi ricevevano un sito web JavaScript e i motori di ricerca erano capaci di indicizzare correttamente il contenuto (dal momento che stavano ricevendo il formato HTML+CSS).

Ad ogni modo, il vecchio schema di crawling AJAX non era la soluzione perfetta. Dal momento che gli utenti stavano ricevendo una versione differente della pagina rispetto a quella che ricevevano gli spider, trovare le problematiche risultava complicato. Inoltre, alcuni webmaster trovavano difficoltà con il pre-rendering del contenuto per il Googlebot. Ecco perché Google ha annunciato che nel secondo trimestre del 2018 non ci sarebbe stato più bisogno di costruire due versioni di un sito.

Cosa significa tutto questo?

• Google farà il rendering del tuo sito per i propri scopi, il che significa che devi assicurarti che sia tecnicamente capace di farlo.
• Googlebot smetterà di visitare i “brutti” URL (contenenti un “escaped fragment”) e inizierà a richiedere lo stesso URL richiesto dagli utenti.
• Inoltre, dovrai trovare un modo per rendere il tuo sito scansionabile e renderizzabile da Bing e altri motori di ricerca che sono decisamente arretrati rispetto a Google per quanto riguarda il rendering di JavaScript. Possibili soluzioni includono il rendering lato server (un JavaScript universale), o l’utilizzo di uno schema crawling AJAX per il Bingbot.

Tomasz Rudzki di Onely ha chiesto direttamente a John Mueller sul forum JavaScript SEO se fosse possibile individuare il Googlebot tramite l’user agent e fornire una versione pre-rendering per Googlebot.

John Mueller ha concordato su questa affermazione e, inoltre, ha consigliato di monitorare le versioni pre-rendering costantemente, per assicurarsi che funzionino a dovere.

Questa è la soluzione migliore per entrambi i mondi, sia quello degli utenti che di Googlebot. La User Experience rimane la stessa, mentre Googlebot ottiene una istantanea pre-rendering che può essere scansionata e indicizzata più facilmente e rapidamente.

Supponiamo che Googlebot renderizzi JavaScript perfettamente e tu non abbia alcun problema con questo. Significa che puoi iniziare a festeggiare? Non proprio. Probabilmente ti stai dimenticando di Bing che, per esempio, è usato da un terzo dei web user negli Stati Uniti. Per ora è certo supporre che questo motore di ricerca non renderizzi il JavaScript (molte voci sembrano affermare che Bing faccia rendering JavaScript su pagine dotate di grande authority, ma non si trova facilmente un esempio concreto).

Parliamo di un caso interessante, in proposito: Angular.io, il sito ufficiale di Angular2+. Alcune pagine sono state costruite usando l’approccio Single-Page Application. Ciò significa che il suo HTML base non contiene alcun contenuto. Poi un file JavaScript esterno carica tutto il contenuto necessario. Sembra che Bing non possa vedere il contenuto di Angular.io:

Questo sito web si posiziona secondo per “Angular” su Bing. E per “Angular4”? Idem, si posiziona secondo, dietro AngularJS.org (un sito ufficiale di Angular1). Per “Angular5”? Ancora, secondo. Se vuoi le prove del fatto che Bing non riesca ad affrontare Angular.io, prova a trovare qualunque frammento legato al sito usando il comando “site”. Vedrai che risulta impossibile. Una cosa insolita. Il sito web ufficiale di Angular2 non può essere scansionato e indicizzato correttamente da Bingbot. E per quanto riguarda Yandex? Il discorso non cambia troppo: Angular.io non si posiziona nemmeno nella top 50 per “Angular” su Yandex.

Il punto è questo: non dimenticarti di Bing quando punti su nuove tecnologie web.

Quando noti che Google sta avendo difficoltà con il tuo sito renderizzato lato client, dovresti prendere in considerazione il pre-rendering o l’isomorphic JavaScript. Ma qual è il migliore?

• Il pre-rendering è utile quando noti che i crawler dei motori di ricerca non sono capaci di renderizzare il tuo sito. Quando un crawler visita il tuo sito web tu gli proponi un’istantanea HTML (senza JavaScript). Allo stesso tempo gli utenti ottengono la versione JavaScript della tua pagina. L’istantanea è usata solo dai bot e non dagli utenti. Puoi usare servizi esterni per il pre-rendering (come pretender.io) o strumenti come PhantomJS o Chrome Headless da implementare sul tuo server.
• L’isomorphic JavaScript (o JavaScript isomorfo) è un altro approccio popolare. Qui sia gli user che i motori di ricerca ricevono una pagina piena di contenuto durante il caricamento iniziale. Poi tutte le feature JavaScript vengono caricate in un secondo momento. È buona sia per gli utenti che per i motori di ricerca ed è l’opzione più consigliata anche dai Googlers.

C’è un problema però: molti sviluppatori hanno difficoltà nell’implementazione del JavaScript isomorfo. Controlla i tuoi documenti sul framework per conoscere meglio come fare rendering lato server nel tuo framework JavaScript. React 16 (rilasciato a novembre) ha portato molti miglioramenti per ciò che riguarda il rendering lato server. Una delle nuove opzioni è la funzione “RenderToNodeStream” che rende il processo di Server-Side Rendering molto più semplice.

In breve, se vuoi che il tuo sito sia renderizzato lato server, dovresti evitare di usare funzioni che operino direttamente sul DOM. Per citare Wassim Chegham, uno sviluppatore esperto di Google: “Una delle più importanti best practices che consiglio è mai toccare il DOM”.

In Onely sono stati condotti alcuni esperimenti per investigare approfonditamente in che modo Googlebot può muoversi per scoprire e seguire link nei casi di siti HTML e JavaScript. I risultati di questi esperimenti sono stati strabilianti. Nel caso dei siti web HTML Googlebot è stato capace di raggiungere tutte le pagine. Tuttavia, nel caso dei siti web JavaScript, era comune che non fosse nemmeno in grado di raggiungere il secondo livello. L’esperimento è stato ripetuto in 5 domini differenti, ma i risultati sono stati sempre gli stessi.

Bartosz Goralewicz ha chiesto a John Muller quale fosse la problematica. John ha confermato che Google ha visto i link JavaScript ma “Googlebot non sentiva di doverli scansionare”. Ha aggiunto: “Non scansioniamo tutte le URL, o le scansioniamo tutte rapidamente, specie quando i nostri algoritmi non sono sicuri del valore della URL, un altro aspetto insidioso di un sito prova.”

Bisogna evidenziare che nonostante questi siti fossero creati solo al fine dell’esperimento, il contenuto è stato realizzato in ugual modo. È stato generato con Articoolo, basato sull’intelligenza artificiale che produce un risultato piuttosto buono. Googlebot ha ricevuto due siti molto simili e ha scansionato solo uno di essi, favorendo il sito HTML rispetto a quello JavaScript.

• Ipotesi 1: gli algoritmi di Google hanno classificato entrambi i siti web come siti prova. Poi hanno assegnato un tempo di esecuzione prestabilito per tutti e due: a) 6 pagine oppure b) 20 secondi di esecuzione (recuperare tutte le risorse e renderizzarle).
• Ipotesi 2: Googlebot classifica entrambi i siti come siti prova. Nel caso del sito JavaScript nota che ci vuole troppo tempo per recuperare una risorsa, quindi lo salta.

Il sito web precedentemente menzionato aveva molti link di alta qualità. Le persone lo stavano volontariamente condividendo su internet. Inoltre, il sito è stato in grado di generare traffico organico.

Quindi, in questo caso, quando si tratta di un sito prova e quando di un sito web vero e proprio? È una domanda spinosa. Ci sono buone possibilità che creando un nuovo sito web renderizzato lato client avrai una situazione esattamente uguale a quella descritta sopra. Googlebot non scansionerà il tuo contenuto. Ciò accade quando non si è più di fronte a una situazione teorica ma il problema diventa reale. Inoltre, la vera problematica è che non c’è virtualmente nessun caso concreto di un sito web/brand/negozio online JavaScript renderizzato lato client che sia riuscito a posizionarsi bene.

Potresti pensare che sicuramente la maggior parte dei SEO Specialist siano consapevoli di questo e che le grandi compagnie possano investire largamente per affrontare queste problematiche; tuttavia, che dire dei piccoli business che non hanno le risorse economiche o le competenze tecniche? Ciò, per esempio, potrebbe porre un grosso problema per un piccolo ristorante a conduzione familiare con un sito Javascript renderizzato lato client.

• Google utilizza Chrome 41 per fare rendering dei siti web. Questa versione di Chrome è stata rilasciata nel 2015, quindi non supporta le moderne funzionalità JavaScript. Puoi usare Chrome 41 per assicurarti che Google sia in grado di renderizzare il tuo contenuto;
• Solitamente non basta analizzare solo il codice sorgente (HTML) del tuo sito. Invece, dovresti analizzare il DOM;
• Google è l’unico motore di ricerca che renderizza JavaScript su larga scala;
• Non dovresti usare la cache di Google per controllare in che modo indicizza il tuo contenuto. Ti dirà soltanto come il tuo browser interpreta l’HTML raccolto dal Googlebot. È completamente non correlato rispetto a come Google fa il rendering del tuo contenuto;
• Usa spesso lo strumento Fetch&Render, ma non contare sui tempi indicati in esso. I tempi di indexing potrebbero essere totalmente differenti;
• Il comando “site:” può essere molto utile;
• Dovresti assicurarti che un menù sia evidente nel DOM prima di cliccare su qualsiasi elemento del menù;
• Gli algoritmi di Google cercano di individuare se una risorsa è necessaria dal punto di vista del rendering. Se non lo è probabilmente non verrà recuperata dal Googlebot;
• Dovresti assicurarti che i tuoi script siano veloci (molti esperimenti fanno notare che Google difficilmente attende per più di 5 secondi). Assicurati che il tuo server non rallenti quando il carico aumenta. Inoltre, cerca di ottimizzare i tuoi script: ci sono molte cose che possono essere migliorate;
• Se Google fallisce il rendering puoi prendere solo l’HTML base per l’indicizzazione;
• Non c’è virtualmente nessun caso concreto di un sito/brand/negozio online posizionato bene.

All’interno del mondo della SEO non si può dire con certezza se Google tratti (e posizioni) i siti web JavaScript allo stesso modo dei siti HTML. Sapendo questo, è chiaro che esperti SEO e sviluppatori stanno appena iniziando a comprendere come rendere scansionabili i moderni framework JavaScript. Quindi è importante ricordare che non c’è una regola che vale sempre. Ogni sito è diverso. Se hai intenzione di costruire un sito JavaScript assicurati di lavorare con sviluppatori e SEO Specialist che sappiano il fatto loro.

Per NetStrategy, la SEO è una delle colonne portanti per una buona strategia di Web Marketing. Hai ulteriori domande o curiosità sull'argomento? Vorresti capire in che modo la SEO può aiutare te e il tuo business? Nessun problema! Siamo qui per questo. Clicca qui e parliamo di come far crescere il tuo progetto.

[Per questo articolo si ringraziano Tomasz Rudzki, autore dell'articolo originale qui tradotto e riadattato, e Bartosz Góralewicz di Onely_, con cui NetStrategy ha instaurato una collaborazione che, giorno dopo giorno, è fonte di arricchimento reciproco.]_