Legibilidad para rastreadores de IA: por qué no leen tu web

Abres tu web en el navegador y está todo: los textos, los precios, las descripciones. Pero le preguntas a ChatGPT por tu empresa y contesta con información desactualizada, incompleta o directamente de la competencia. La explicación más frecuente no es que el rastreador no llegue a tu web, sino que llega y no encuentra nada que leer: recibe un HTML casi vacío que solo se convierte en página después de ejecutar JavaScript, algo que un navegador hace y que no todos los rastreadores hacen.

En esta guía verás qué significa exactamente que una web sea legible para un rastreador de IA generativa, por qué el renderizado con JavaScript es el factor que más pesa de todos, cómo comprobar en menos de un minuto qué ve realmente un rastreador cuando visita tu página, y qué otras señales del HTML determinan que el contenido se entienda o se malinterprete.

Qué significa que una web sea legible para un rastreador

La legibilidad es lo que ocurre después del acceso. Son dos problemas distintos y conviene no mezclarlos: el acceso responde a “¿el rastreador consigue entrar?”, y la legibilidad responde a “una vez dentro, ¿entiende qué está leyendo?”. Una web puede responder correctamente a todos los rastreadores y aun así ser prácticamente ilegible para ellos, porque lo que devuelve es un esqueleto sin contenido, o un muro de texto donde el menú de navegación y el artículo pesan lo mismo.

Si lo que te falla es lo primero, el artículo que necesitas es otro: cómo saber si tu firewall está bloqueando a los rastreadores de IA. Este trata de lo segundo.

Legibilidad para máquinas vs. accesibilidad web

Los dos conceptos se solapan, pero no son el mismo. La accesibilidad web (WCAG) busca que una persona con una discapacidad pueda usar el sitio: contraste suficiente, navegación por teclado, textos alternativos en las imágenes. La legibilidad para rastreadores busca que un programa entienda la estructura del contenido sin verlo.

El solape es real y conviene aprovecharlo: un HTML semántico bien construido, con encabezados jerárquicos y regiones marcadas, mejora las dos cosas a la vez. Pero no son equivalentes. Una web puede aprobar una auditoría de accesibilidad y seguir siendo ilegible para un rastreador que no ejecuta JavaScript, porque el lector de pantalla del usuario sí lo ejecuta y el rastreador no.

El factor que más pesa: contenido que solo existe con JavaScript

De todo lo que se puede medir en legibilidad, este es el que decide el resultado. Los demás factores afinan; este determina si hay algo que afinar.

Por qué el navegador lo ve y el rastreador no

Cuando pides una página, el servidor devuelve un documento HTML. En una web renderizada en servidor, ese documento ya contiene el texto. En una web renderizada en el cliente —lo habitual en aplicaciones hechas con React, Vue o Angular sin configuración adicional—, ese documento contiene poco más que un contenedor vacío y una referencia a un archivo JavaScript. El texto aparece después, cuando el navegador descarga ese archivo, lo ejecuta y construye la página.

Tu navegador hace ese trabajo sin que lo notes. Un rastreador no tiene por qué hacerlo: ejecutar JavaScript de millones de páginas es caro, y no todos los sistemas que rastrean la web para alimentar modelos de IA lo hacen. Algunos leen el HTML tal como sale del servidor y siguen adelante. Para ellos, tu página no está incompleta: está vacía.

Cómo comprobarlo en menos de un minuto

No hace falta ninguna herramienta especial. Pide la página como la pediría un rastreador y busca en la respuesta una frase que sepas que está en el contenido:

curl -s https://tudominio.com | grep -c "una frase de tu contenido"

Si devuelve 0, esa frase no está en el HTML servido: solo aparece después de ejecutar JavaScript. Si no tienes terminal a mano, el equivalente en el navegador es abrir el código fuente con Ctrl+U (o Cmd+Opt+U) y buscar ahí la misma frase. Es importante usar “ver código fuente” y no el inspector de elementos: el inspector muestra la página ya construida, con el JavaScript ejecutado, y por eso siempre parece que todo está bien.

