JavaScript SEO: evitare le insidie ​​del rendering lato server

JavaScript SEO è attualmente uno degli argomenti caldi nel settore SEO, poiché il Web moderno si evolve e sempre più siti Web vengono rilanciati o sono basati su applicazioni Web basate su JavaScript, principalmente su React o AngularJS. Con questo, si aggiunge maggiore complessità alla SEO, poiché dobbiamo assicurarci che Google sia in grado di eseguire il rendering di JavaScript in modo efficace, in modo che le pagine possano essere indicizzate e classificate correttamente. Questo può essere ottenuto utilizzando il rendering lato server. Tuttavia, questo non è privo di rischi. In questo articolo, esamino cinque errori di rendering lato server e spiego come evitarli.

Se stai cercando supporto nell'ottimizzazione tecnica del tuo sito web, perché non fissare un appuntamento non vincolante con i nostri consulenti Digital Strategies Group e scoprire dove possono aiutarti?

Richiedi un appuntamento!

Quali diversi tipi di rendering lato server esistono?

Il pre-rendering del tuo sito Web per Google sul tuo server (rendering lato server, SSR) è un'opzione per garantire che il tuo sito Web JavaScript sia compatibile con Googlbot. In questo modo, puoi fornire a Google la versione HTML prerenderizzata del tuo sito Web, mentre l'utente ottiene la versione del browser normale (non ancora sottoposta a rendering).

Tuttavia, quando si tratta di rendering lato server, ci sono anche diversi modi per eseguire il rendering, come puoi vedere dal grafico successivo, che è stato utilmente fornito da Google, con alcune utili aggiunte di Jan-Willem Bobbink.

Esistono tre modi principali per impostare ed eseguire il rendering lato server:

1. Rendering lato server con HTML dinamico

Il rendering lato server crea una versione HTML sottoposta a rendering di ogni URL su richiesta.

2. Rendering statico con HTML statico

Fondamentalmente, questo crea una versione HTML pre-renderizzata (statica) di un URL in anticipo e la memorizza nella cache.

3. Rendering lato server con (ri)idratazione con HTML dinamico e JS/DOM

Il server fornisce una versione HTML statica dell'URL e del client (browser, ecc.) che include già un markup DOM (Document Object Model) strutturato. Il client lo prende e lo trasforma in un DOM dinamico che può reagire ai cambiamenti lato client e lo rende più interattivo.

Google ha pubblicato un'ottima panoramica del rendering del Web, con tutti i pro e i contro, oltre a una spiegazione più approfondita se sei interessato. Ma prima di tutto, se stai cercando aiuto sull'argomento JavaScript SEO o Server Side Rendering, assicurati di contattarci qui al Searchmetrics Digital Strategies Group.

Mettiti in contatto!

Insidie ​​durante il rendering di siti Web JavaScript tramite il server

Di recente ci siamo imbattuti in alcuni problemi SSR con uno dei nostri clienti. Gestiscono il loro sito Web su Angular JS e lo rendono con Rendertron tramite un Chrome senza testa.

Usano un approccio di rendering SSR statico, il che significa che eseguono il rendering di una pagina e memorizzano nella cache l'HTML sul server (in anticipo). L'HTML memorizzato nella cache non verrà sostituito automaticamente ma si basa sulla logica di rendering. Di seguito sono riportati cinque problemi che abbiamo riscontrato lavorando su questo sito Web. Li condivido con te qui, in modo che se hai sfide simili, avrai un'idea di come affrontarle. Tuttavia questo può essere considerato come un elenco incompiuto/espandibile.

1. Quando non fai nulla

Quando non ti interessa e non presti alcuna attenzione a come Google visualizza la tua pagina, lascia che ti mostri come Google esegue il rendering (effettivamente vede) la tua pagina. Questo si basa su un sito Web costruito su un'applicazione a pagina singola (SPA) che utilizza un framework JavaScript, senza rendering lato server.

Questo non sembra particolarmente promettente, vero? Questo è esattamente il motivo per cui è importante utilizzare SSR, perché in tal caso si presenta così:

2. Impaginazione

