Hay un detalle de infraestructura que afecta al mismo tiempo a tu posicionamiento, a tus campañas de pago y a cómo los agentes de IA leen los contenidos de tu web.
No dejes de leer aquí por parecer contenido técnico, por favor. Seas de SEO o de PPC. Me lo agradecerás en el futuro. Te lo aseguro. Si no es así, puedes dejar un comentario y llamarme algo feo. Además, abajo os dejo un consejo sobre Google-AdsBot para la gente de PPC.
Hace una semana escribí sobre agentes que no pueden completar un formulario porque depende de JavaScript. Aquello era un síntoma de la nueva infraestructura que definirá Internet en 2027. Esto que os cuento aquí es la causa.
En la mayoría de proyectos que he auditado, el equipo de SEO, el de paid media y el de desarrollo no han hablado entre sí de este tema ni una sola vez. Y puede ser por varias razones:
No saben que existe el problema.
Lo ven lejano.
Consideran que es problema de otro (esta es la más común y más peligrosa de todas).
El “pequeño” detalle del que hablo es el renderizado: cómo la página se dibuja a nivel técnico, qué necesidades y dependencias tiene para lograrlo y la capacidad de agentes y bots para leerlo.
Un sitio basado en Client-Side Rendering puro (CSR para los amigos) (React o Vue sin configuración de servidor) entrega a quien se lo pida algo parecido a este HTML:
<div id=”root”></div>
Y se queda así de pichi. ¿Tú ves contenido ahí? No, ¿verdad? Pues el agente tampoco.
El resto lo pinta JavaScript en el cliente. Si el bot no ejecuta ese JavaScript, o lo ejecuta con retraso como hace Google con su rendering budget, el contenido que intenta indexar es prácticamente una cáscara vacía.
Google sí ejecuta Javasript, pero no lo hace simultáneamente con el HTML crudo: hay una cola de renderizado. Para páginas de menor autoridad o sitios con miles de URLs, esa cola puede tardar días. Mientras esperas, Google indexa lo que tiene: el cascarón vacío.
He visto proyectos de e-commerce donde las páginas de producto rankeaban con título y H1, pero sin descripción, especificaciones técnicas ni reseñas. Todo eso vivía en componentes que el crawler había visto sin renderizar. El equipo pensaba que había un problema de contenido, pero el problema estaba en cuándo llegaba ese contenido al bot.
Esto no es solo cosa de e-commerce. Pasa cada vez más en sitios de contenido montados sobre un headless CMS Contentful, Sanity, Strapi, Storyblok, que ahora están muy de moda por la flexibilidad que dan a marketing (me encantan, ojo, pero hay que saber manejarlo).
TL;DR de un par de párrafos: el framework puede tener SSR y, aun así, el contenido del CMS llegar solo en el navegador. El bot ve un cascarón.
El framework Next.js, Nuxt sí hace SSR por defecto (luego te cuento qué es eso del SSR: recuerda, no dejes de leer), así que el equipo asume que está a salvo. El fallo suele estar en el detalle: si el componente que trae el contenido desde la API del CMS lleva un ’use client’ en Next.js o hace el fetch dentro de un onMounted en Nuxt o Vue, esa llamada se ejecuta solo en el navegador. El HTML que sirve el servidor sigue siendo un cascarón para ese bloque, aunque el resto de la página esté perfectamente renderizada. Tener SSR configurado y que tu contenido llegue en el HTML inicial no son la misma frase, y auditar uno sin comprobar el otro es el error que más veces me he encontrado en migraciones a headless en 2026.
(Fin del desvío técnico. Si te lo has saltado, vuelve al TL;DR de arriba y sigue.)
Esto no es algo nuevo y es algo que todo SEO debe comprobar si hace los deberes. Lo que sí ha cambiado es que ahora afecta a tres actores distintos de forma simultánea: humanos, bots y, sí, agentes.
Algunos conceptos básicos en cuanto a estrategias de rendering. No te preocupes, te lo explico en sencillo (nota para los más técnicos: sí, lo he simplificado: quiero que se entienda bien):
SSR (Server-Side Rendering) genera el HTML completo en el servidor antes de enviarlo al navegador. El crawler recibe un documento con contenido real desde el primer byte. Limpio, indexable, sin dependencias del cliente. Esto es la perfección para SEO y PPC, aunque no siempre es lo ideal en cuanto a usabilidad (aunque eso es otro debate diferente).
CSR (Client-Side Rendering) envía el HTML mínimo y delega la construcción de la página al cliente. El crawler ve lo que llega antes del Javascript: en muchos frameworks modernos, prácticamente nada.
ISR (Incremental Static Regeneration, nativa de Next.js) es el punto medio más interesante de la terna. Genera páginas estáticas con controles de revalidación: va cargando de manera progresiva con peticiones en segundo plano lanzadas mediante temporizadores o tras la interacción del usuario. Para SEO es casi casi como usar Server-Side Rendering con un coste de servidor más controlado. Sin embargo, no sirve para contenido que cambia en tiempo real, pero para fichas de producto o landing pages estables es la opción más equilibrada del stack actual.
La diferencia a la hora de auditar es clara. Con SSR, el HTML que recibe el crawler tiene el mismo contenido que ve el usuario, incluso si tiene Javascript desactivado. Con CSR puro, depende de si el renderizador ha ejecutado el JS y de cuándo lo haya hecho.
Google confirmó en marzo de 2026, en su propio blog de Search Central, que Googlebot ya no es un programa único: es un cliente más de una infraestructura de crawling centralizada que comparten Search, Shopping, AdSense y AdsBot.
Todos pasan por el mismo Web Rendering Service (WRS), el mismo que renderiza JavaScript como un navegador moderno. El AdsBot ejecuta JavaScript igual que el crawler orgánico, así que aquí la mayoría de auditorías (incluidas versiones anteriores de esta misma explicación) se quedan cortas.
El problema real es más sutil y, para quien hace WPO, más interesante. Dos límites técnicos de ese WRS explican por qué una landing puede fallar en Ads aunque “funcione”:
Corte de 2MB por recurso. Si tu bundle de JavaScript o tu CSS inline son voluminosos, todo lo que quede después de esos primeros 2MB simplemente no existe para el renderizador. Ni se descarga, ni se ejecuta, ni se indexa.
El WRS es stateless. Borra
localStoragey datos de sesión entre peticiones. Una app CSR que necesita ese estado persistido en cliente (token de auth, respuesta de API cacheada, flag de hidratación) para pintar el contenido real puede aparecer vacía en cada rastreo, aunque el navegador de un usuario real nunca pierda ese estado y nunca vea el problema.
El resultado, en cualquier caso, es el mismo: una landing page sin render basado en servidor puede pasar el test visual del equipo de paid media, recibir tráfico de pago y acumular un Quality Score penalizado porque el AdsBot ha visto una página casi vacía. Ejem. Menuda liada, ¿verdad?
He revisado cuentas de Google Ads donde el “landing page experience” era consistentemente “Por debajo del promedio” en páginas que cargaban sin ningún problema visual en el navegador.
Hasta parecía rápido, pero, ¡oh, sorpresa! Al revisar el HTML crudo con curl (luego te digo qué es esto), el cuerpo era un div vacío. El AdsBot había evaluado exactamente eso: una página sin contenido. No te miente, estás devoliendo basura.
¿Detalles interesantes? Deja un comentario y cuéntame.
El impacto en coste por clic es directo. Un Quality Score bajo sube el CPC. Con suficiente tráfico, la penalización de renderizado CSR se convierte en un coste que se paga cada mes sin que nadie haya hecho la relación mental con la decisión de estrategia de carga del frontend.
Nadie ha atado cabos entre ese div vacío y la pobreza del informe de rentabilidad. La culpa se reparte entre quien decidió la arquitectura y quien nunca ha comprobado qué vé AdsBot. Da igual de quién sea: alguien está pagando esa factura.
Los agentes autónomos de 2026 usan distintas estrategias para acceder a contenido web:
Algunos hacen una petición HTTP simple y parsean el HTML crudo que reciben.
Otros abren un navegador headless (Playwright, Puppeteer) y esperan a que la página se renderice antes de extraer el DOM.
Otros usan APIs de contenido cuando las hay.
El problema es que no sabes cuál de los tres aplica el agente que visita tu sitio.
Un mapeo reciente en Search Engine Journal ordena estos protocolos por capa:
ARD para que el agente descubra qué puede hacer tu sitio
WebMCP para que invoque esa acción
UCP para que complete una compra (el mismo protocolo de la entrega anterior)
Las tres capas asumen algo que damos por hecho sin comprobar: que el agente ya ha podido leer el HTML renderizado. Si esa capa de rendering falla, ARD no encuentra nada que descubrir y WebMCP no tiene nada que invocar.
En los logs de servidor con acceso de agentes habilitado, se puede ver cómo el comportamiento varía bastante: es poco consistente entre agentes.
Un agente que hace fetch simple ve lo mismo que el AdsBot: la devolución directa de la aplicación. Un agente con headless browser tarda más y puede que el sitio lo bloquee por sobrepasar el tiempo de espera o la tasa de peticiones. Un agente con acceso a API lee lo que la API devuelva, independientemente de cómo se renderice el frontend (y esto puede llevarnos a otros problemas bastante complejos que veremos en otras entregas).
Para los agentes que buscan extraer datos para fundamentar una respuesta (el grounding, en términos de LLM), un sitio CSR sin SSR es un agujero negro. El agente no puede citar algo que no ha podido leer.
Esto tiene consecuencias reales cuando un agente ayuda a un usuario a comparar productos o verificar especificaciones antes de comprar. Si la ficha de producto no está disponible en el HTML inicial, el agente trabaja con lo que tiene: otra fuente que sí lo estaba.
Antes de tomar ninguna decisión de arquitectura, hay que saber dónde estás. Algunas opciones:
Dale a “View source” en tu navegador y comprueba el contenido que devuelve el servidor. Mira si tu contenido está allí presente. Si lo está, el HTML devuelto por el servidor ya tiene lo que necesitas. Si no lo está, tienes un problema: habla con desarrollo.
Haz un curl de las URLs críticas de tu sitio y compara el HTML crudo con lo que renderiza el navegador. Si hay una diferencia sustancial en el contenido visible, tienes un problema activo en los tres frentes a la vez.
curl https://www.example.com/mi-landing
Si el sitio es un e-commerce o un B2B con landing pages de PPC importantes, la prioridad es SSR o ISR para esas rutas. Next.js, Nuxt y Astro permiten configurar renderizado por ruta: SSR para páginas de producto y landing, CSR para las zonas de aplicación donde el tiempo real importa más que la indexabilidad.
Para los agentes, el paso adicional es asegurarte de que el HTML inicial tiene metadatos de contenido suficientes. Si el script de “hidratación” (usado por ISR) tarda, al menos el <head> tiene contexto para que un parser simple entienda de qué va la página.
La revisión de este triángulo (SEO, AdsBot y agentes) es de las cosas que más impacto tiene por hora de trabajo en las auditorías técnicas. No porque sea complejo, sino porque normalmente nadie lo ha mirado en su conjunto junto.
Envía esto a alguien para que se espabile con su Javascript
Si tienes un sitio con arquitectura CSR y quieres revisar cómo lo está viendo cada uno de estos tres actores, es el tipo de análisis que hacemos en bigmomo. Puedes escribirme directamente.
La moraleja: devuelve HTML desde el servidor de manera directa siempre que puedas. Una vez que ese HTML llega, la siguiente pregunta es qué dice sobre tu marca: ahí entra el grafo de entidades que Google lleva construyendo desde 2012.
Si te gusta, deja un comentario
Sin posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.