Agentes web y la importancia del HTML semántico y accesible

Los agentes de inteligencia artificial que navegan la web, como los de modelos LLM multimodales, se encuentran con HTML complejo y con interfaces hechas para humanos. Igual que los lectores de pantalla, muchos de estos agentes dependen de la estructura semántica y de la accesibilidad del HTML para entender una página y actuar correctamente. En este artículo, vamos a ver cómo podemos hacerle la vida fácil a los nuevos visitantes de nuestras páginas web.

Para entender por qué la semántica y la accesibilidad importan, piensa en tres capas que muchos navegadores y agentes combinan:

  • Lo que se pinta: el Layout Tree (lo visible, no el DOM crudo).
  • Lo que significa: el Árbol de Accesibilidad (roles, nombres accesibles, relaciones).
  • Lo que se extrae: un resumen estructurado del contenido (texto, tablas, formularios) que sirve de entrada al modelo.

Como comentábamos en el artículo sobre tráfico agéntico, hay dos enfoques principales: los agentes visuales, que procesan la página como imagen, y los agentes basados en DOM, que leen el árbol HTML o el árbol de accesibilidad. Los primeros pueden “ver” botones o imágenes aunque no tengan texto, aunque con mucho más coste computacional, mientras que los segundos son más eficientes pero solo entienden elementos que tengan atributos HTML o ARIA, lo visual puro no existe para ellos. En la práctica, los agentes híbridos que combinan ambas formas suelen ser más robustos y efectivos.

En cualquier caso, seguir buenas prácticas de HTML semántico y accesibilidad hace que los agentes funcionen mejor. A continuación, os comparto una serie de recomendaciones respaldadas por la evidencia, con ejemplos de código y referencias a estudios y benchmarks como WebArena, Mind2Web o MiniWoB++.

Índice del artículo

1. Usar elementos HTML nativos

Siempre usa los elementos HTML apropiados en vez de contenedores genéricos. Los estándares son bastante claros al respecto: “usa elementos HTML nativos siempre que sea posible”. Por ejemplo, no uses un <div> clicable para algo que debería ser un botón. Los elementos nativos ya traen su rol accesible y su comportamiento por defecto, lo que ayuda tanto a usuarios como a agentes.

<!-- Correcto: Botón semántico -->
<button type="button">Play video</button>

<!-- Incorrecto: div sin semántica -->
<div onclick="playVideo()">Play video</div>

¿Cuál es la diferencia?

  • El <button> real ya sabe que es un elemento interactivo accionable y que se puede activar con Enter o Espacio :
  • El <div> con onclick solo sabe que alguien puede hacer clic, pero no entiende nada más.

Estudios recientes confirman que usar elementos nativos aumenta la tasa de éxito y reduce fallos en tareas web. Así que debemos evitar antipatrones que rompen a los agentes, como por ejemplo:

  • Div falso: Usar onclick + role="button" pero sin que funcione con teclado
  • Sin foco visible: Si quitas el borde azul (outline: none) sin poner una alternativa ni el usuario ni el agente sabe dónde está el cursor.
  • Orden raro: Usar tabindex para cambiar el orden natural de navegación
  • ARIA innecesario: Usar atributos ARIA para replicar algo que ya existe en HTML
  • div con  sin soporte de teclado no no es un botón.

2. Poner nombres accesibles a los controles

Cualquier elemento interactivo debe tener un nombre accesible que describa qué hace. Puede venir de texto visible, de un <label>, de un aria-label o de un alt. Por ejemplo, en formularios, cada campo debe tener su <label for> asociado.

<label for="email">Correo electrónico:</label>
<input type="email" id="email" name="email" aria-required="true">

Si usas iconos sin texto, como un botón de lupa, añade un aria-label, para que el botón no sea invisible para el agente:

<button type="submit" aria-label="Buscar">
  <img src="lupa.png" alt="" aria-hidden="true">
</button>

Y si quieres reutilizar texto que ya existe en la página, usa aria-labelledby, así el lector de pantalla dirá: "Total: €127.50 Pagar ahora" en lugar de solo "Pagar ahora":

<h3 id="precio-total">Total: €127.50</h3>
<button type="submit" aria-labelledby="precio-total">
  Pagar ahora
</button>

Cómo decide el navegador el "accessible name"