Come gestire le tue pagine impaginate quando si tratta di rendering? Ebbene, specialmente nella pubblicazione, le pagine impaginate possono ancora essere una buona cosa per servire Google con i tuoi articoli (più recenti) mentre Google li sta scansionando. Se dai un'occhiata ai tuoi file di registro, vedrai come Google sta accedendo alla tua paginazione, in modo da sapere dove ha senso fornire una versione prerenderizzata (spoiler: non è necessario fornire 399 URL con una versione renderizzata )

Poiché il nostro client esegue il rendering con un approccio SSR statico, ha semplicemente eseguito il rendering della prima pagina e ha eseguito il mirroring della versione memorizzata nella cache di Pagina 1 fino a pagina 10. Senza alcuna versione renderizzata da pagina 11 in poi. Ecco due schermate che mostrano abbastanza bene il problema, con esattamente lo stesso contenuto di pagina 1 fornito anche alle pagine 2-10.

Ciò significa che fornisci a Google 10 pagine con gli stessi contenuti e articoli. Idealmente, vuoi che Google renda tutte le pagine come uniche con articoli impaginati correttamente.

3. Rinnova la versione renderizzata delle pagine delle categorie dopo la pubblicazione di un nuovo articolo/prodotto

Il nostro cliente ha aumentato la sua posizione in quasi tutte le proprietà di Google News in modo abbastanza significativo, come AMP Carousels, Google News Box e Mobile News Box, con l'eccezione di Publisher Carousels. Abbiamo iniziato a indagare su questo e si è scoperto che il nostro client non ha aggiornato la versione memorizzata nella cache quando è stato pubblicato un nuovo articolo. Abbiamo scoperto che hanno rinnovato la loro versione cache delle categorie principali una settimana dopo:

e sulle sottocategorie anche un mese dopo.

Ciò ha portato al fatto che avevano ancora un vecchio articolo sull'argomento Brexit nella loro versione prerenderizzata, ma non avevano tutti i nuovi articoli pubblicati sull'argomento. La nostra ipotesi qui è che, a causa di questo problema, non c'erano abbastanza nuovi articoli per Google per popolare un carosello e questo ha avuto un grande impatto negativo sulle loro prestazioni. Stiamo ancora studiando l'impatto del cambiamento.

4. Il rendering può causare contenuti duplicati e canonizzazione errata

Fornire una versione prerenderizzata di un URL può causare problemi di sistema. Poiché il nostro client ha fornito pagine prerenderizzate, ciascuna con il proprio URL creato dal motore di rendering, questi URL avevano i parametri “p=1; render=1” ed erano completamente indicizzabili:

C'era anche un nuovo canonico impostato dal motore SSR per quell'URL. Abbastanza inquietante, eh?

Idealmente, vuoi escludere questi parametri dalla scansione di Google.

5. Il titolo della pagina cambia durante il rendering

Abbiamo anche scoperto che i titoli delle pagine correnti sono stati visualizzati tramite JavaScript. Ciò è stato fatto in un modo che significava che il meta titolo HTML mostrava sempre il nome del marchio quando JavaScript era disabilitato. E quando lo user agent non è Googlebot, esegue solo il rendering del titolo della pagina HTML. Vedere i seguenti due esempi di seguito. Il primo mostra l'URL con JavaScript disabilitato. Il secondo è lo stesso URL, ma con JavaScript abilitato.

Per assicurarti che i metadati vengano sempre visualizzati correttamente, dovresti includerli nella versione non sottoposta a rendering (JavaScript) dell'URL.

Conclusione

Il rendering lato server non può essere usato come approccio taglia-cookie per il rendering di applicazioni a pagina singola. È necessaria un'attenzione speciale per gli approcci statici in cui si fornisce solo un'istantanea. Come puoi vedere dall'esempio del nostro cliente, devi assicurarti che il motore SSR fornisca sempre una versione aggiornata dell'URL, altrimenti Google non vedrà e acquisirà i tuoi articoli più recenti e sarai perdendo traffico prezioso.

Prima di rilanciare da un sito Web basato su HTML a un framework basato su JavaScript, assicurati che il rendering lato server sia incluso e che sia sempre disponibile in modo dinamico!

Se hai problemi con JavaScript o sei comunque alla ricerca di supporto nell'ottimizzazione tecnica del tuo sito web, perché non fissare un appuntamento non vincolante con i nostri consulenti Digital Strategies Group e scoprire dove possono aiutarti?

Richiedi un appuntamento!