SEO JavaScript: assicurati che i link sopravvivano al rendering

Google renderizza il JavaScript con un Chromium evergreen. Il problema raramente è il rendering in sé. Sono i link che non diventano mai ancoraggi e le pagine che dipendono da uno stato che il crawler non possiede.

Team di ricerca ArchiLinks · Aggiornato 2026-10-29

Un ponte che collega fondamenta in pietra a strutture in vetro che rappresentano la sopravvivenza dei link

Cosa vede un crawler

Googlebot utilizza un Chromium evergreen dal maggio 2019. Questo ha risolto la questione sulla sua capacità di eseguire JavaScript moderno.

I rischi pratici sono più antichi: il rendering avviene dopo il crawling e può essere ritardato, i contenuti dietro clic o accessi non appaiono mai e un link creato da un gestore onclick su un div non è un link. Prima di verificare i backlink sulle pagine del sito che hai recentemente migrato a un front-end React, conferma che quelle pagine mostrino i loro contenuti nella risposta grezza o nell'HTML renderizzato.

SSR, SSG, CSR: cosa cambia per i link

Approccio	Contenuti nella prima risposta	Link interni come ancoraggi	Adatto per
SSR (Next.js, Nuxt)	Sì	Sì, se usi veri ancoraggi	Pagine pubbliche con dati in continua evoluzione
SSG o prerendering	Sì	Sì	Documentazione, blog, pagine di marketing
App a pagina singola CSR	No, guscio vuoto	Solo dopo il rendering	Dashboard dietro un accesso
Ibrido (home SSR, app CSR)	Per route	Per route	La maggior parte dei prodotti con una parte pubblica

Test uno: HTML grezzo contro HTML renderizzato

Se i link chiave appaiono nella prima risposta, la questione è chiusa. In caso contrario, confronta con un rendering headless.

bash

# raw response: are the links there?
curl -s https://new-shop.com/guides/ | grep -o '<a [^>]*href="[^"]*"' | head -20

# rendered DOM with headless Chrome
chrome --headless --dump-dom https://new-shop.com/guides/ | grep -c '<a '

Un giardiniere che ispeziona le radici degli alberi che rappresenta i controlli di salute dei backlink esterni

Dove entrano in gioco i link esterni

Un bug di rendering nasconde i tuoi contenuti. Non cancella i link che altri siti ti hanno già fornito.

Dopo una migrazione a Next.js, Vite o un CMS headless, esegui toppages per l'host e testa i 20 URL più linkati per stato, canonical e contenuto visibile. Fallo subito. Se una pagina con 40 domini linkanti restituisce un guscio vuoto o un 404 lato client, risolvilo prima di qualsiasi altra cosa, perché è lì che atterra la tua autorità. La pagina sull'equità tra link interni ed esterni mostra come confrontare quell'elenco con i tuoi link interni, e la checklist di migrazione inserisce il test in un piano di lancio.

I framework contano meno della disciplina. Express con un motore di template, un tema WordPress e un Next.js app router possono tutti servire link indicizzabili. Ognuno può anche fallire se un team rilascia ancoraggi che esistono solo dopo un clic.

Checklist link e rendering

Navigazione e paginazione usano <a href>, non gestori di clic su altri elementi.
Ogni route restituisce un vero codice di stato. Le schermate soft 404 devono restituire 404.
Un noindex o un canonical iniettati da JavaScript corrispondono a quello nella risposta del server.
I contenuti di fallback nella prima risposta sono la pagina reale, non uno spinner che Google potrebbe indicizzare.
Il codice di autenticazione non reindirizza i crawler sulle route pubbliche.
I file CSS e JS necessari per il rendering non sono bloccati in robots.txt.
Il caricamento lazy usa IntersectionObserver o attributi di caricamento nativi, non eventi di scroll.

Leggere le evidenze di Search Console

Search Console risponde alla maggior parte delle domande sul rendering se fai la domanda giusta. Usa Ispezione URL, poi Visualizza pagina indicizzata.

Confronta tre cose: l'HTML recuperato da Google, la schermata e le risorse della pagina che non sono state caricate. Una pagina che sembra completa nel tuo browser ma vuota nella schermata è solitamente bloccata da un errore di script o da una risorsa non consentita, e la soluzione risiede nel tuo build, non nei tuoi contenuti.

Ricorda il ritardo. Una modifica che rilasci oggi appare nello strumento di ispezione solo dopo che Google ha nuovamente indicizzato l'URL, il che può richiedere giorni.

Quando vale la pena l'SSR

Pagine pubbliche che devono posizionarsi: sì. Dashboard: no.

Se una route dovrebbe generare traffico organico, servi i contenuti nella prima risposta. Se è dietro un accesso, salta la complessità. Scegli per route e non per progetto, e documenta la decisione in modo che il prossimo sviluppatore non la annulli.

Usa il test dei Risultati Arricchiti e l'Ispezione URL per confrontare l'output renderizzato.
Testa con il test live di Search Console dopo ogni aggiornamento del framework.

Due case su una collina che mostrano il prerendering rispetto al rendering lato client

È necessario il rendering server-side o è sufficiente il prerendering?

Il rendering server-side è opzionale. È un modo per far sì che la prima risposta contenga ciò di cui ha bisogno un crawler. Molti siti pubblici ci arrivano con il prerendering, un build statico o un render server per le pagine che contano, e lasciano le parti con accesso non toccate.

