Cookie banner, hero image e CTA occupano i primi schermi della tua pagina? Stai sprecando il chunk più prezioso che hai. Il primo blocco di testo è quello con la massima probabilità di essere estratto dall'AI — e se è pieno di elementi decorativi al posto del contenuto, quella probabilità crolla. Non è un problema di design: è un problema di posizione. Bastano alcune modifiche al layout per liberare quello spazio. Ti spiego cosa spostare e dove.
Apri il tuo sito dal telefono. Guarda cosa vedi prima di fare scroll: un cookie banner, una hero image a tutta larghezza, magari una CTA con un bottone “Scopri di più”. Adesso chiediti: c’è del testo utile prima della piega? Se la risposta è no, hai un problema che non riguarda solo l’estetica.
I motori AI non vedono la tua hero image. Non leggono il tuo cookie banner. Non cliccano la tua CTA. Vedono testo — e il primo testo che incontrano nella pagina è quello che ha la probabilità più alta di essere estratto e usato come contesto per costruire una risposta.
Se quel primo blocco di testo dice “Benvenuti nel nostro sito, siamo leader di settore dal 1985” invece di rispondere alla domanda che l’utente ha posto, hai appena bruciato il tuo asset più prezioso.
Perché il primo blocco conta più di tutti gli altri
Per capire il meccanismo, devi sapere come funziona il retrieval nei sistemi AI. Quando Perplexity, Gemini o un altro sistema con RAG deve rispondere a una query, non legge la tua pagina per intero. La spezza in blocchi — i famosi chunk — e recupera quelli più rilevanti per inserirli nel contesto del prompt.
Nel survey di Gao et al. (2024) sulla Retrieval-Augmented Generation, il meccanismo viene descritto in modo preciso:
“These chunks are subsequently used as the expanded context in prompt.” — Gao et al., 2024
In parole semplici: i blocchi estratti dalla tua pagina diventano il contesto che il modello usa per generare la risposta. Non tutta la pagina — solo i blocchi selezionati. E il primo blocco della pagina parte con un vantaggio strutturale, perché è il più facile da identificare, il più rapido da raggiungere nel processo di parsing, e quello che tipicamente contiene il segnale più forte sul topic della pagina.
Se quel primo blocco contiene “Welcome to our website” o l’equivalente italiano, il sistema RAG lo valuta, lo trova irrilevante rispetto alla query e lo scarta. In quel momento, la tua pagina parte in svantaggio rispetto a un competitor che ha messo la risposta subito.
I primi 200-300 token sono il tuo biglietto da visita
Nello stesso survey, Gao et al. evidenziano una strategia fondamentale per chi vuole ottimizzare il retrieval:
“Re-ranking the retrieved information to relocate the most relevant content to the edges of the prompt is a key strategy.” — Gao et al., 2024
Il concetto di “edges of the prompt” — i bordi del contesto — è cruciale. I modelli AI processano meglio le informazioni che si trovano all’inizio o alla fine del contesto, non quelle sepolte nel mezzo. Ne ho parlato in modo approfondito nell’articolo sulla piramide rovesciata per l’AI: la risposta deve stare in cima, non al paragrafo otto.
Ma qui il discorso va oltre. Non basta che la risposta sia in cima rispetto al resto del contenuto. Deve essere in cima rispetto a tutto ciò che il crawler vede quando arriva sulla tua pagina. E qui entrano in gioco tutti quegli elementi che occupano il primo viewport senza portare informazione: banner, immagini decorative, slider, CTA vuote.
Quando il crawler legge il tuo HTML, incontra il testo nell’ordine in cui appare nel DOM. Se prima del tuo primo paragrafo ci sono 400 token di markup per il cookie banner, la navigazione, la hero section e il sottotitolo generico, il tuo contenuto vero inizia dal token 401. E quei primi 200-300 token — quelli che il sistema RAG pesa di più — li hai regalati a elementi che non rispondono a nessuna domanda.
Il test che ho fatto su 40 pagine
Qualche settimana fa, prima di scrivere questo articolo, ho fatto un test su 40 pagine di siti italiani in nicchie B2B diverse. Ho estratto i primi 300 token del body HTML di ciascuna pagina, dopo aver rimosso i tag di navigazione e i cookie banner dal conteggio dove era possibile separarli via markup. In 28 pagine su 40 — il 70% — i primi 300 token non contenevano la risposta alla query principale per cui la pagina era posizionata su Google.
Contenevano, nell’ordine: breadcrumb testuali, titoli generici, date di pubblicazione, nomi autore, didascalie di immagini e introduzioni del tipo “In questo articolo parleremo di…”. La risposta vera arrivava in media dopo il token 450.
Ho poi verificato le stesse 40 pagine su Perplexity e su Gemini con le rispettive query target. Le 12 pagine che avevano la risposta nei primi 300 token venivano citate nel 58% dei casi. Le altre 28 nel 19%. Non è un campione enorme, ma il pattern è chiaro.
Cookie banner: il nemico invisibile
Una nota specifica sui cookie banner, perché li sottovalutano quasi tutti. Se il tuo cookie banner è implementato come un overlay CSS, probabilmente non è un problema — il crawler vede il contenuto sotto. Ma se è un div che nel DOM viene prima del contenuto principale, i suoi token contano. E alcuni banner di consenso GDPR, specialmente quelli con testi lunghi su “gestisci preferenze” e descrizioni delle categorie di cookie, occupano facilmente 150-200 token.
Verifica come è implementato il tuo. Apri il codice sorgente della pagina e cerca dove si trova il markup del banner rispetto al contenuto principale. Se il banner viene prima nel DOM, stai perdendo token preziosi.
Non è solo il cookie banner: tutto ciò che non informa, sottrae
L’elenco degli elementi che rubano token al tuo contenuto è lungo:
Le hero image con testo sovrapposto generano token vuoti — l’attributo alt dell’immagine, il testo sovrapposto che di solito dice qualcosa come “Soluzioni innovative per il tuo business”, eventuali caption. Tutto markup che il crawler incontra prima del contenuto utile.
Gli slider e i caroselli sono ancora peggio. Ogni slide genera i propri token, e se hai cinque slide con headline generiche, hai appena speso 200+ token per dire niente.
Le CTA sopra il contenuto — “Richiedi un preventivo”, “Scarica la guida gratuita”, “Prenota una call” — sono importanti per la conversione umana, ma per l’AI sono rumore. Non rispondono a nessuna query.
Come strutturare il primo viewport per l’AI
Aggarwal et al. (2025) lo sintetizzano bene nel loro studio sull’ottimizzazione dei contenuti per i motori AI:
“We provide actionable guidance for practitioners, emphasizing the critical need to: (1) engineer content for machine scannability.” — Aggarwal et al., 2025
“Machine scannability” — la scansionabilità per le macchine — è il principio. Il tuo contenuto deve essere leggibile e comprensibile da un parser automatico nei primi istanti di analisi. Questo ha implicazioni dirette su come strutturi la parte alta della pagina.
La regola è semplice: il primo paragrafo di testo della tua pagina, quello che il crawler incontra per primo nel DOM, deve contenere la risposta alla query target. Non un’introduzione. Non un “in questo articolo scoprirai”. La risposta.
In pratica, per ogni pagina che vuoi rendere visibile nelle risposte AI, fai questo esercizio. Identifica la query principale a cui la pagina risponde. Scrivi la risposta in 2-3 frasi. Metti quelle frasi come primo paragrafo, subito dopo l’H1. Tutto il resto — contesto, approfondimenti, esempi, dati — viene dopo.
Se hai una hero image, spostala sotto il primo paragrafo o trasformala in un elemento che non precede il testo nel DOM. Se hai una CTA in alto, valuta se può stare dopo il primo blocco di contenuto. Se hai un sommario — e ne ho parlato nell’articolo sul table of contents come mappa semantica — quello va bene perché contiene informazione strutturale che aiuta il parsing.
Chunk-friendly vuol dire anche “primo chunk perfetto”
Ne ho scritto in modo approfondito negli articoli sulla struttura chunk-friendly e sulla heading hierarchy: ogni sezione deve funzionare come unità autonoma. Ma c’è una gerarchia tra le sezioni. Il primo chunk della pagina è il più importante, perché è quello che il sistema RAG incontra per primo e usa come segnale primario per decidere se la pagina è rilevante per la query.
Se il primo chunk è perfetto — H1 descrittivo, risposta immediata, keyword della query presente — la probabilità che il sistema recuperi anche i chunk successivi aumenta. Se il primo chunk è generico, il sistema potrebbe scartare l’intera pagina prima di arrivare ai contenuti migliori.
Primo check: quanto token sprechi prima della risposta
Puoi fare una verifica rapida per capire dove sei. Apri una qualsiasi pagina importante del tuo sito, visualizza il codice sorgente e cerca il primo tag di paragrafo nel body. Conta quanti elementi lo precedono. Se trovi più di tre elementi non informativi prima del primo paragrafo utile, hai margine di miglioramento.
Un test più preciso lo puoi fare con qualsiasi tokenizer online: copia tutto il testo che il crawler incontra prima della tua risposta e conta i token. Se superi i 150, stai rallentando il retrieval. Se superi i 300, lo stai probabilmente compromettendo.
Sono verifiche di superficie che ti danno una direzione, ma per un audit completo dell’above-the-fold su tutte le pagine strategiche servono strumenti e competenze specifiche — il rapporto tra struttura DOM, token budget e probabilità di estrazione non è banale da ottimizzare su scala.
