Dubbi su JavaScript e SEO? Ecco alcune risposte di Google
Come gestire al meglio Javascript per il nostro sito, e soprattutto come farlo in maniera efficiente per Google e per la SEO? Questa resta una delle aree più critiche e con le maggiori zone d’ombra del lavoro online, e quindi John Mueller e Martin Splitt di Google hanno deciso di chiarire un po’ di questioni rispondendo a domande precise nel corso dell’ultimo #askgooglewebmaster su YouTube.
JavaScript e SEO, i chiarimenti di Google
I due Googler hanno raccolto le domande ricevute accomunate dal tema JavaScript e hanno provato a fornire indicazioni a webmaster e sviluppatori impegnati nell’ottimizzare le applicazioni del linguaggio di programmazione per il proprio sito, senza influenzare negativamente il posizionamento sui motori di ricerca.
Come gestire i vecchi asset e la cache
La prima domanda ci porta subito nelle questioni pratiche: un utente chiede infatti consigli per gestire i vecchi asset quando si usano i Rails Asset Pipeline per la caching. In particolare, si interroga sullo status code da restituire: “Googlebot scansiona queste vecchie risorse che attualmente abbiamo messo in 404, ma è meglio impostare un 410 o mantenere ancora in vita tali asset per qualche mese? È qualcosa che può annientare il nostro crawl budget?”
La risposta è affidata a Martin Splitt, Developer Advocate at Google, che premette che in realtà la questione riguarda in generale ogni tipo di risorsa obsoleta che vogliamo aggiornare. In particolare, i Rails Asset Pipeline è un modo con cui “i rails processano e pre-processano i tuoi asset così come li hai in fase di sviluppo per la parte di caricamento del sito”, e quindi, è “una pipeline automatica che tratta gli asset del sito nell’applicazione rails”.
Rispetto alla gestione delle risorse vecchie – come vecchio JavaScript, versioni precedenti del CSS e immagini che non sono più caricate nelle pagine – Splitt spiega che il metodo migliore è mantenere questi asset ancora “vivi” e “attivi” fino a quando Googlebot non scansiona nuovamente l’attuale contenuto HTML e ottiene i nuovi asset. Eliminando immediatamente le vecchie risorse potrebbero sorgere problemi di scansione o rendering interrotti a causa del caching, quindi il consiglio è di aspettare un po’, verificando sui server logs quando il bot smette di usare questi asset e solo poi eliminarli completamente.
Cosa fare con elementi irrilevanti nel pre-rendering
La seconda domanda riguarda invece l’aspetto del pre-rendering, e l’utente chiede se si possono sostituire o saltare gli elementi irrilevanti, come le barre dei grafici svg generati da JavaScript. A rispondere stavolta è John Mueller che, dal “suo punto di vista”, invita a “includere sempre tutto quello che c’è” così che, quando Googlebot accede alle pagine del sito, possa vedere il contenuto completo.
È poi Splitt a prendere parola per approfondire il tema del pre-rendering, sottolineando che si tratta “solo” di lanciare JavaScript server-side quando il contenuto cambia e poi dispiegare le risorse statiche a tutti; in questo caso, non bisognerebbe “saltare” elementi. La stessa risposta (includere tutto) vale anche nella situazione del rendering dinamico, dove sostanzialmente si offre agli utenti un contenuto diverso da quello dei crawler.
Il title tag, le chat e JavaScript
Molto specifica anche la terza domanda sotto i riflettori: se un sito ha un sistema di chat che riscrive il tag title per indicare la notifica al visitatore, come si può evitare che Google indicizzi la versione del titolo riscritta dinamicamente da JavaScript?
Non c’è molto da fare, secondo i Googler, se non evitare preventivamente questo scenario: quando fa il rendering della pagina, Googlebot prende i titoli scritti che trova e quindi potrebbe leggere quello indesiderato. La soluzione potrebbe essere nascondere o ritardare la chat dietro l’interazione dell’utente, perché Googlebot non interagisce con queste cose: quindi, un processo ideale sarebbe quello che inizia con il clic sul pulsante, prosegue con la comparsa del popup della chat e poi determina la modifica al titolo.
Cosa inserire nel pre-rendering?
Per l’ultima domanda si ritorna al tema del pre-rendering, con un utente che il dubbio se possa ancora essere elementi JavaScript, tipo quelli che generano cambiamenti minimi al layout del contenuto, ma non richieste AJAX.
Mueller ricorda che con il pre-rendering fondamentalmente possiamo rigenerare quelle pagine in anticipo e servirle agli utenti, e quindi “va benissimo avere un po’ di elementi JavaScript anche lì dentro”. Questo vale anche dal punto di vista dell’utente, perché a volte servi contenuti in modo molto veloce se usi il pre-rendering e poi utilizzare JavaScript per aggiungere elementi interattivi.
Quindi, non dobbiamo eliminare tutti gli elementi JavaScript nel pre render delle pagine, ma anzi il processo corretto, come aggiunge Splitt, è quello di usare la cosiddetta “idratazione”: hydration significa lanciare JavaScript sul browser per migliorare una pagina web renderizzata server side. Questo permette di dare il contenuto all’utente con la massima rapidità possibile.
Riflessioni su JavaScript e SEO
Prima di concludere l’appuntamento video, i due Googler discutono brevemente dell’importanza di JavaScript per la SEO e in particolare delle forme di rendering: secondo Splitt, a parte il rendering dinamico (un espediente, una soluzione temporanea che quindi dovrebbe svanire), rendering lato server e pre-rendering sono concetti destinati a restare a lungo perché utili.
Con questi sistemi infatti possiamo dare agli utenti e ai crawler i contenuti in modo più veloce; con l’HTML può passare tutto così com’è, mentre ciò che è scritto in JavaScript deve essere prima analizzato ed eseguito prima di generare il contenuto. Quindi, Googlebot non è capace di fare uno streaming contemporaneo del contenuto sul lato browser, ma non deve neppure farlo grazie appunto alla disponibilità lato server.
