--- title: "blog/post-single" canonical_url: "https://www.laioutr.com/it/blog/aeo-frontend-layer-schema-render-budget-2026" locale: it --- ![Hero tech en](https://eu-west-2.graphassets.com/cmii2mlqi0dux06l5543v7nkc/cmpwcvzmx9qcc07l4vibto82q) # L'AEO vive nel frontend layer, non nel team SEO Indice 1. 1.1. Schema.org renderizza in modo deterministico, oppure va alla deriva pagina per pagina 2. 2.2. First meaningful render sotto 1,0 secondo per i crawler AI 3. [3.3. Coerenza delle entità tra locale e domini](#3-coerenza-delle-entit-tra-locale-e-domini) 4. 4.Chi possiede tutto questo nell'organigramma? 1. 1.1. Schema.org renderizza in modo deterministico, oppure va alla deriva pagina per pagina 2. 2.2. First meaningful render sotto 1,0 secondo per i crawler AI 3. [3.3. Coerenza delle entità tra locale e domini](#3-coerenza-delle-entit-tra-locale-e-domini) 4. 4.Chi possiede tutto questo nell'organigramma? Webflow ha dato un nome all'AEO, bene. Con questo, la domanda si sposta: non "se", ma "quale layer dello stack regge il carico". La mia opinione è questa: la maggior parte delle leve operative non sta nel team dei contenuti e non sta nel tool SEO. Stanno nel frontend layer. Gli answer engine, ChatGPT, Perplexity, Gemini, Google AI Overviews, Claude, leggono le pagine in modo diverso rispetto ai classici bot di Google. Recuperano più velocemente, analizzano in modo più strutturale e pesano di più lo schema e la coerenza delle entità. Chiunque provi a vincere o perdere visibilità dentro le risposte AI lo decide tramite pattern di hydration, percorsi di rendering dello schema e grafi di entità multi-locale. Tre leve, tre argomenti di architettura. ## 1. Schema.org renderizza in modo deterministico, oppure va alla deriva pagina per pagina Gli answer engine leggono il markup dello schema (`Article`, `Product`, `Organization`, `FAQPage`) **prima** del DOM visivo. È il momento in cui i crawler decidono se la tua entità entra o meno nel modello. Il problema tecnico: nelle configurazioni monolitiche, lo schema viene spesso assemblato per singolo snippet del page-builder. Un editor di marketing inserisce un hero, un modulo FAQ, un box prodotto, e ogni elemento porta con sé il proprio JSON-LD. Tre pagine sullo stesso prodotto producono tre varianti di schema. Il crawler non vede alcun grafo di entità coerente, solo frammenti. Approccio a livello frontend: l'output dello schema è legato ai content resolver, non agli snippet del page-builder. Un'entità `Product` ha esattamente una definizione di schema che renderizza dal modello di contenuto canonico. L'editor aggiunge il modulo; il layer dello schema resta coerente. Le configurazioni composable e FMP hanno qui un vantaggio strutturale, perché la separazione content-resolver ↔ view è già in essere. In concreto in fase di render: emetti il JSON-LD dal template di layout ``, non dall'output del block-slot. Chiunque recuperi il JSON-LD tramite chiamate lato client `useHead()` da blocchi idratati rischia che i crawler AI con latenza di cutoff non vedano affatto la definizione, vedi leva 2. ## 2. First meaningful render sotto 1,0 secondo per i crawler AI I classici bot SEO hanno budget di fetch generosi. Googlebot aspetta, riprova, è tollerante. I crawler AI non lo sono. Il fetcher di Perplexity concede circa 1,5 secondi nei nostri test interni, poi tronca il body. La superficie AI di Bing è altrettanto ristretta. Il crawler di ChatGPT recupera in due fasi (HTML più un secondo passaggio), ma pesa fortemente ciò che era visibile nel primo passaggio. Questo va direttamente contro i pattern di hydration che vengono celebrati per i Core Web Vitals: - **Hydration selettiva / islands**: buona per il TTI, dannosa per la copertura AI. Se il tuo contenuto principale compare solo dopo l'hydration lato client, i crawler AI vedono il contenitore vuoto. - **Sezioni caricate in lazy loading**: stessa storia. Il contenuto below-the-fold che si idrata solo tramite IntersectionObserver non rientra mai nel render budget dell'AI. - **Streaming SSR senza fallback \`\