Come eseguire un audit JavaScript SEO su rendering, link, contenuti e performance
3 Settembre 2026 · Guide
L’audit JavaScript SEO è un controllo tecnico delle pagine che usano JavaScript per mostrare contenuti o gestire la navigazione. Serve a individuare difetti ripetibili e a consegnare al fornitore del sito le prove necessarie per correggerli.
In breve
- L’audit confronta la risposta del server con ciò che compare dopo JavaScript.
- Il campione deve rappresentare i diversi modelli di pagina e i casi limite.
- Ogni difetto va riprodotto e ricontrollato sulla versione corretta del sito.
Il risultato da ottenere
Un audit JavaScript SEO deve stabilire, per ciascun template, se contenuto, link e segnali tecnici esistono già nella risposta server oppure compaiono solo dopo rendering e chiamate API. Il risultato utile è una mappa delle differenze che consenta agli sviluppatori di riprodurre il difetto e verificarne la correzione.
Mappare framework, rendering e routing
CSR, SSR, SSG, hydration e rendering ibrido producono comportamenti diversi. L'audit deve documentare come vengono generate pagine, metadati, link e status per ogni template.
Confrontare HTML iniziale e DOM renderizzato
Titolo, testo, link, canonical, hreflang, structured data e dati critici vanno verificati prima e dopo JavaScript. Il rendering non deve cambiare in modo incoerente segnali essenziali.
Il confronto riguarda la stessa pagina prima e dopo JavaScript. Le differenze vanno descritte per contenuto e per segnale tecnico.
Controllare URL e link realmente scansionabili
Google raccomanda elementi `<a>` con `href` verso URL validi. Eventi `onclick`, frammenti usati come routing o link creati soltanto dopo interazioni possono limitare scoperta e comprensione.
Verificare lazy loading e contenuti condizionali
Immagini e testo devono caricarsi quando entrano nel viewport senza richiedere azioni che Google non esegue. Tab, filtri e infinite scroll hanno bisogno di URL o percorsi accessibili quando rappresentano contenuti autonomi.
Analizzare errori, risorse e prestazioni
Console, rete, status, blocchi robots, timeout e bundle mostrano cause di rendering incompleto. Le prestazioni influenzano utenti e capacità operativa, ma non vanno ridotte a un solo punteggio.
Usare strumenti e log con un protocollo
URL Inspection, test live, crawler con rendering, browser e log server forniscono viste diverse. Ogni anomalia deve avere template, condizione, evidenza e test di correzione.
Matrice operativa
| Dimensione | Dato o oggetto | Decisione | Cautela |
|---|---|---|---|
| HTML | Contenuto server | Baseline | View source |
| DOM | Contenuto renderizzato | Parità | Browser/crawler |
| URL | Routing e status | Indicizzabilità | History API |
| Link | a + href | Scoperta | No onclick-only |
| Segnali | Canonical, hreflang, schema | Coerenza | Prima/dopo JS |
| Risorse | JS, API, errori | Completezza | Log e network |
Sequenza di implementazione
1. Inventariare template e modalità di rendering.. La fase va chiusa con un'evidenza accessibile, un owner e un criterio di accettazione; eccezioni e dipendenze devono essere registrate.
2. Campionare URL importanti e casi limite.. La fase va chiusa con un'evidenza accessibile, un owner e un criterio di accettazione; eccezioni e dipendenze devono essere registrate.
3. Confrontare source, DOM e render di Google.. La fase va chiusa con un'evidenza accessibile, un owner e un criterio di accettazione; eccezioni e dipendenze devono essere registrate.
4. Testare link, routing, status e canonical.. La fase va chiusa con un'evidenza accessibile, un owner e un criterio di accettazione; eccezioni e dipendenze devono essere registrate.
5. Verificare lazy loading e contenuti interattivi.. La fase va chiusa con un'evidenza accessibile, un owner e un criterio di accettazione; eccezioni e dipendenze devono essere registrate.
6. Analizzare console, rete e log.. La fase va chiusa con un'evidenza accessibile, un owner e un criterio di accettazione; eccezioni e dipendenze devono essere registrate.
7. Correggere per template e testare regressioni.. La fase va chiusa con un'evidenza accessibile, un owner e un criterio di accettazione; eccezioni e dipendenze devono essere registrate.
8. Monitorare dopo rilasci e framework update.. La fase va chiusa con un'evidenza accessibile, un owner e un criterio di accettazione; eccezioni e dipendenze devono essere registrate.
Come misurare il lavoro
- Template con contenuto assente nell'HTML
- Differenze tra canonical iniziale e renderizzato
- Link privi di href valido
- Errori JS e API per template
- Tempo e successo del rendering
- URL scoperti e indicizzati
Il conteggio delle anomalie va segmentato per template e modalità di rendering: pochi errori su pagine ad alto valore possono pesare più di molte differenze innocue. Il report deve mostrare ciò che è presente nel source, ciò che compare nel DOM, l’eventuale errore di rete e l’effetto osservato su scoperta o indicizzazione, distinguendo riscontro tecnico e possibile conseguenza.
Scenario applicativo
Una SPA mostra categorie e prodotti nel browser, ma l'HTML iniziale contiene soltanto un contenitore vuoto e alcuni link sono pulsanti con `onclick`.
Il progetto introduce rendering server per elementi critici, URL stabili e link reali. L'audit ripete i test su source, DOM, URL Inspection e log.
Criteri di completamento
| Livello | Condizione | Evidenza |
|---|---|---|
| Fondamenta | Perimetro, definizioni e owner approvati | Brief, RACI e fonti |
| Implementazione | Configurazioni, processi o contenuti testati | QA, log o versione |
| Adozione | Le persone previste usano il processo | Dati e osservazione |
| Risultato | Gli indicatori cambiano senza effetti indesiderati | Dashboard e verifica |
| Manutenzione | Esistono trigger e data di revisione | Calendario e backlog |
Errori da evitare
- Assumere che Google non elabori JavaScript.
- Assumere che tutto ciò che vede l'utente sia indicizzabile.
- Usare frammenti per contenuti autonomi.
- Bloccare risorse necessarie al rendering.
- Testare soltanto la homepage.
- Ignorare regressioni dopo i rilasci.
Un campione che rappresenti il catalogo
Chiedi al fornitore quali pagine usano lo stesso modello di impaginazione. Raggruppa le categorie e le schede prodotto; considera a parte il configuratore. Per ogni gruppo scegli una pagina che porta richieste e una con una condizione meno comune, come un prodotto ritirato. Elenca gli indirizzi effettivamente provati nel report, senza estendere automaticamente l’esito a tutto il sito.
La segnalazione da consegnare allo sviluppatore
L’infografica raccoglie i campi di una scheda difetto. Per ogni problema compila questi campi:
Scarica l’infografica (PNG ad alta risoluzione)
Incorpora l’infografica nel tuo sito
Puoi ripubblicare l’infografica usando questo codice, con il collegamento alla guida originale.
- Pagina e versione. Indica l’URL e la versione del sito provata.
- Condizione di prova. Descrivi il percorso e le azioni eseguite.
- Risultato atteso e osservato. Riporta la differenza e allega la prova.
- Estensione del difetto. Elenca le pagine coinvolte e il modello comune.
- Prova dopo la correzione. Ripeti il caso e controlla una pagina senza il difetto.
Per la prova servono l’orario e il browser usato. Annota lo stato del consenso quando può influire sul caricamento. Le schermate aiutano a vedere il sintomo; una risposta di rete o un estratto del documento permette al tecnico di cercarne la causa. Prima di condividere i file, togli i dati di sessione e le informazioni dei clienti.
Il prodotto ritirato che continua a rispondere
Nel catalogo di un fornitore di trasmissioni, una vecchia scheda potrebbe mostrare un messaggio di prodotto non disponibile pur restituendo una risposta HTTP di successo. Chiedi quale comportamento è previsto per quell’indirizzo. Un ricambio ancora richiesto può avere una pagina utile; un indirizzo inesistente ha un trattamento diverso. L’audit deve descrivere il caso prima di proporre un codice di risposta o un reindirizzamento.
Prova un indirizzo certamente inesistente e confrontalo con quello del prodotto ritirato. Segui poi il collegamento dalla categoria, dove potrebbe essere rimasto un riferimento al modello vecchio. Se il difetto riguarda lo stesso modello di pagina, il fornitore deve cercare gli altri indirizzi interessati prima di correggere soltanto quello segnalato.
L’ordine degli interventi
Metti davanti i difetti che impediscono di raggiungere o leggere le pagine commerciali. Descrivi quante pagine hai effettivamente trovato coinvolte e quali famiglie di prodotto riguardano. Un avviso della console senza un effetto riprodotto non ha automaticamente la stessa urgenza di un catalogo che non si apre.
Alla consegna della correzione ripeti la condizione iniziale sulla nuova versione. Prova una pagina dello stesso gruppo che prima funzionava, perché una modifica condivisa può introdurre un altro errore. Tieni distinta questa chiusura tecnica dal successivo controllo dell’indicizzazione. Il ticket può risultare corretto mentre i dati del motore non riflettono ancora il nuovo sito.
Domande frequenti
Google esegue JavaScript?
Sì, ma i siti JavaScript richiedono più controlli e possono presentare problemi di rendering, routing e segnali.
Serve sempre il server-side rendering?
No. Serve garantire accessibilità, URL e segnali corretti; la soluzione dipende dall'architettura.
Come controllare ciò che Google vede?
Con URL Inspection, test live, HTML renderizzato, crawler e log, ricordando che ogni strumento copre una parte.
Che cosa fare
Scegli una scheda prodotto che porta richieste. Salva la risposta HTML e confrontala con il documento dopo JavaScript, annotando la condizione di prova per ripetere eventuali differenze.
Fonti e riferimenti
- Google Search Central — JavaScript SEO basics — https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
- Google Search Central — Fix JavaScript search problems — https://developers.google.com/search/docs/crawling-indexing/javascript/fix-search-javascript
- Chrome for Developers — Lighthouse performance scoring — https://developer.chrome.com/docs/lighthouse/performance/performance-scoring
Approfondisci il servizio: SEO tecnica.