Lo que ves no es lo que entregás: cómo auditar si tu contenido existe para Google y para los agentes de IA

Hay una intuición que cualquiera que lleve años en esto ya incorporó: la página que ves en el navegador y la página que recibe un bot no son la misma. Lo aprendimos con Flash, lo volvimos a aprender con los frameworks de JavaScript, y ahora toca aprenderlo por tercera vez, con un agravante: ya no hay un solo lector mecánico al que satisfacer. Ahora hay tres, y cada uno lee distinto.

Este artículo es una invitación a hacer algo que todos los SEOs sabemos en abstracto y casi nadie chequea en concreto: abrir una página propia y preguntarse, capa por capa, qué parte de ese contenido existe de verdad para cada uno de los que vienen a leerla sin dedo, sin ojos y, cada vez más, sin paciencia.

Tres lectores, tres formas de leer

Googlebot es el lector más generoso. Descarga el HTML y después lo renderiza en un Chrome sin interfaz, ejecuta el JavaScript de carga y se queda con el DOM resultante. Pero renderizar no es interactuar: no hace clic, no abre acordeones, no pasa de pestaña, no hace scroll para disparar la carga del siguiente lote. Ejecuta lo que se ejecuta solo; lo que depende de un evento de usuario, para Googlebot nunca ocurrió.

Los crawlers de los LLMs son más crudos. El estudio conjunto de Vercel y MERJ sobre su red de sitios, publicado a fines de 2024, no encontró evidencia de ejecución de JavaScript en ninguno de los grandes bots de IA: GPTBot, ClaudeBot, PerplexityBot y compañía bajan el HTML tal cual lo devuelve el servidor, a veces hasta bajan los archivos JS, pero no los corren. Para ellos, lo que no está en el HTML plano no está. El dato tiene casi dos años y estos bots cambian rápido, así que conviene volver a comprobarlo periódicamente, pero la lógica de fondo no cambia: no apostés tu contenido a que un bot va a comportarse como una persona.

Los agentes de IA son el lector nuevo, y el más raro de los tres. No vienen a indexar; vienen a resolver una tarea para alguien. Algunos navegan con un browser real y entonces sí ven lo renderizado (y a veces hasta hacen clic). Otros solo hacen un fetch del HTML, como un crawler. Pero todos comparten una restricción que los otros dos lectores no tienen: un presupuesto de tokens. No leen tu página de arriba a abajo; recortan. Y lo que recortan es lo que para ellos no existió. Sobre esto vuelvo más abajo, porque es donde la visibilidad deja de ser un problema técnico y pasa a ser un problema de escritura.

Las tres capas donde puede vivir tu contenido

Antes de auditar conviene tener claro que “el contenido está en la página” puede querer decir tres cosas distintas, y que cada lector llega hasta una capa diferente.

Capa 1: el HTML que manda el servidor. Lo que ves con Ctrl+U, antes de que corra una sola línea de JavaScript. Es la única capa que ven, con seguridad, todos los lectores. Si tu contenido importante está acá, dormí tranquilo.

Capa 2: el DOM después de la carga. Lo que ves en la pestaña Elements de DevTools una vez que la página terminó de cargar. Incluye lo que el JavaScript inyectó solo, sin que nadie tocara nada. Googlebot llega hasta acá. Los crawlers de LLMs, según la evidencia disponible, no.

Capa 3: lo que aparece después de una interacción. La respuesta de la FAQ que se escribe en el DOM recién al abrirla. El contenido de la segunda pestaña. Las reseñas que cargan con “ver más”. Los productos que aparecen al scrollear. La ficha técnica detrás de un modal. Acá ya no podés asumir que llegue nadie. Googlebot no debería depender de esa interacción; los crawlers de LLMs tampoco; y que un agente pueda hacer clic no significa que vaya a hacerlo.

Y hay una cuarta capa que ni siquiera cuenta como capa: contenido que está, pero en un formato que ningún lector mecánico va a procesar bien. Texto dentro de imágenes. Tablas de precios como PNG. Comparativas en un PDF embebido. Para el usuario es contenido; para el crawler es un rectángulo.

El chequeo de dos minutos, generalizado