La solución: renderizado en servidor o generación estática

La corrección real consiste en que el HTML llegue con el contenido dentro. Hay dos formas habituales de conseguirlo, y ambas están soportadas por los frameworks actuales:

Renderizado en servidor (SSR): el servidor construye el HTML completo en cada petición. Es lo indicado cuando el contenido cambia con frecuencia o depende del usuario.
Generación estática (SSG): el HTML se construye una vez, al publicar, y se sirve ya hecho. Es lo indicado para contenido que no cambia en cada visita: páginas de producto, artículos, páginas institucionales.

Si tu web está en WordPress, Shopify o cualquier CMS clásico, esto ya lo tienes resuelto por defecto: el HTML sale del servidor con el contenido dentro. El problema aparece sobre todo en desarrollos a medida y en aplicaciones de una sola página.

Por qué <noscript> es un parche y no una solución

La etiqueta <noscript> permite incluir contenido alternativo para quien no ejecuta JavaScript. Sirve para tapar el agujero mientras se prepara un cambio mayor, y es mejor que no tener nada. Pero mantener esa alternativa sincronizada con el contenido real es un trabajo manual que se abandona en cuanto hay prisa, y a partir de ahí lo que el rastreador lee deja de coincidir con lo que el usuario ve. Úsalo como medida temporal, con fecha de caducidad.

Las señales que hacen que el contenido se entienda

Suponiendo que el contenido esté en el HTML, quedan cuatro señales que determinan si se interpreta bien. Ninguna de ellas es tan decisiva como la anterior, pero juntas marcan la diferencia entre un texto que se entiende y un texto que hay que adivinar.

Un solo H1, y que diga de qué va la página

El <h1> es la señal más básica sobre el tema de una página. Los dos errores habituales son opuestos: no tener ninguno, porque el diseño usa un <div> con letra grande en su lugar; o tener varios, porque se han elegido las etiquetas por tamaño visual en vez de por jerarquía. En el primer caso falta la señal; en el segundo, el tema principal queda ambiguo. Un <h1> por página, y el resto en <h2> y <h3> según la estructura real del contenido.

El idioma declarado en la etiqueta raíz

Una línea que se olvida con frecuencia y que cuesta nada:

<html lang="es-ES">

Sin ella, el idioma del contenido hay que deducirlo del propio texto. Se deduce casi siempre bien, pero “casi siempre” es peor que “siempre”, y en webs con contenido en varios idiomas o con muchos nombres propios la deducción falla más de lo que parece.

Delimitar el contenido principal con <main> y <article>

Una página típica contiene mucho texto que no es el contenido: el menú, el pie, los avisos de cookies, los enlaces relacionados. Si todo eso está en <div> indistinguibles, separar el grano de la paja es una tarea de adivinación. Envolver el contenido principal en <main>, y cada pieza autónoma en <article>, elimina esa ambigüedad con dos etiquetas.

Es también el punto que más se repite en las webs que analizamos, precisamente porque no tiene ningún efecto visible: quitar el <main> no cambia nada en pantalla, así que nadie lo echa de menos.

Y una señal que pertenece al vecindario: los datos estructurados

La legibilidad se ocupa de que el texto se lea y se entienda. Declarar explícitamente qué es cada cosa —quién eres, qué vendes, quién firma un artículo— es el paso siguiente, y se hace con datos estructurados. Son problemas vecinos: el primero hace que el contenido exista para la máquina, el segundo hace que no tenga que interpretarlo.

Las cinco comprobaciones, ordenadas por lo que pesan

No todas valen lo mismo, y tratarlas como una lista plana lleva a corregir lo fácil antes que lo importante. Este es el orden por impacto:

