Cómo lee tu página un motor de búsqueda (y una IA)

Un motor de búsqueda y una IA generativa no «miran» tu página como lo haría un visitante humano. Recuperan un flujo de HTML, lo transforman (o no) en una estructura de datos llamada DOM, y después extraen de ahí un texto en bruto que dividen en bloques para indexarlo o usarlo como respuesta. Entender este recorrido cambia, de forma concreta, cómo debes escribir y estructurar tus páginas.

El recorrido del HTML en bruto al renderizado

Cuando un crawler visita una URL, recibe primero una respuesta HTTP que contiene el HTML en bruto enviado por tu servidor, antes de cualquier ejecución de JavaScript. Es este HTML inicial el que la mayoría de los robots analiza en primer lugar, porque ejecutarlo por completo (el «renderizado») cuesta tiempo de cálculo y memoria, multiplicado por los miles de millones de páginas rastreadas cada día.

Google es capaz de renderizar el JavaScript en un segundo momento, mediante una cola independiente que puede tardar entre unos segundos y varios días según la carga del momento y la prioridad asignada a tu sitio. Dicho de otro modo, existe un desfase, a veces considerable, entre el momento en que se lee tu HTML en bruto y el momento en que se tiene en cuenta su renderizado completo (tras la ejecución de JavaScript). Los crawlers de la IA generativa (ChatGPT, Claude, Perplexity en particular) suelen ser más limitados en este aspecto: se observa que se apoyan más en el HTML estático o en versiones ya indexadas por motores de terceros, en lugar de en un renderizado JavaScript completo y sistemático en cada visita.

Esta diferencia de tratamiento explica por qué dos herramientas pueden tener una visión distinta de una misma página: una puede haber esperado al renderizado completo, la otra no.

Lo que ve un crawler frente a lo que ve un navegador

Un navegador ejecuta el CSS y el JavaScript, carga las fuentes, aplica las animaciones y muestra un renderizado visual completo, píxel a píxel. Un crawler no «ve» nada visual: procesa una cadena de caracteres (el HTML) y, eventualmente, una estructura en árbol construida a partir de esa cadena.

En la práctica, si un contenido solo existe visualmente — una información codificada únicamente en una imagen sin texto alternativo, un texto generado por una animación CSS, un contenido inyectado tras un clic del usuario, una información emergente que solo aparece al pasar el cursor — es probable que ningún robot lo perciba nunca como texto utilizable. No es que lo ignore deliberadamente: simplemente no tiene forma de reproducir la interacción humana que desencadena su aparición.

El DOM y la extracción de texto

El DOM (Document Object Model) es la representación en árbol del HTML: cada etiqueta se convierte en un «nodo» con padres, hijos y atributos. Es a partir de esta estructura arbórea que los motores y las IA extraen el texto útil, apoyándose en particular en:

la jerarquía de etiquetas (<header>, <nav>, <main>, <article>, <footer>) para distinguir el contenido principal de los elementos periféricos;
las etiquetas de título (<h1> a <h6>) para identificar la estructura lógica del contenido;
el orden del HTML en el documento (no el orden visual impuesto por el CSS).

Un punto que se pasa por alto a menudo: si usas position: absolute o flex-direction: row-reverse para reorganizar visualmente bloques, el orden que lee la máquina sigue siendo el del código fuente, no el que se muestra en pantalla. Un párrafo colocado en último lugar en el HTML pero desplazado visualmente a la parte superior de la página mediante CSS seguirá siendo tratado, por la mayoría de los sistemas de extracción, como el último bloque de contenido — lo que puede distorsionar la estructura lógica percibida por un lector automático.

JavaScript: la trampa del contenido invisible

Los sitios construidos con JavaScript del lado del cliente (algunas aplicaciones React, Vue o Angular sin renderizado en servidor) plantean un riesgo real: si el contenido de texto solo aparece tras la ejecución del script, y el robot que visita la página no lo ejecuta o lo ejecuta solo parcialmente, ese contenido simplemente está ausente de lo que se indexa. El riesgo es especialmente alto en los bloques cargados de forma diferida (lazy loading agresivo), en los contenidos detrás de una pestaña cerrada por defecto, o en los datos inyectados mediante una llamada API asíncrona tras la carga inicial de la página.

Para limitar este riesgo existen varios enfoques:

<!-- Renderizado del lado del servidor (SSR): el HTML inicial ya contiene el texto -->
<article>
  <h1>Título visible de inmediato en el HTML fuente</h1>
  <p>Este párrafo está presente antes de cualquier ejecución de JS.</p>
</article>

El SSR (server-side rendering), el renderizado estático (SSG) o la hidratación progresiva garantizan que el texto esencial esté presente desde la primera respuesta HTTP, sin depender de que el robot que te visita ejecute JavaScript. Estos enfoques no son simples opciones técnicas reservadas a los desarrolladores: tienen un impacto directo en la visibilidad de tu contenido ante cualquier sistema automatizado, ya sea un motor de búsqueda clásico o una IA generativa que explora la web para construir una respuesta.

Lo que esto cambia concretamente para tu contenido

Tres implicaciones directas para la redacción y la maquetación de tus páginas:

El contenido de texto importante (argumentos, respuestas a preguntas, datos numéricos) debe existir en el HTML en bruto, no solo tras una interacción o una animación.
La estructura del código fuente debe reflejar el orden lógico de lectura, con independencia del formato visual impuesto por el CSS.
Un marcado semántico claro ayuda a separar el contenido principal del ruido (menús, publicidad, pie de página repetitivo) — un punto detallado en la lección sobre HTML5 semántico.

Para comprobar de forma concreta lo que puede leer un robot, compara el HTML en bruto que devuelve tu servidor (clic derecho → «código fuente de la página», no el inspector, que muestra el DOM tras el renderizado) con lo que se muestra en pantalla. Cualquier discrepancia notable — un bloque de texto presente visualmente pero ausente del código fuente — es una señal que corregir de forma prioritaria.

Esta cuestión del recorrido técnico del contenido conecta directamente con dos temas del siguiente módulo: la forma en que un LLM divide tu contenido en bloques una vez extraído el texto, y la manera de gestionar el acceso de los crawlers mediante el archivo robots.txt.