Este método es el que usamos en la agencia para chequear si el contenido es legible para todo el mundo:

1. Abrí en Chrome una página que tenga el contenido que te importa. Mejor si es un template (la ficha de producto, la landing de servicio): lo que encuentres va a aplicar a todas las páginas que lo usen.
2. Elegí un fragmento de ese contenido que esté detrás de una interacción: una FAQ cerrada, una pestaña no activa, un bloque colapsado. Abrilo y copiá unas cinco o seis palabras seguidas que sean difíciles de encontrar en otra parte de la página.
3. Botón derecho, Inspeccionar. En Elements, Ctrl+F (Cmd+F en Mac) y pegá el fragmento. Si Chrome lo resalta en el DOM, el texto está ahí ahora.
4. Recargá la página. Y acá está la clave: después de recargar, no toques nada.
5. Volvé a buscar el mismo fragmento en Elements.

Si aparece, tu componente es honesto: el contenido ya estaba disponible antes de la interacción y el clic solo lo mostraba. Es capa 1 o capa 2. Si no aparece, acabás de confirmar que el contenido se inyecta al clic. Es capa 3. Para cualquier crawler, ese bloque tiene título y no tiene cuerpo.

Dos pasos más para saber exactamente en qué capa caíste:

• Ctrl+U y buscar el mismo fragmento en el código fuente. Si está en Elements pero no en el código fuente, es capa 2: Google probablemente lo lea y los crawlers de LLMs probablemente no. Si está en ambos, es capa 1, y es lo que querés.
• Desactivar JavaScript y recargar. En DevTools, Ctrl+Shift+P, escribí Disable JavaScript, Enter, y recargá. Lo que quede en pantalla es, con bastante aproximación, lo que recibe un bot que no renderiza. Es la versión visual del punto anterior y la que mejor funciona para mostrarle el problema a alguien que no es técnico. Si preferís hacerlo con un clic, la extensión Web Developer, que repasamos en las 13 extensiones de Chrome que todo equipo SEO debería usar, tiene exactamente ese interruptor. 

Y para cerrar con la confirmación oficial: Inspección de URL en Search Console, Probar URL publicada y después Ver página probada → HTML. Ahí buscás el fragmento en el HTML renderizado que Google efectivamente procesó. Es lo que le llevás al desarrollador cuando te dice que “Google ejecuta JavaScript”, porque sí, lo ejecuta, y aun así el texto no está.

Dónde suele fallar

Las FAQs son el caso emblemático, pero la lista de sospechosos es más larga, y conviene correr el chequeo en todos:

• Acordeones y FAQs que cargan la respuesta al abrir.
• Pestañas (descripción / especificaciones / reseñas) donde solo la primera viene en el HTML.
• Botones de “ver más” o “cargar más” que traen el contenido por AJAX.
• Scroll infinito en listados de productos o artículos.
• Modales y drawers con fichas técnicas, tablas de talles, condiciones.
• Reseñas y valoraciones inyectadas por un widget de terceros.
• Contenido que depende de aceptar cookies, de un selector de ubicación o de un login.
• Texto en imágenes, infografías y PDFs embebidos.

Un detalle que suele pasarse por alto: si tu plugin de SEO genera el schema FAQPage o Product a partir de ese contenido, es posible que el JSON-LD sí lleve el texto aunque el HTML visible no. Eso no te salva. Google exige que el marcado estructurado se corresponda con el contenido real de la página. Si un dato solo existe en el JSON-LD, pero no en el contenido disponible para el usuario y los crawlers, tenés como mínimo una señal inconsistente.

La solución casi nunca es pelearse con el componente. El acordeón está bien, la pestaña está bien. Lo que hay que pedirle a desarrollo es que el contenido se renderice en el HTML inicial (en servidor o en build) y que el JavaScript se limite a mostrarlo y ocultarlo. En la mayoría de los stacks es un cambio chico. En WordPress suele ser reemplazar un bloque o plugin por otro que imprima el contenido en el markup; muchos lo hacen bien, algunos no, y la única forma de saberlo es el chequeo de arriba.

La otra visibilidad: la que no se audita con DevTools

