SEO JavaScript per l'ecommerce

Googlebot utilizza un processo di indicizzazione in due fasi per le pagine con molto JavaScript. Nella prima fase, scansiona la risposta HTML grezza e indicizza il contenuto presente nella risposta iniziale del server. Nella seconda fase, mette la pagina in coda per il rendering usando un browser Chromium headless, esegue il JavaScript e poi indicizza il contenuto completamente renderizzato. Il problema critico e il divario tra queste due fasi.

La coda di rendering puo richiedere da pochi secondi a settimane a seconda dell'allocazione del budget di crawl di Google per il vostro dominio. Durante questo ritardo, qualsiasi contenuto che dipende dall'esecuzione JavaScript rimane invisibile per Google. Per un negozio ecommerce con migliaia di pagine prodotto, questo significa che nuovi prodotti e aggiornamenti dei prezzi potrebbero non apparire nei risultati di ricerca per giorni.

Il motore di rendering di Googlebot esegue una versione relativamente recente di Chromium, quindi le API JavaScript moderne sono generalmente supportate. Tuttavia, ha limitazioni importanti: non interagisce con le pagine (nessun clic, scorrimento o invio di moduli), ha un timeout di rendering di circa 5 secondi e blocca certi tipi di risorse.

Il rendering lato client (CSR) e il default per la maggior parte dei framework per applicazioni a pagina singola. Il server invia una struttura HTML minimale e un bundle JavaScript che costruisce l'intera pagina nel browser. Per il SEO ecommerce, il CSR puro e la scelta peggiore. Titoli, descrizioni, prezzi e dati strutturati dei prodotti sono assenti dall'HTML iniziale.

Il rendering lato server (SSR) genera l'HTML completo sul server per ogni richiesta, fornendo contenuto prodotto completo immediatamente. Framework come Next.js, Nuxt.js e Angular Universal offrono capacita SSR. Googlebot puo indicizzare questo contenuto nella prima fase di crawl.

La generazione di siti statici (SSG) pre-renderizza le pagine al momento del build, producendo file HTML statici serviti direttamente da un CDN. Per i cataloghi ecommerce con dati prodotto stabili, SSG offre i tempi di caricamento piu veloci.

La rigenerazione statica incrementale (ISR) offre un compromesso. Le pagine vengono generate staticamente ma possono essere rivalidate e rigenerate secondo un programma definito.

Il rendering ibrido, dove diversi tipi di pagina utilizzano strategie diverse, e l'approccio pragmatico per la maggior parte dei negozi ecommerce.

I meta tag, gli URL canonici e i dati strutturati devono essere presenti nell'HTML renderizzato dal server, non iniettati lato client. Se il vostro framework genera il tag <title>, la meta description e il link canonico tramite JavaScript dopo il caricamento, Googlebot potrebbe mancarli durante il primo passaggio di crawl. Usate la soluzione di gestione head del vostro framework.

I link interni sono frequentemente rotti nei negozi ecommerce renderizzati in JavaScript. Menu di navigazione, breadcrumb, link di categoria e paginazione basati su gestori di eventi JavaScript anziche su tag <a href> standard sono invisibili a Googlebot. Ogni link di navigazione deve usare elementi ancora corretti con attributi href completi.

Il lazy loading delle immagini prodotto puo essere compatibile con il SEO se implementato correttamente. Usate l'attributo nativo loading='lazy' per le immagini sotto la piega, ma assicuratevi che le immagini prodotto principali si carichino immediatamente.

La gestione degli URL tramite la History API deve produrre URL reali e scansionabili. Se il vostro sistema di filtri prodotto cambia la visualizzazione senza aggiornare l'URL o usa routing basato su hash, i motori di ricerca non possono scoprire quegli stati.