Los navegadores utilizan el algoritmo AccName para determinar el nombre accesible de cada elemento. Este algoritmo sigue un orden de prioridad específico: primero verifica si existe aria-labelledby, después busca aria-label, y finalmente recurre al texto visible del elemento o al label for correspondiente, dependiendo del tipo de elemento.

Los lectores de pantalla y otros dispositivos de asistencia obtienen esta información del Árbol de Accesibilidad, donde ya está procesado el nombre que determinó el navegador.

Lo recomendable es utilizar label for como primera opción siempre que sea posible, ya que es la solución más semántica y compatible. Reserva aria-label únicamente para situaciones donde no existe texto visible que pueda servir como etiqueta descriptiva adecuada.

3. Dar texto alternativo en imágenes

Cualquier imagen que tenga información debe llevar un alt descriptivo. Si es decorativa, se deja vacío. Un ejemplo:

<a href="/promociones">
  <img src="promo.png" alt="Promoción 50% descuento en suscripción">
</a>

Más de la mitad de los banners online no tienen alt y se vuelven invisibles para agentes y lectores de pantalla. Incluso en modelos multimodales, los datos textuales bien marcados se priorizan frente a señales visuales más difusas.

4. Estructurar con encabezados y regiones

Un documento bien estructurado ayuda a los agentes a navegar. Por ello se han de usar encabezados <h1>–<h6> en orden y no saltes niveles (si quieres saber más, este artículo te doy unos tips de HTML 5 para SEO y seo semántico) y define las regiones principales con <header>, <nav>, <main>, <aside>, <footer>.

<header><h1>Título del sitio</h1></header>
<nav aria-label="Menú principal">...</nav>
<main>
  <article>
    <h1>Título del artículo</h1>
    <section><h2>Subsección</h2></section>
  </article>
</main>
<aside aria-label="Relacionado">...</aside>
<footer>...</footer>

Al hacer esto estamos dando puntos de referencia claros. Por ejemplo, en el benchmark Mind2Web se vio que al filtrar el DOM para quedarse con nodos relevantes y estructurados se redujo el ruido casi a la mitad manteniendo el 95% de lo importante.

Además, en el estudio Understanding HTML with Large Language Models se demostró que los LLM generalistas ya son capaces de aprender a entender el HTML y superar modelos diseñados solo para entornos sintéticos como MiniWoB. También el trabajo Decoupling Structure and Content for DOM Representation Learning confirma que separar estructura y contenido del DOM mejora los resultados en tareas de grounding y extracción. No es casualidad que frameworks de RAG como LangChain incorporen utilidades como HTMLHeaderTextSplitter que aprovechan directamente los encabezados para segmentar mejor el contenido en chunks procesables por los modelos.

Ojo a un matiz: incluso sin "entender" la semántica de tus clases o CSS, un extractor puede aproximar muy bien qué es contenido mirando únicamente señales cuantitativas locales. De hecho, con número de palabras por bloque y densidad de enlaces se lograron mejoras fuertes en IR (Boilerplate Detection Using Shallow Text Features), trabajo que inspiró el DOM Distiller de Chrome.

Hoy en día, Blink (el motor de renderizado de Chrome) usa un sistema aún más sofisticado llamado Annotated Page Content (APC), que es un árbol estructurado con contenido, geometría e interactividad que se genera desde el layout tree (lo que realmente se renderiza), no desde el DOM crudo. Puede exportarse como Markdown estructurado o pasajes para alimentar modelos de IA. Es decir, que estructurar bien (encabezados, regiones) y evitar plantillas verbosas reduce ruido para agentes y "reader modes".

Cómo verificar tu estructura

Para comprobar rápidamente si tu página está bien organizada, abre las herramientas de desarrollador de tu navegador (F12) y ve a la pestaña "Accessibility". Ahí podrás revisar que los encabezados siguen el orden correcto (H1, después H2, después H3) y que cada elemento (rol y name) tiene bien definido su propósito.

También es recomendable usar herramientas como Lighthouse o instalar extensiones como axe DevTools que analizan tu página y te muestran problemas de accesibilidad.

5. Dar pistas semánticas en contenido visual o dinámico

  • Texto oculto pero accesible: añade un <span class="visually-hidden"> con el mensaje en banners solo gráficos.
  • Overlays semánticos: poner un <a> transparente con aria-label encima de un banner hace que el agente pueda clicar.
  • Describir cambios dinámicos: usa atributos como aria-live o aria-expanded para que el agente sepa qué ha cambiado.
  • Prefiere estados estáticos: usa frames o texto en lugar de animaciones que desaparecen.
  • Bloquea el fondo del modal con inert: evita que el agente interactúe con lo que no toca cuando hay un diálogo abierto.
  • Comunica estados asíncronos: usa aria-live="polite|assertive" y aria-busy="true" mientras cargas resultados. Ejemplo:
<div id="results" aria-live="polite" aria-busy="true">Cargando…</div>
<script>
  // ...fetch()
  document.getElementById('results').textContent = '42 resultados';
  document.getElementById('results').setAttribute('aria-busy', 'false');
</script>

En el estudio Machine-Readable Ads se comprobó que estas técnicas convertían anuncios invisibles en elementos detectables y clicables para agentes de IA sin empeorar la experiencia humana. Específicamente, añadir elementos como <span> fuera de pantalla, roles ARIA apropiados, y overlays semánticos hacía que elementos antes ignorados por los LLMs pasaran a ser clicables de forma fiable.

6. Optimizar diseño para la exploración automatizada

  • Contenido clave arriba. Muchos agentes no hacen scroll más allá de una o dos pantallas, así que pon lo esencial visible pronto.
  • Haz tu sitio responsive sin esconder funciones. Lo que ofrezcas en desktop debe estar también en móvil y ser alcanzable con clics o teclado, no solo hover.
  • Retrasa permisos del navegador. Notificaciones, geolocalización..., bloquean a muchos agentes. Pídelos solo cuando aporten valor inmediato (no al cargar).
  • Modales bien hechos, no “pop-ups” intrusivos. Usa <div role="dialog"> en HTML con botones accesibles. Ejemplo:
<div role="dialog" aria-modal="true" aria-labelledby="titulomodal">
  <h2 id="titulomodal">Suscríbete</h2>
  <button type="button" aria-label="Cerrar">✕</button>
  ...
</div>

El benchmark WebArena mostró que los agentes se bloqueaban con diálogos de permisos del navegador y que rara vez hacían scroll profundo. Esto me lo he encontrado también en mis pruebas.

7. Usar datos estructurados

Los metadatos como Schema.org ayudan a que la información sea entendida sin ambigüedad. No sustituyen a la accesibilidad básica, pero complementan. Por ejemplo:

<div itemscope itemtype="https://schema.org/Product">
  <h2 itemprop="name">Auriculares XYZ</h2>
  <span itemprop="offers" itemscope itemtype="https://schema.org/Offer">
    Precio <span itemprop="priceCurrency" content="EUR">€</span>
    <span itemprop="price" content="49.99">49,99</span>
  </span>
</div>

Esto haría que un agente pueda extraer directamente el precio de forma inequívoca.

7.1 Lo que sabemos por la documentación y la investigación académica

Hay trabajos como Schema2QA muestran cómo un schema bien definido puede servir directamente para generar agentes de preguntas y respuestas con buena precisión, y en Schema.org Action annotations se ve cómo anotar APIs web permite que asistentes ejecuten acciones como reservar o comprar. En el caso de Schema2QA, los autores midieron una precisión del 64–75% en agentes de preguntas y respuestas basados directamente en Schema.org, cifras comparables a asistentes comerciales como Siri. Y con las Action annotations se comprobó que asistentes podían ejecutar reservas o compras automáticamente al leer estas anotaciones, lo que nos indica que Schema.org no es solo un recurso SEO, también podría ser infraestructura útil para agentes.

Pero, como decíamos en el punto 4, los LLM generalistas ya leen HTML crudo razonablemente bien cuando el documento está limpio y la estructura es consistente. No hace falta “enseñarles” una sintaxis especial y lo que más suma es ordenar, titular bien y etiquetar controles.

7.2 Lo que estamos viendo hoy en la práctica con los grandes chatbots

Lo que reciben ChatGPT/Gemini/Claude al “leer” una URL suele ser un extracto plano tipo reader mode: sin etiquetas, sin scripts y sin atributos. Y ahí está la trampa: el Schema está dentro de una etiqueta <script>, por lo cual es invisible. Y, aunque lo pongas en microdata, te pasará lo mismo.