Comprobación	Peso	Qué falla cuando falla
Contenido disponible sin JavaScript	🔴 Crítico	El rastreador recibe una página vacía. Nada de lo demás importa.
Alternativa <noscript>	🟠 Medio	Sin renderizado en servidor y sin alternativa, no queda nada que leer.
Encabezado principal (H1)	🟠 Medio	Falta la señal más básica sobre el tema, o hay varias y se contradicen.
Idioma declarado	🟠 Medio	El idioma hay que deducirlo del texto, y a veces se deduce mal.
Contenido principal delimitado	🟡 Bajo	El menú y el pie de página pesan lo mismo que el contenido.

El orden importa: corregir el H1 en una web cuyo contenido solo existe con JavaScript es pintar una pared que todavía no está construida.

Errores comunes al intentar arreglar la legibilidad

Comprobarlo con el inspector de elementos en lugar de con “ver código fuente”. El inspector muestra la página ya construida, así que siempre parece que el contenido está.
Dar por hecho que si Google indexa la página, todos los rastreadores la leen igual. Google renderiza JavaScript; no todos los sistemas que alimentan asistentes de IA lo hacen.
Instalar un plugin de prerender y no volver a comprobarlo. Estas soluciones dependen de detectar correctamente al rastreador, y cuando la detección falla, falla en silencio.
Corregir una plantilla y suponer que el resto del sitio hereda el arreglo. La página de inicio y las fichas de producto suelen usar plantillas distintas.

Ninguno de estos problemas se detecta mirando la web. Todos dependen de qué devuelve realmente el servidor cuando le pide la página algo que no es un navegador, que es exactamente lo que hace un diagnóstico técnico de accesibilidad para rastreadores.

Preguntas frecuentes sobre legibilidad para rastreadores

¿Los rastreadores de IA ejecutan JavaScript?

No todos, y no siempre. Ejecutar JavaScript a escala de toda la web es costoso, y algunos sistemas leen el HTML tal como lo devuelve el servidor. Como no hay forma de saber con certeza qué hace cada uno en cada momento, lo prudente es que el contenido no dependa de ello.

Si Google indexa bien mi web, ¿está el problema resuelto?

No necesariamente. Google renderiza JavaScript desde hace años, así que una web que solo funciona con JS puede indexarse en Google y aun así resultar ilegible para otros rastreadores. Son sistemas distintos con capacidades distintas.

¿Cómo veo lo que ve un rastreador en mi web?

Abriendo el código fuente de la página con Ctrl+U (Cmd+Opt+U en Mac) y buscando ahí una frase de tu contenido. Si no aparece, no está en el HTML servido. El inspector de elementos no vale para esto, porque muestra la página después de ejecutar el JavaScript.

¿Sirve <noscript> para solucionarlo?

Sirve como parche temporal. El problema es mantenerlo sincronizado con el contenido real: en cuanto se desincroniza, lo que lee el rastreador deja de coincidir con lo que ve el usuario. La solución estable es renderizar en servidor o generar el HTML de forma estática.

¿Puede una web tener varios H1?

Técnicamente el HTML lo permite, pero para un rastreador el resultado es un tema principal ambiguo. Lo recomendable sigue siendo un único H1 por página, y el resto de encabezados elegidos por jerarquía y no por tamaño visual.

¿Mejorar la legibilidad garantiza que ChatGPT cite mi web?

No. Garantiza que sea posible: si el contenido no está en el HTML, no hay nada que citar. Que además se cite depende de la autoridad del sitio, de la consulta concreta y de otros factores que ningún cambio técnico controla por sí solo.

Qué comprobar en tu web ahora mismo

Empieza por lo que más pesa: abre el código fuente de tu página más importante y busca una frase del contenido. Si no está, ya sabes cuál es tu prioridad y ninguna otra corrección la sustituye. Si está, revisa entonces el H1, el atributo lang y si el contenido principal va dentro de un <main>. Y si prefieres verlo todo de una vez, sobre todas tus páginas y con la línea exacta que causa cada punto, puedes comprobar la legibilidad de tu web de forma gratuita.