I bundle JavaScript grandi impattano direttamente sia l'esperienza utente che la capacita di Googlebot di renderizzare le vostre pagine. Ogni kilobyte di JavaScript che deve essere scaricato, parsificato ed eseguito ritarda il rendering del contenuto prodotto. Il budget di crawl di Google e finito, e JavaScript inefficiente spreca risorse di rendering.

Il code splitting e essenziale per i negozi ecommerce. Dividete il bundle JavaScript per route in modo che le pagine prodotto carichino solo il codice necessario per la visualizzazione del prodotto. Gli import dinamici permettono di differire funzionalita non critiche.

Il tree shaking elimina il codice inutilizzato dai vostri bundle. Verificate le dipendenze regolarmente poiche molti negozi importano intere librerie di utilita quando usano solo poche funzioni.

Gli script di terze parti sono la fonte piu comune di appesantimento JavaScript nell'ecommerce. Widget di chat, piattaforme analytics, motori di raccomandazione e pixel di retargeting aggiungono ciascuno JavaScript che compete con il rendering dei prodotti. Caricate gli script di terze parti in modo asincrono con gli attributi async o defer.

Monitorate il tempo di esecuzione JavaScript con la tab Performance di Chrome DevTools e Lighthouse. Puntate a un tempo di blocco totale sotto i 200ms e un time-to-interactive sotto i 3,8 secondi.

Le pagine prodotto nei negozi ecommerce contengono diversi tipi di contenuto dinamico: prezzi che cambiano con le promozioni, stato dell'inventario in tempo reale, recensioni che si accumulano nel tempo e informazioni specifiche delle varianti. Ogni tipo richiede un approccio diverso per garantire la visibilita nei motori di ricerca.

I prezzi e la disponibilita devono essere renderizzati lato server con le informazioni della variante predefinita o canonica. Quando un utente seleziona una taglia o un colore diverso, il JavaScript lato client puo aggiornare il prezzo visualizzato. Lo stato predefinito renderizzato dal server e cio che Googlebot indicizzera.

Le recensioni prodotto sono critiche per il SEO perche forniscono contenuto unico, copertura di parole chiave a coda lunga e dati strutturati AggregateRating. Se le recensioni si caricano in modo asincrono tramite chiamate API, potrebbero non essere disponibili quando Googlebot renderizza la pagina.

La navigazione a faccette e i filtri prodotto presentano una sfida complessa di JavaScript SEO. Le interazioni dei filtri dovrebbero aggiornare l'URL con parametri scansionabili, ma la maggior parte delle combinazioni di filtri dovrebbe essere bloccata dall'indicizzazione per prevenire il gonfiamento dell'indice.

Il monitoraggio continuo della pipeline di rendering JavaScript e essenziale perche gli aggiornamenti del framework, le modifiche agli script di terze parti e le modifiche del CMS possono rompere il rendering lato server senza sintomi visibili all'utente. Una pagina che funziona perfettamente per gli utenti puo essere completamente vuota per Googlebot se SSR fallisce silenziosamente.

Il rapporto Copertura di Google Search Console e il vostro strumento di monitoraggio principale. Osservate i picchi nelle categorie 'Scoperta - attualmente non indicizzata' o 'Scansionata - attualmente non indicizzata', che spesso indicano fallimenti di rendering.

Impostate test di rendering automatizzati usando script Chrome headless o Puppeteer che simulano il comportamento di Googlebot. Questi test dovrebbero disabilitare JavaScript, catturare l'HTML renderizzato dal server, poi riabilitare JavaScript e confrontare il DOM renderizzato.

Monitorate i tassi di errore JavaScript in produzione con servizi di tracciamento errori come Sentry o Datadog. Gli errori che impediscono il rendering nell'ambiente di Googlebot potrebbero non manifestarsi nei browser regolari.

Tracciate le prestazioni di rendering della pagina specificamente dalla prospettiva SSR. Monitorate i tempi di risposta SSR separatamente e impostate avvisi per tempi di risposta che superano 1-2 secondi.