Shopify y Vercel están reconstruyendo Hydrogen como una base abierta y agnóstica al runtime. Hydroge…
La AEO vive en la capa de frontend, no en el equipo de SEO
Webflow nombró la AEO, bien. Con eso, la pregunta se desplaza: no "si", sino "qué capa del stack carga con el peso". Mi opinión es esta: la mayoría de las palancas operativas no están en el equipo de contenido y no están en la herramienta de SEO. Están en la capa de frontend.
Los motores de respuesta, ChatGPT, Perplexity, Gemini, Google AI Overviews, Claude, leen las páginas de forma distinta a los bots clásicos de Google. Hacen fetch más rápido, parsean de forma más estructural y ponderan más alto la consistencia de schema y de entidades. Quien intente ganar o perder visibilidad dentro de las respuestas de IA lo decide a través de los patrones de hidratación, las rutas de renderizado de schema y los grafos de entidades multi-locale. Tres palancas, tres argumentos de arquitectura.
1. Schema.org se renderiza de forma determinista, o deriva página a página
Los motores de respuesta leen el marcado de schema (Article, Product, Organization, FAQPage) antes que el DOM visual. Ese es el momento en que los crawlers deciden si tu entidad entra siquiera en el modelo.
El problema técnico: en configuraciones monolíticas, el schema a menudo se ensambla por fragmento del page-builder. Un editor de marketing coloca un hero, un módulo de FAQ, una caja de producto, y cada elemento trae consigo su propio JSON-LD. Tres páginas sobre el mismo producto producen tres variantes de schema. El crawler no ve un grafo de entidades coherente, solo fragmentos.
Enfoque de la capa de frontend: la salida de schema está ligada a los resolvers de contenido, no a los fragmentos del page-builder. Una entidad Product tiene exactamente una definición de schema que se renderiza a partir del modelo de contenido canónico. El editor añade el módulo; la capa de schema se mantiene consistente. Las configuraciones Composable y de FMP tienen aquí una ventaja estructural, porque la separación resolver-de-contenido ↔ vista ya está en su sitio.
En concreto en el renderizado: emite el JSON-LD desde el <head> de la plantilla de layout, no desde la salida de los slots de bloque. Quien extraiga el JSON-LD mediante llamadas a useHead() del lado del cliente desde bloques hidratados se arriesga a que los crawlers de IA, con latencia de corte, no vean la definición en absoluto, ver la palanca 2.
2. Primer render significativo por debajo de 1,0 segundo para los crawlers de IA
Los bots clásicos de SEO tienen presupuestos de fetch generosos. Googlebot espera, reintenta, es tolerante. Los crawlers de IA no. El fetcher de Perplexity da aproximadamente 1,5 segundos en nuestras pruebas internas, y luego trunca el body. La superficie de IA de Bing es igual de ajustada. El crawler de ChatGPT hace fetch en dos etapas (HTML más una segunda pasada), pero pondera mucho lo que era visible en la primera pasada.
Eso funciona directamente en contra de los patrones de hidratación que se celebran por los Core Web Vitals:
- Hidratación selectiva / islands: buena para el TTI, mala para la cobertura de IA. Si tu contenido principal solo aparece tras la hidratación del cliente, los crawlers de IA ven el contenedor vacío.
- Secciones con lazy-load: la misma historia. El contenido below-the-fold que solo se hidrata vía IntersectionObserver nunca cae dentro del presupuesto de render de la IA.
- Streaming SSR sin fallback `<noscript>`: arriesgado. Los crawlers de IA ejecutan JavaScript de forma inconsistente.
Respuesta de la capa de frontend: server-render-first como opción por defecto por cada ruta relevante para AEO. Si quieres que el contenido caiga en las respuestas de IA, renderízalo en la respuesta HTML inicial. Punto. La hidratación selectiva es un ajuste de rendimiento después de eso.
Bloque de código práctico en un stack composable (Nuxt 3 / Vue 3, esbozo de patrón):
// pages/article/[slug].vue
defineRouteRules({ ssr: true, isr: 60 })
// Server renders deterministically, ISR caches 60s.
// No client-only wrappers around the article body. No v-if bridges.En un stack headless clásico con Hydrogen o similar, eso a menudo no basta, el server-first tiene que llegar también a las llamadas de la capa de contenido, de lo contrario el servidor renderiza el DOM pero sin los datos.
3. Consistencia de entidades entre locales y dominios
Las configuraciones multimarca, multimercado y multi-locale producen deriva de AEO cuando cada locale tiene su propia ruta de definición de schema. "Acme Brand DE" y "Acme Brand UK" son tratadas por el crawler como dos entidades Organization diferentes si las propiedades sameAs, las URL de logo y los anclajes de sujeto no son coherentes. Eso diluye la señal de entidad y te cuesta probabilidad de mención dentro de las respuestas de IA.
La capa de frontend como fuente única de verdad para el renderizado del grafo de entidades significa, operativamente:
- Una definición central de entidad por marca, con las variantes de locale como propiedades (
@language,inLanguage) sameAscon enlaces cruzados entre todos los dominios de locale- Hash del asset de logo idéntico en todos los locales
Organizationse renderiza por locale desde el mismo resolver, no desde entradas de CMS por locale
Eso es difícil en la configuración clásica de un WCMS por locale. En una configuración de FMP con una capa de entidades central, es configuración.
¿Quién es dueño de esto en el organigrama?
Las palancas 1, 2 y 3 están todas por delante de la capa a la que tiene acceso el equipo clásico de SEO. La salida de schema es lógica de renderizado. El primer render significativo es arquitectura de frontend. La consistencia de entidades es modelado de contenido × ruta de renderizado.
Webflow nombró la AEO como categoría de producto, ese es el gancho de la noticia. Contentful lanzó "Skills" como agente de IA para desarrolladores, un movimiento adyacente. Los proveedores de primer nivel reconocen todos el mismo cambio: la visibilidad en respuestas de IA es un tema del stack, no un tema de herramienta de marketing.
Tres próximos pasos concretos para CTO y responsables de frontend que quieran abordar esto en los próximos 90 días:
- Auditoría de renderizado de schema: ¿qué definiciones de schema se renderizan desde el
<head>de la plantilla de layout y cuáles desde bloques hidratados? Estas últimas son el primer riesgo. - Test de first-byte de crawler de IA: ejecuta un test sintético contra los fetchers de Perplexity, Bing AI y ChatGPT (al menos contra los user-agents documentados). Observa qué cae en el body dentro de la ventana del primer 1,0 segundo.
- Inventario del grafo de entidades: ¿qué
Organization,Brand,Productse renderizan por locale desde resolvers separados? ¿Cuáles desde uno compartido?
Quien ejecute estas tres auditorías con rigor habrá visto la mayor parte de la palanca de AEO, y notará rápidamente si la capa de plataforma fija los defaults correctos o lucha contra ellos.
Lecturas adicionales:
- Agentic Frontend Management Platform , la capa de plataforma detrás de las tres palancas.
- Composable / Headless Frontend , el desacoplamiento como precondición para un renderizado de schema determinista.
- Performance & Core Web Vitals , los defaults server-first que respaldan la palanca 2.
- Answer Engine Optimisation as a Product Category for Marketing Teams , el post previo con la lente de marketing.
- Why GEO Will Decide Brand Visibility in 2026 , el marco estratégico, ahora con profundidad de arquitectura añadida.
Relacionado: SEO and GEO with AI.