Vai al contenuto
SilktideAiuto

Contenuto leggibile senza JavaScript

Il contenuto principale della tua pagina — i paragrafi, le intestazioni, le tabelle e i prezzi per cui il visitatore è arrivato — deve essere presente nell'HTML che il tuo server restituisce alla prima richiesta. L'arricchimento tramite va benissimo. Il contenuto che compare solo dopo l'esecuzione di JavaScript è invisibile alla maggior parte dei crawler di IA e quindi agli assistenti che citano da essi.

In tutta questa pagina, supponiamo che Fernwood abbia ricostruito il suo sito marketing come una single-page app. Nel browser sembra completo. Visualizza il sorgente della pagina mostra un <div id="root"></div> quasi vuoto. Quel guscio vuoto è ciò che GPTBot, ClaudeBot, PerplexityBot e crawler simili ricevono.

Perché funziona

I motori di ricerca tradizionali hanno in gran parte risolto questo problema: Google renderizza JavaScript prima dell'indicizzazione. I motori di risposta no. I crawler che alimentano ChatGPT, Claude, Perplexity e sistemi simili in genere recuperano la risposta HTML grezza e si fermano: non aspettano che il tuo framework si idrati, non eseguono il tuo bundle e non seguono le route lato client. Il confronto delle scansioni di Silktide (pagina renderizzata vs. HTML grezzo) si basa proprio su questo comportamento; vedi Contenuto senza JavaScript.

La modalità di errore è silenziosa e totale:

  • Una pagina che si posiziona bene in Google può essere completamente assente dalle risposte di IA, perché gli assistenti non hanno mai ricevuto il testo.
  • Ogni altro investimento AEO su quella pagina — dati strutturati, date leggibili dalla macchina, scrittura orientata alla risposta — è inutile se il crawler non vede mai il contenuto descritto da quei segnali.
  • I visitatori umani con script non riusciti o bloccati vedono lo stesso guscio vuoto e il first contentful paint peggiora anche quando gli script alla fine hanno successo.

È un problema di architettura del sito, non di modifica della pagina. Correggere a mano un URL non sistema il template che produce i prossimi cento.

Come verificare cosa vede un crawler

Prima di cambiare qualcosa, conferma il problema. Tre modi, in ordine di efficacia:

  1. Il controllo di Silktide. Contenuto senza JavaScript confronta il testo significativo del corpo della pagina renderizzata con l'HTML grezzo acquisito al momento della scansione. Segnala le pagine in cui il testo grezzo è sia inferiore a circa il 10% del testo renderizzato sia minuscolo in termini assoluti: un vero guscio vuoto, non una pagina che si limita a migliorarsi.
  2. Visualizza il sorgente, non gli Elementi di DevTools. Nel browser, "Visualizza sorgente pagina" mostra ciò che ha inviato il server. Il pannello Elementi mostra il DOM dopo l'esecuzione di JavaScript. Se il testo dell'articolo è negli Elementi ma assente in Visualizza sorgente, i crawler che saltano JS non lo vedranno.
  3. Recupera senza un browser. Da un terminale: curl -sL https://fernwood.example/pricing | head. Oppure usa un browser solo testo. Se la tabella dei prezzi manca da quell'output, manca anche per il crawler.

Verifica anche che al crawler sia effettivamente consentito l'accesso: una risposta HTML perfetta è inutile se robots.txt blocca il crawler di IA, o se un firewall lo blocca di fatto (crawler di IA bloccati in pratica).

Come risolvere

Scegli l'approccio che si adatta al tuo stack. Tutti e tre producono lo stesso risultato: la prima risposta HTML contiene il contenuto.

1. Server-side rendering (SSR)

Il server renderizza ogni pagina in HTML su richiesta; poi JavaScript la idrata per l'interattività. Questo è il percorso predefinito per i framework che già lo supportano:

  • Next.js — usa l'App Router con Server Components, oppure getServerSideProps / getStaticProps nel Pages Router. Non distribuire un root solo client che recupera il contenuto dopo il montaggio.
  • Nuxt — modalità universale/SSR (predefinita), non ssr: false.
  • Remix, SvelteKit, Astro (modalità SSR) ed equivalenti — stessa idea: la risposta del documento include il testo del corpo.

La regola pratica: se è un fetch in useEffect / onMounted a mettere l'articolo sulla pagina, sposta quel recupero dati sul server.

2. Static site generation (SSG)

Precompila le pagine come semplice HTML al momento della pubblicazione. Ideale per contenuti che non cambiano per visitatore — post del blog, documentazione, pagine marketing, prezzi. Astro, Eleventy, Hugo, Next.js output: 'export' e Nuxt generate producono tutti file che un crawler può leggere senza alcun JavaScript.

SSG è di solito la vittoria più economica per siti marketing e di contenuti: nessun costo di rendering per richiesta e l'HTML su disco è esattamente ciò che riceve il crawler.

3. Pre-rendering come ponte

Se non puoi ancora cambiare framework, un servizio di pre-rendering o uno step di build può servire uno snapshot HTML renderizzato ai crawler (e spesso ai visitatori alla prima visita) mentre la SPA continua a funzionare per le sessioni interattive. Consideralo un ponte, non una destinazione: freschezza degli snapshot, invalidazione della cache e route autenticate diventano tutte un onere di manutenzione. Preferisci correggere la modalità di rendering quando puoi.

Le linee guida di Google sulla SEO per JavaScript e Rendering sul Web di web.dev coprono lo stesso spettro — SSR, SSG e miglioramento progressivo — dal lato dei motori di ricerca.

Cosa deve essere presente nel primo HTML

Non ogni pixel. Il contenuto che una citazione riporterebbe:

  • Il corpo dell'articolo o della pagina — intestazioni, paragrafi, elenchi, tabelle.
  • Prezzi, limiti e altri fatti che vuoi che gli assistenti ripetano.
  • Dati strutturati in un blocco <script type="application/ld+json"> nell'HTML iniziale — il JSON-LD iniettato solo dopo l'idratazione è invisibile quanto la prosa.
  • URL canonico, title e meta description in <head>.

JavaScript può comunque gestire menu, personalizzazione, grafici che migliorano una tabella già presente e funzionalità progressive. Il controllo di Silktide è deliberatamente permissivo riguardo all'arricchimento: le pagine che servono il contenuto principale come HTML e stratificano il comportamento sopra passano.

Modelli di errore comuni

  • SPA solo client — Create React App, SPA Vite e configurazioni simili che inviano un guscio vuoto e recuperano le route nel browser. La soluzione è SSR/SSG, non altro codice lato client.
  • Contenuti dietro "Carica altro" o schede che non compaiono mai nell'HTML. Se l'unico modo per raggiungere la sezione tre è un clic che la recupera, i crawler non raggiungono mai la sezione tre. Preferisci URL reali o includi il contenuto nella risposta iniziale.
  • "Funziona in Google, quindi siamo a posto." Il rendering di Googlebot non sostituisce la leggibilità per i crawler di IA. Passare con Google e fallire con GPTBot è una scissione comune e invisibile.
  • Bloccare il crawler e dare la colpa a JavaScript. Verifica sempre accesso dei crawler di IA e raggiungibilità effettiva insieme a questa tecnica.

Come aiuta Silktide

Se Silktide non riesce a leggere il tuo contenuto senza JavaScript, non ci riescono neppure gli assistenti dai quali vuoi essere citato.

Correlati

Ultimo aggiornamento

Questa pagina è stata utile?

Contenuto leggibile senza JavaScript | Guida di Silktide