Aiuto! Abbiamo migrato il sito su una nuova piattaforma ed è sparito dai motori di ricerca. Eppure è stato sviluppato secondo la più recente tecnologia da un’agenzia strapagata…

Oppure.

Aiuto! Sono passati già 6 mesi e il mio nuovissimo sito fa ancora 20 visite organiche (lo staff interno che cerca il brand). Eppure pubblico 8 contenuti al giorno e faccio link building fin dall’inizio!

Quando un Cliente mi parla di “nuova tecnologia”, 9 volte su 10 ormai si parla di siti costruiti in JavaScript.

Gioia di ogni developer, dolore per ogni SEO.

JavaScript è ovunque… ed è un bene, perché è una tecnologia che permette di fare cose bellissime con risorse contenute. Il problema è quando JS non si limita ad aggiungere funzionalità (pur fondamentali per la UX) ma costituisce l’architettura dell’intero sito (qualcuno ha parlato di Single Page Applications?). Quando un sito è totalmente dipendente da JS, nel senso che elementi fondamentali come i menu o – Zeus ce ne scampi! – il contenuto testuale… è lì che iniziano i problemi SEO.

seo-per-siti-in-javascript

 

Google legge il Javascript. Sì, ma.

Facciamo chiarezza: Googlebot, il crawler di Google, vuole fare il ribelle ma è ancora un tradizionalista. Preferisce siti semplici, con un codice HTML chiaro e leggibile fin dal primo approccio. È il motivo per cui, lato SEO, continuano ad avere successo siti basici sviluppati su CMS come WordPress: semplici e veloci. In una parola: Javascript sì… ma solo per gli elementi “di contorno”.

Sappiamo per certo che Google sta lavorando duramente per aumentare le capacità del bot di leggere il contenuto fornito in JS (come nel caso del recentissimo supporto dato ad ES6, la più moderna di Javascript).

Ma.

Non tutti i developer sanno che Google quando scansiona la nostra pagina non esegue istantaneamente il rendering. Spesso lo fa a distanza di giorni… e quando nota incoerenze con una più recente scansione (ad esempio perché abbiamo modificato dinamicamente il contenuto della pagina… che è lo scopo principale di un sito sviluppato con tecnologia Javascript) il processo rischia di ricominciare da capo.

 

Nella cosiddetta “first-wave” il codice HTML viene generato dal server e servito al crawler che può immediatamente indicizzarlo. L’esecuzione del JS avverrà solo in differita nella second-wave. Diventa quindi fondamentale che tutti gli elementi chiave lato SEO della pagina vengano forniti fin dalla prima ondata: il rischio concreto è una enorme difficoltà nel guadagnare posizioni e competere organicamente con siti della nostra stessa “qualità” ma sviluppati senza l’utilizzo intensivo di Javascript.

 

SEO e Javascript: Best practices

Se non abbiamo voglia di essere presi a schiaffi dal motore di ricerca sarà bene ricordare alcune cose quando sviluppiamo il nostro sito:

  • non generare i Meta Tag in JS
  • non generare il main content (testo o immagini chiave) in HS
  • Redirect? Evitiamo il JS
  • Per i link preferiamo l’html: tag <a> e url dentro l’attributo href
  • evitiamo di caricare contenuti fondamentali solo in seguito ad interazioni con la pagina (il Googlebot NON interagisce!)
  • utilizziamo il tag <noscript> e i dati strutturati per supportare Google nella scansione dei contenuti caricati in lazy loading
  • non blocchiamo (MAI) le risorse JS da robots.txt
  • il sito non si vede su Google? Testiamo come Google vede il sito (da Search Console)!

Tutto molto bello ma come faccio se il mio sito è sviluppato con logiche differenti e tutti questi elementi chiave sono forniti proprio in Javascript?

 

Dynamic rendering is still the way

Proprio in questi giorni sembra che Google stia testando una nuova versione del browser utilizzato dai suoi crawler, con rinnovate possibilità nel rendering del JS, le best practice per essere sicuri che le cose funzionino e che i bot leggano correttamente le nostre pagine sono sempre le stesse:

  • Rendering Ibrido (Isomorphic o Universal Applications… che paroloni!)
    La soluzione a lungo termine preferita da Google: consiste nel rendering lato server di tutte le pagine. In seguito al caricamento iniziale (solo per gli utenti umani) o in seguito ad una interazione, avviene l’aggiornamento dei contenuti con Javascript.
    Pro: migliora le performance e facilita l’indicizzazione.
    Contro: oneroso in termini di risorse hardware, necessita un framework che supporti questo approccio e spesso è complesso da implementare ex-post.
  • Rendering Dinamico
    Il cloaking autorizzato da Google. Appoggiandosi a strumenti di terze parti, una copia dell’HTML di ogni pagina, totalmente renderizzato viene conservato e fornito ai bot selezionati al posto del normale codice non eseguito… quello che viene invece servito ai client “umani”.
    Pro: facile da implementare.
    Contro: per ora è supportato da Google ma, trattandosi di fatto di cloaking, non sappiamo se la scena muterà.

 

Dubbi? Perplessità? Ne sono sicuro.
E noi siamo qui per questo.

 

Keep in Touch with Francesco!