Immagina che le pagine prodotto e la documentazione siano pubbliche, mentre la dashboard è dietro un accesso. Prerendera il primo gruppo. Lascia la dashboard lato client. Le pagine pubbliche così trasportano i loro link nella prima risposta, e la dashboard può rimanere complessa quanto necessario.

Prerendering solo della home page

Il prerendering della home page risolve il primo crawling, ma lascia ogni altra route in attesa del browser. Se la home page linka a pagine di categoria renderizzate lato client, i link su quelle pagine dipendono ancora dal rendering. Controlla ogni template che possiedi, non solo la porta d'ingresso.

Tieni un breve elenco di route pubbliche con il loro metodo di rendering. L'elenco mostrerà le lacune più velocemente di un report di crawling.

Il rendering server-side cambia la visibilità locale

Il rendering server-side può cambiare la velocità con cui appare il primo contenuto, e i lettori lo percepiscono. Non rende una pagina rilevante per una query locale di per sé. Quei segnali provengono dal contenuto della pagina, dai dettagli dell'attività e dai link che puntano ad essa.

Tratta il rendering come il modo in cui quei segnali diventano leggibili a un crawler, e misura i link separatamente con l'API.

App Vite e React che servono un unico guscio

Un build Vite che serve un unico guscio HTML per ogni percorso mette tutto il lavoro sul client. Tale app può ancora posizionarsi per alcune query, ma ogni route pubblica ha bisogno di un piano: prerenderala, renderizzala sul server o accetta la perdita e annotalo.

Prima di verificare i backlink sulle route del sito dopo una ricostruzione, decidi come ogni route pubblica ottiene i suoi contenuti. Altrimenti i dati sui link mostreranno link esterni che atterrano su pagine vuote.

Testare se una route mostra i suoi link

Due test rispondono alla maggior parte delle domande. La risposta grezza mostra cosa ottiene un crawler prima che qualsiasi script venga eseguito. Il DOM renderizzato mostra cosa costruisce un browser dopo. Un link che appare solo nel secondo è ancora un link, ma dipende dal fatto che il rendering vada a buon fine.

Leggere il test live in Search Console

Esegui il test live da Ispezione URL su una route alla volta. Guarda l'HTML renderizzato, poi l'elenco delle risorse che non sono state caricate. Uno script bloccato può rimuovere un intero blocco di navigazione, e la pagina appare sottile senza mostrare errori visibili.

Ripeti il test dopo un aggiornamento del framework, perché un nuovo default può cambiare se i link vengono renderizzati prima o dopo l'esecuzione di uno script. La guida pagine non indicizzate copre cosa fare quando una pagina renderizzata rimane comunque esclusa.

Quando una route si renderizza ma il contenuto è uno spinner

Il fallback nella prima risposta è più importante di quanto la maggior parte dei team si aspetti. Uno spinner o un contenitore vuoto significano che la pagina non trasporta testo per il crawler in quel momento. Metti il titolo, l'introduzione e i link principali nella prima risposta, anche se un elenco dettagliato viene caricato in seguito.

Un fallback che è la pagina reale può rimanere semplice. Il suo unico compito è contenere i contenuti fino all'arrivo del resto.

Migrare un sito client-side senza perdere i suoi link

Elenca le route con link esterni

Esegui toppages per l'host e annota i 50 URL principali. Testa quelle route prima delle modifiche al codice, in modo da sapere cosa deve mantenere la ricostruzione.

Confronta output grezzo e renderizzato

Per ogni route, controlla l'HTML grezzo e il DOM renderizzato nel vecchio e nel nuovo build. Annota eventuali link che esistono in uno ma non nell'altro.

Sostituisci i gestori di clic con ancoraggi

Trasforma la navigazione in veri ancoraggi con un indirizzo corretto. Il lavoro di velocità può aspettare un sprint, mentre un anchor mancante costa alla route il suo percorso nel sito.

Ripeti il test dopo il rilascio

Una settimana dopo il rilascio, esegui il test live sulle stesse route e confronta i risultati con quelli precedenti. Le differenze mostrano dove la ricostruzione ha cambiato l'output.

Codici di stato e redirect in un'app client-side

Un'app a pagina singola mostra spesso una schermata non trovato mentre il server restituisce status 200. Google può trattare tale pagina come un soft 404, e i link esterni che puntano all'URL mancante allora fanno poco per te. La soluzione spetta al server.

Route sconosciute che restituiscono ancora 200

Restituisci un vero 404 dal server per qualsiasi route che non esiste, e mantieni la schermata non trovato nell'app per i visitatori che arrivano tramite una route lato client. Dove esiste una sostituzione, invia un 301.

Controlla alcuni indirizzi inventati sull'host live dopo ogni rilascio. Il codice di risposta è la cosa da leggere, non la pagina che vedi nel browser.

Redirect che avvengono nel browser

Un redirect che si attiva dopo il caricamento della pagina, ad esempio leggendo un parametro URL all'interno di un componente, è una cosa diversa da un redirect del server. Un crawler potrebbe indicizzare la prima risposta prima che il redirect venga eseguito. Dove una route è stata spostata definitivamente, restituisci un 301 dal server e mantieni i parametri che cambiano il contenuto. La ricetta della mappa dei redirect mostra come testare quelle regole.