Pero tenemos 4 escenarios que cambian el resultado:

    1. Acceso para entrenamiento: aquí depende del origen del dataset.
      - En rastreos propios (GPTBot, Google-Extended, CCBot) algunos modelos pueden parsear JSON-LD/microdata y usarlo como señal adicional, otros solo indexan el texto plano. Pero no hay forma de saber qué modelo concreto “entiende” tu Schema y cuál no porque cada proveedor tiene pipelines distintos y opacos.
      - Cuando la información llega vía Common Crawl u otros repositorios públicos, suele perderse el contexto del Schema y se conserva solo el HTML simplificado.
      - Además de estos, entran datasets licenciados o aportados por usuarios, donde tampoco hay garantías de cómo se procesa el Schema.
    2. Acceso a través de SERP (Google/Bing): cuando el asistente/agente consulta resultados de búsqueda, si en ellos existe información estructurada en forma de rich snippets, entonces el chatbot los puede leer porque el buscador ya ha indexado tu Schema con JSON-LD/microdata y éste queda expuesto en sus snippets. Me di cuenta porque al hacer búsquedas en ChatGPT de la temática de un cliente, los productos de éste aparecían siempre con un atributo cuya información sólo estaba en el JSON-LD. En cambio, si le pedía a ChatGPT que entrara al producto y forzaba el scrapeo del mismo a través de sus tools, éste no veía el Schema y tampoco la versión con ese atributo (porque estaba en SSR).
    3. Acceso directo por scraping de la página: si fuerzas al chatbot a entrar y “leer” el HTML con sus tools, no verá el Schema porque se queda con texto plano.
    4. Acceso mediante agentes navegacionales: los que renderizan/navegan un DOM real sí pueden procesar el documento completo y, por tanto, acceder tanto a JSON-LD como a microdata para interpretar la página y sus funciones. En cuanto a si le dan algún uso, de momento lo desconozco.

 

Esquema visual del comportamiento de agentes conversacionales frente a agentes navegacionales en la lectura de datos estructurados
Los agentes navegacionales que procesan el DOM completo sí interpretan correctamente los datos estructurados.


Confirmación técnica:
El propio Blink (el motor de renderizado de Chrome que mencionábamos antes) tiene rutas de extracción de texto que eliminan scripts y segmentan el documento según estructura HTML (encabezados, regiones semánticas). En ese flujo, el JSON-LD dentro de <script> simplemente no pasa al resultado final, salvo que el agente renderice el DOM completo y acceda al APC (Annotated Page Content).

7.3 Lo que pasa al generar schema con LLMs

Eso sí, cuidado con delegar la generación de este marcado a un LLM. En el estudio LLM4Schema.org se comprobó que modelos como GPT-4 generan Schema.org más completo que un humano en muchos casos, pero también cometen errores o inventan propiedades, lo que puede acabar en un marcado inválido. Así que conviene usar la IA como apoyo, pero siempre validando el resultado con herramientas oficiales. En ese mismo estudio se cuantifica el problema, hasta un 40–50% del marcado generado automáticamente resultó inválido o inventado. Por eso conviene usar la IA como asistente para ahorrar tiempo, pero nunca como sustituto, siempre validando con el validador oficial de Schema.org o con la herramienta de resultados enriquecidos de Google.

8. Conclusión: El HTML semántico y accesible hace que los agentes de IA funcionen mejor

El HTML semántico y accesible no solo ayuda a usuarios con discapacidades, también hace que los agentes de IA funcionen mejor. Usar los elementos correctos, etiquetar y estructurar bien el contenido y añadir metadatos prepara nuestras páginas para la siguiente generación de agentes. El HTML semántico es la base de la accesibilidad, y ahora también podemos decir que es la base de la IA-readiness y Agent Experience.

Podríamos decir que si un lector de pantalla lo entiende bien, un agente también tendrá muchas más papeletas de cumplir la tarea.

Relacionado:

Tráfico agéntico: así navegan los agentes de IA y qué tienes que saber tú

Natzir Turrado 20 agosto 2025

Compartir

Facebook Linkedin Twitter

Otros artículos

SEO Local para ChatGPT

Foursquare anunció su asociación con OpenAI hace 4 meses para alimentar las búsquedas locales en ChatGPT a través de su Places API. Desde entonces, su base de datos, que incluye más de 100 millones de puntos de interés en más de 200 países, se ha convertido en una de las principales fuentes utilizadas por el […]

Leer más

Qué es un buscador semántico

Un buscador semántico es aquel que no da enlaces clasificados por relevancia, autoridad y demás menesteres, un buscador semántico es aquel que da respuesta a tus preguntas. La Web en sí es una paradoja interesante, está hecha con tecnología, pero para dar soluciones a la gente. Los sitios que visitamos cada día utilizan el lenguaje […]

Leer más