Redazione: 4SYSTEMPubblicato il Aggiornato il
9 lettura minima
SEO JavaScript consiste nel verificare che i contenuti utili e i collegamenti su una pagina rimangano accessibili a Google, non solo visibili nel browser. Per verificarlo, confronta la risposta HTML dal server, il DOM dopo l'esecuzione e HTML reso nell'ispezione URL. Questo confronto consente di individuare un difetto di accesso, una dipendenza dai clic o un errore di rendering prima di modificare l'architettura.
Google sa come eseguire JavaScript, ma ciò non garantisce la presenza di ciascun contenuto nel rendering né la sua indicizzazione. Controlla caratteristiche, destinazioni dei link e linee guida per l'indicizzazione su un singolo URL.
Leggi tre documenti, senza confondere i loro ruoli
La risposta HTML è il documento inviato dal server. Puoi visualizzarlo con "Mostra codice sorgente" o nella risposta alla query principale. Il DOM è la struttura attuale della pagina, osservabile nella scheda Elementi degli strumenti di sviluppo. JavaScript può aggiungere, eliminare o sostituire contenuti.
Google distingue tra esplorazione, rendering e indicizzazione. Può eseguire JavaScript con Chromium quando le sue risorse lo consentono; il risultato quindi non è necessariamente immediato.[28] Una pagina contenente solo una struttura vuota nella risposta iniziale dipende maggiormente da questa esecuzione rispetto a una pagina il cui testo è già stato consegnato.
Il tuo browser non costituisce prova del rendering Google: può trarre vantaggio da una sessione, archiviazione locale o interazione. Il documento decisivo per questo controllo rimane il HTML reso nello strumento Google. Il contenuto mancante nell'HTML reso utilizzato per l'indicizzazione non può essere indicizzato come contenuto della pagina.[28] La sua assenza durante un test live non dimostra tuttavia la sua assenza dalla versione indicizzata, perché i due stati possono differire.[23]
Infine, distinguere tra leggibilità e indicizzazione. Vedere il testo in questo rendering conferma la sua presenza al momento del test, non la sua inclusione nell'indice.
Preparare un controllo riproducibile SEO JavaScript
Prima di aprire Search Console, definisci esattamente cosa desideri leggere. “La scheda è esposta” è troppo vago: ricorda il nome del prodotto, un tratto distintivo e il collegamento ad un'altra scheda.
Riporta nella tua dichiarazione:
- l'URL completo, il modello interessato e la versione distribuita;
- il testo previsto, la sua posizione e la sua origine: HTML o API;
- gli URL degli script e la richiesta che ne fornisce le caratteristiche;
- le interazioni necessarie, l'esistenza di una sessione e le regole di accesso;
- stato HTTP, direttive
robotse la canonicità dichiarata.
L'ordine di controllo qui proposto è: accesso URL, risposta iniziale, direttive di indicizzazione, risorse, inserimento contenuto, collegamenti, quindi ispezione Google.
Per prima cosa apri l'URL direttamente in una nuova sessione, senza fare clic o scorrere. Quindi osserva separatamente le interazioni che modificano il contenuto. Mantieni ogni stato con la sua data e il suo contesto; altrimenti confronterai situazioni diverse senza saperlo.
Confronta un modulo: la tabella diagnostica completata
Prendiamo un catalogo interamente fittizio, senza riferimento a un cliente di 4SYSTEM. Il foglio /catalogue/lampe-atelier fornisce il titolo come HTML. Le caratteristiche provengono da un API richiamato all'apertura della scheda “Caratteristiche”. Le mappe di navigazione utilizzano i pulsanti con onclick.
La tabella è un modello completato per questo scenario. La colonna ispezione imposta l'ispezione da effettuare; non riporta alcun test reale. Il DOM descritto corrisponde allo stato dopo l'apertura della scheda.
| Elemento selezionato | HTML sorgente | DOM del browser | Rapporto di ispezione da verificare | Decisione |
|---|---|---|---|---|
| Titolo “Lampada da officina” | Titolo fornito dal server | Titolo mantenuto | Verificare la presenza dello stesso titolo | Convalida la sua presenza dopo aver letto il rendering |
| Caratteristica “Materiale: acciaio” | Testo non fornito | Testo aggiunto dopo il clic e la risposta API | Cerca questo testo senza aprire la scheda | Se assente, rimuove la dipendenza dal clic |
| Destinazione “Lampada regolabile” | Pulsante con onclick, senza href | Stesso pulsante | Verificare la presenza di un collegamento reale | Fornire un ancoraggio al modulo |
Il titolo può essere leggibile senza che sia leggibile l'intero file. Riutilizzare gli stessi elementi in tutte e tre le visualizzazioni. Dopo la correzione, archivia un nuovo controllo da una nuova sessione, senza eliminare l'osservazione iniziale.
Sostituisci le destinazioni nascoste dietro onclick
Una scheda che apre un file con un evento JavaScript non è automaticamente un collegamento sfruttabile. Google indica che non è possibile estrarre in modo affidabile gli URL di ancoraggio senza href né altri elementi che simulano collegamenti tramite eventi di script.[17]
Nel catalogo fittizio, sostituisci la navigazione con un articolo reale: <a href="/catalogue/lampe-orientable">Lampe orientable</a>. Lo script può ancora migliorare la transizione, ma la destinazione esiste indipendentemente dal gestore dei clic. Un pulsante mantiene la sua posizione per un'azione, come l'apertura di un pannello, anziché per puntare a un'altra pagina.
Verificare tre punti: la presenza dell'ancora nel HTML renderizzato, una destinazione reale e un'etichetta comprensibile. Poi si apre direttamente la destinazione: il server deve fornire il modulo previsto, non solo una busta di domanda che funziona dopo la navigazione interna.
Anche i collegamenti aggiunti da JavaScript sono utilizzabili se rispettano questo markup.[17] Correggere il componente di navigazione, quindi controllarne le variazioni nelle categorie e nei consigli.
Isola la dipendenza da API e l'attivazione
Inizia con la query che fornisce il testo mancante. Nella scheda Rete, prendi nota del suo trigger, del suo stato e del contenuto della risposta. Non basta una risposta JSON corretta: identifica anche il passaggio che trasforma questi dati in testo nel DOM.
Se la query prevede un clic, suggerire di caricare le caratteristiche essenziali non appena si apre il modulo. Se esce automaticamente ma fallisce, esamina l'accesso API, i controlli dell'origine, i cookie richiesti e gli errori di script. Non rendere pubblico un API privato per risolvere un problema SEO: fornisci solo i dati destinati al record pubblico.
Google non esegue il rendering di JavaScript di file o pagine bloccate.[28] Controlla le restrizioni di esplorazione per risorse utili. L'ispezione dal vivo richiede anche una pagina accessibile su Internet senza connessione.[23]
Non impostare una presunta scadenza universale per il rendering. Per isolare una dipendenza, testa una variante che fornisca direttamente il testo essenziale, quindi confronta il rendering. Questo metodo distingue un problema di acquisizione dati da un problema di inserimento.
Interroga Search Console senza sovrainterpretare il test
L'ispezione URL presenta innanzitutto le informazioni sulla versione nota di Google, non lo stato corrente della distribuzione.[23] Prendere nota della data di scansione visualizzata prima di interpretare una differenza. Quindi esegui il test dal vivo sullo stesso identico URL.
Visualizza i dettagli della pagina testata, il suo rendering HTML e le risorse segnalate. Trova quindi il testo distintivo conservato href previsto. La cattura visiva aiuta a comprendere lo stato della pagina, ma non sostituisce questa ricerca: un pulsante visibile può rimanere senza collegamento.
Controlla anche la risposta originale. Se contiene noindex sebbene il modulo debba essere indicizzabile, non contare su JavaScript per rimuovere questa direttiva: Google potrebbe interrompere il rendering quando la incontra.[28] Correggere la direttiva alla sua origine, senza rimuovere le legittime esclusioni da altre pagine.
Un test diretto valido non garantisce l'indicizzazione. Inoltre, non prevede la canonicità che Google manterrà.[23] Se il contenuto viene visualizzato correttamente ma la pagina rimane mancante, continuare con diagnosi di una pagina non indicizzata invece di trattare JavaScript come unica causa.
Scegli la patch e definisci la sua convalida
Decidere in base al divario osservato. Contenuto assente dalla risposta iniziale ma presente nel rendering Google: la dipendenza da JavaScript esiste, senza difetti di leggibilità dimostrati. Contenuto presente solo dopo il clic: modifica il trigger. Contenuto perso dopo l'esecuzione: esamina il componente che sostituisce HTML. Collegamenti senza destinazione: correggere il markup.
Il rendering o prerendering del server può fornire il testo non appena viene ricevuta la risposta HTML e ridurre la dipendenza dal rendering JavaScript; non tutti i robot sanno eseguire quest'ultima operazione.[28] Questa è un'opzione architetturale, non un obbligo o una promessa di indicizzazione. In particolare, valutare la disponibilità dei dati lato server e il rischio di discrepanza tra le versioni.
Per chiudere il ticket, registrare la modifica, la versione testata e i documenti di controllo: risposta iniziale, DOM senza interazione, test diretto HTML e collegamento verificato. Il criterio proposto è concreto: il contenuto atteso e la sua destinazione sono presenti senza alcun intervento preventivo, con direttive coerenti.
Infine controlla un altro foglio utilizzando lo stesso componente. Tieni traccia separata dello stato di indicizzazione; la validazione tecnica della patch non ne è la prova.
Domande frequenti
Il contenuto di un componente con shadow DOM è invisibile?
Non necessariamente. Google supporta i componenti web e riunisce i contenuti shadow DOM e light DOM durante il rendering.[28] Per un modulo le cui caratteristiche sono incapsulate, trova il testo nel rendering di ispezione HTML. La semplice presenza del componente nel codice sorgente non convalida la presenza dei suoi dati.
Perché un URL reindirizzato sembra superare il test?
Il test in tempo reale tiene traccia dei reindirizzamenti, ma il suo rapporto non indica che sia stato seguito un reindirizzamento o che l'URL finale sia stato testato.[23] Quindi controlla la catena di reindirizzamento negli strumenti di rete e controlla separatamente la destinazione prevista. Altrimenti potresti convalidare il contenuto di una pagina diversa dal record che stai tentando di correggere.
Come verificare se Google sta utilizzando un vecchio script?
Google specifica che il suo servizio di rendering potrebbe utilizzare vecchie risorse JavaScript o CSS a causa della sua cache.[28] Confronta i file a cui fa riferimento la pagina con quelli nella distribuzione, quindi controlla la loro versione negli elementi di test disponibili. Una strategia relativa ai nomi di file con versione aiuta con la diagnosi, senza comportare di per sé un aggiornamento.
Conclusione: aprire un ticket verificabile
Inizia con un profilo rappresentativo e contenuti distintivi. Completa il confronto, correggi la prima discrepanza riscontrata, quindi ripeti il test senza interazione. Fornisci allo sviluppatore osservazioni e prove, non solo uno screenshot. Per inquadrare la diagnosi e le correzioni consultare il servizi web e SEO di 4SYSTEM e presenta il tuo URL con questa dichiarazione.
Fonti
- SEO Link Best Practices for Google | Google Search Central | Documentation | Google for Developers (accesso 2026-10-08)
- URL Inspection tool - Search Console Help (accesso 2026-10-08)
- Understand JavaScript SEO Basics | Google Search Central | Documentation | Google for Developers (accesso 2026-10-08)