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:
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
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?
<button> real ya sabe que es un elemento interactivo accionable y que se puede activar con Enter o Espacio :<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:
onclick + role="button" pero sin que funcione con tecladooutline: none) sin poner una alternativa ni el usuario ni el agente sabe dónde está el cursor.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>
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.
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.
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".
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.
<span class="visually-hidden"> con el mensaje en banners solo gráficos.<a> transparente con aria-label encima de un banner hace que el agente pueda clicar.aria-live o aria-expanded para que el agente sepa qué ha cambiado.inert: evita que el agente interactúe con lo que no toca cuando hay un diálogo abierto.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.
<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.
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.
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.
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:
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).
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.
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ú
La Inteligencia Artificial ha dejado de ser una promesa futurista para convertirse en una fuerza transformadora en el presente y, el SEO, tenía que subirse también a la ola. Problema: nadar por el estado actual de herramientas, workflows y agentes de IA para SEO puede ser complicado, y el hype existente nubla la realidad práctica. […]
Leer másFoursquare 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