Hasta acá, visibilidad quiso decir “el texto está en el lugar donde el lector lo va a buscar”. Con los agentes de IA aparece una segunda pregunta, que DevTools no responde: suponiendo que el texto está disponible, ¿está escrito de una forma que permita recuperarlo y entenderlo fuera de contexto?

El equipo de Pare & Co publicó este año una idea que me parece de las más útiles del momento: la mayoría de los sistemas que consultan la web para responder no leen tu página entera. Recuperan pasajes. Trocean el contenido (muchas veces por párrafo), eligen los fragmentos semánticamente más cercanos a la pregunta y meten solo esos en la ventana del modelo. Tu contenido compite pasaje por pasaje, no página por página. 

En su experiencia auditando clientes, los fragmentos que terminan citados son los que contienen una unidad completa de información (afirmación, evidencia e implicancia) en un bloque relativamente corto; los que necesitan el contexto de arriba para entenderse se recuperan menos y se citan casi nunca. Son observaciones de su propia práctica, no un estudio controlado, y así hay que tomarlas; pero coinciden con lo que uno ve cuando pregunta algo a un asistente y mira qué párrafo exacto trajo.

Si eso es cierto, la auditoría de visibilidad tiene una segunda vuelta, y es de redacción:

• ¿La primera oración de cada sección contesta algo, o solo prepara el terreno?
• ¿Tus títulos dicen qué afirma la sección, o solo de qué tema trata?
• ¿Tus párrafos son unidades que se sostienen solas si alguien los lee aislados, o dependen de un “como vimos arriba”?
• ¿Tu mejor dato está en el cuarto párrafo de la tercera sección, después del preámbulo?

Es la misma lógica que vimos al hablar del Anchor Context y el entorno del enlace: el valor nunca estuvo solo en la palabra, sino en lo que la rodea. La diferencia es que ahora ese entorno tiene que viajar dentro del mismo bloque, porque es lo único que el agente se lleva. 

Nada de esto exige escribir mal ni abandonar el hilo narrativo que a los humanos nos hace seguir leyendo. Exige adelantar la sustancia. El que guarda la conclusión para el final está escribiendo para el suspenso; el que quiere ser citado, la pone primero.

Hay otra capa, todavía más incómoda, que la academia empezó a mirar: el agente como lector es un lector con límites de interpretación. En la conferencia ACM Hypertext de este año se presentó un trabajo de Gupta y Joshi que, desde el título, pone el dedo ahí: “The Assumed Reader“, el lector presupuesto. Durante treinta años diseñamos páginas para un lector humano que navega, infiere y completa lo que falta. El agente puede inferir, pero no conviene diseñar el contenido suponiendo que va a completar correctamente lo que falta. Toma fragmentos, los interpreta dentro de un contexto limitado y construye con ellos una respuesta. Esa literalidad es también una vulnerabilidad (el mismo trabajo dialoga con la literatura sobre inyección indirecta de instrucciones en páginas web), pero para nosotros, los que escribimos, el mensaje es más simple: dejaste de poder asumir cómo lee tu lector.

Lo de siempre, otra vez

Me quedé pensando en por qué este error es tan común, y creo que la respuesta es incómoda: porque las páginas se diseñan para la persona que las usa, y la persona que las usa hace clic, scrollea, abre, lee salteado y entiende igual. El componente cumple para el usuario, el equipo de producto lo da por bueno, y nadie en la cadena tiene el reflejo de preguntarse qué pasa cuando el que llega no tiene dedo, ni ojos, ni ganas de leer todo.

La página no es lo que se ve. La página es lo que se entrega. Todo lo que pongas del lado de la interacción, por más valioso que sea, está apostando a que alguien lo vaya a buscar. Y todo lo que pongas del lado del suspenso está apostando a que alguien lo vaya a esperar. Los lectores que hoy deciden si te citan o no, no buscan ni esperan: toman lo que hay.

Así que la próxima vez que te muestren una landing impecable, hacé lo que haría cualquier viejo desconfiado: recargá, no toques nada, apagá el JavaScript, y fijate qué queda. Y después leé el primer párrafo de cada sección como si fuera lo único que alguien va a ver. Porque probablemente lo sea.