Todas las principales plataformas de inteligencia artificial ahora pueden navegar por sitios web de forma autónoma. La navegación automática de Chrome se desplaza y hace clic. ChatGPT Atlas llena formularios y completa compras. Perplexity Comet investiga entre pestañas. Pero ninguno de estos agentes ve su sitio web como lo hace un humano.
Esta es la Parte 4 de una serie de cinco partes sobre la optimización de sitios web para la web agencial. La parte 1 cubrió la evolución de SEO a AAIO. La parte 2 explicó cómo hacer que su contenido sea citado en las respuestas de IA. La parte 3 mapeó los protocolos que forman la capa de infraestructura. Este artículo se vuelve técnico: cómo los agentes de IA perciben realmente su sitio web y qué construir para ellos.
La idea central es una que sigue apareciendo en mi investigación: lo más impactante que se puede hacer para la compatibilidad de los agentes de IA es el mismo trabajo que los defensores de la accesibilidad web han estado impulsando durante décadas. El árbol de accesibilidad, creado originalmente para lectores de pantalla, se está convirtiendo en la interfaz principal entre los agentes de IA y su sitio web.
Según el Informe Imperva Bad Bot 2025 (Imperva es una empresa de ciberseguridad), el tráfico automatizado superó al tráfico humano por primera vez en 2024, constituyendo el 51% de todas las interacciones web. No todo eso es navegación agente, pero la dirección es clara: la audiencia no humana de su sitio web ya es mayor que la humana y está creciendo. A lo largo de este artículo, nos basamos exclusivamente en documentación oficial, investigaciones revisadas por pares y anuncios de las empresas que construyen esta infraestructura.
Tres formas en que los agentes ven su sitio web
Cuando un humano visita su sitio web, ve colores, diseño, imágenes y tipografía. Cuando un agente de IA nos visita, ve algo completamente diferente. Comprender lo que los agentes realmente perciben es la base para crear sitios web que funcionen para ellos.
Las principales plataformas de IA utilizan tres enfoques distintos y las diferencias tienen implicaciones directas sobre cómo debe estructurar su sitio web.
Visión: lectura de capturas de pantalla
El uso de la computadora de Anthropic adopta el enfoque más literal. Claude toma capturas de pantalla del navegador, analiza el contenido visual y decide en qué hacer clic o escribir en función de lo que “ve”. Es un bucle de retroalimentación continuo: captura de pantalla, motivo, acto, captura de pantalla. El agente opera a nivel de píxel, identifica botones por su apariencia visual y lee el texto de la imagen renderizada.
El Proyecto Mariner de Google sigue un patrón similar con lo que Google describe como un ciclo de “observar-planificar-actuar”: observar captura elementos visuales y estructuras de código subyacentes, planificar formula secuencias de acción y actuar simula las interacciones del usuario. Mariner logró una tasa de éxito del 83,5 % en el punto de referencia WebVoyager.
El enfoque de visión funciona, pero es computacionalmente costoso, sensible a los cambios de diseño y limitado por lo que se representa visualmente en la pantalla.
Árbol de accesibilidad: estructura de lectura
OpenAI tomó un camino diferente con ChatGPT Atlas. Las preguntas frecuentes de sus editores y desarrolladores son explícitas:
ChatGPT Atlas utiliza etiquetas ARIA, las mismas etiquetas y roles que admiten lectores de pantalla, para interpretar la estructura de la página y los elementos interactivos.
Atlas se basa en Chromium, pero en lugar de analizar los píxeles renderizados, consulta el árbol de accesibilidad en busca de elementos con funciones específicas (“botón”, “enlace”) y nombres accesibles. Esta es la misma estructura de datos que utilizan los lectores de pantalla como VoiceOver y NVDA para ayudar a las personas con discapacidad visual a navegar por la web.
Playwright MCP de Microsoft, el servidor MCP oficial para la automatización del navegador, adopta el mismo enfoque. Proporciona instantáneas de accesibilidad en lugar de capturas de pantalla, lo que brinda a los modelos de IA una representación estructurada de la página. Microsoft eligió deliberadamente los datos de accesibilidad en lugar de la representación visual para su estándar de automatización del navegador.
Híbrido: ambos a la vez
En la práctica, los agentes más capaces combinan enfoques. El agente de uso de computadoras (CUA) de OpenAI, que impulsa tanto a Operador como a Atlas, analiza capas de captura de pantalla con procesamiento DOM y análisis de árboles de accesibilidad. Prioriza las etiquetas y roles de ARIA, recurriendo al contenido de texto y a los selectores estructurales cuando los datos de accesibilidad no están disponibles.
La investigación de Perplexity confirma el mismo patrón. Su artículo BrowseSafe, que detalla la infraestructura de seguridad detrás del agente de navegador de Comet, describe el uso de “gestión de contexto híbrida que combina instantáneas de árboles de accesibilidad con visión selectiva”.
Plataforma
Enfoque primario
Detalles
Uso antrópico de la computadora
Visión (capturas de pantalla)
Captura de pantalla, motivo, bucle de retroalimentación de acto
Proyecto Marinero de Google
Visión + estructura de código
Observar-planificar-actuar con datos visuales y estructurales
Atlas abierto de IA
Árbol de accesibilidad
Utiliza explícitamente etiquetas y roles ARIA
OpenAI CUA
Híbrido
Capturas de pantalla + DOM + árbol de accesibilidad
Dramaturgo de Microsoft MCP
Árbol de accesibilidad
Instantáneas de accesibilidad, sin capturas de pantalla
Cometa de perplejidad
Híbrido
Árbol de accesibilidad + visión selectiva
El patrón es claro. Incluso las plataformas que comenzaron con enfoques que priorizan la visión están incorporando datos de accesibilidad. Y las plataformas que optimizan la confiabilidad y la eficiencia (Atlas, Playwright MCP) lideran el árbol de accesibilidad.
El árbol de accesibilidad de su sitio web no es un artefacto de cumplimiento. Es cada vez más la interfaz principal que utilizan los agentes para comprender e interactuar con su sitio web.
El año pasado, antes de que entrara en vigor la Ley Europea de Accesibilidad, medio bromeé diciendo que sería irónico que lo que finalmente hiciera que la gente se preocupara por la accesibilidad fueran los agentes de inteligencia artificial, no las personas para las que estaba diseñada la accesibilidad. Eso ya no es una broma.
El árbol de accesibilidad es la interfaz de su agente
El árbol de accesibilidad es una representación simplificada del DOM de su página que los navegadores generan para las tecnologías de asistencia. Donde el DOM completo contiene cada div, span, styley scriptel árbol de accesibilidad elimina el ruido y expone sólo lo que importa: elementos interactivos, sus funciones, sus nombres y sus estados.
Por eso funciona tan bien para los agentes. El DOM de una página típica puede contener miles de nodos. El árbol de accesibilidad lo reduce a los elementos con los que un usuario (o agente) realmente puede interactuar: botones, enlaces, campos de formulario, encabezados, puntos de referencia. Para los modelos de IA que procesan páginas web dentro de una ventana de contexto limitada, esa reducción es significativa.
Las preguntas frecuentes de editores y desarrolladores de OpenAI son muy claras al respecto:
Siga las mejores prácticas de WAI-ARIA agregando roles, etiquetas y estados descriptivos a elementos interactivos como botones, menús y formularios. Esto ayuda a ChatGPT a reconocer lo que hace cada elemento e interactuar con su sitio con mayor precisión.
Y:
Hacer que su sitio web sea más accesible ayuda al agente ChatGPT en Atlas a comprenderlo mejor.
Los datos de la investigación respaldan esto. Los datos más rigurosos al respecto provienen de un estudio de la UC Berkeley y la Universidad de Michigan publicado para CHI 2026, la principal conferencia académica sobre interacción persona-computadora. Los investigadores probaron Claude Sonnet 4.5 en 60 tareas web del mundo real bajo diferentes condiciones de accesibilidad, recopilando 40,4 horas de datos de interacción en 158.325 eventos. Los resultados fueron sorprendentes:
Condición
Tasa de éxito de la tarea
Promedio Tiempo de finalización
Estándar (predeterminado)
78,33%
324,87 segundos
Solo teclado
41,67%
650,91 segundos
Vista ampliada
28,33%
1.072,20 segundos
En condiciones estándar, el agente tuvo éxito casi el 80% de las veces. Restrinjalo a la interacción únicamente con el teclado (simulando cómo navegan los usuarios de lectores de pantalla) y el éxito cae al 42%, lo que lleva el doble de tiempo. Restrinja la ventana gráfica (simulando herramientas de ampliación) y el éxito se reduce al 28%, lo que lleva más de tres veces más tiempo.
El documento identifica tres categorías de brechas:
Brechas de percepción: los agentes no pueden acceder de manera confiable a los anuncios del lector de pantalla o a los cambios de estado de ARIA que les indiquen lo que sucedió después de una acción.
Brechas cognitivas: los agentes tienen dificultades para realizar un seguimiento del estado de la tarea en varios pasos.
Brechas de acción: los agentes infrautilizan los atajos de teclado y fallan en interacciones como arrastrar y soltar.
La implicación es directa. Los sitios web que presentan un árbol de accesibilidad rico y bien etiquetado brindan a los agentes la información que necesitan para tener éxito. Los sitios web que dependen de señales visuales, estados de desplazamiento o interacciones complejas de JavaScript sin alternativas accesibles crean las condiciones para que el agente falle.
El documento sobre arquitectura de la API de búsqueda de Perplexity de septiembre de 2025 refuerza esto desde el punto de vista del contenido. Su sistema de indexación prioriza el contenido que sea “de alta calidad tanto en fondo como en forma, con información capturada de una manera que preserve la estructura y el diseño del contenido original”. Los sitios web “con muchos datos bien estructurados en forma de lista o tabla” se benefician de “reglas de análisis y extracción más formuladas”. La estructura no sólo es útil. Es lo que hace posible un análisis confiable.
HTML semántico: la base del agente
El árbol de accesibilidad se construye a partir de su HTML. Utilice elementos semánticos y el navegador generará automáticamente un árbol de accesibilidad útil. Sáltelos y el árbol será escaso o engañoso.
Este no es un consejo nuevo. Los defensores de los estándares web han estado gritando “use HTML semántico” durante dos décadas. No todos escucharon. La novedad es que la audiencia se ha ampliado. Solía tratarse de lectores de pantalla y de un porcentaje relativamente pequeño de usuarios. Ahora se trata de cada agente de IA que visita su sitio web.
Utilice elementos nativos. A El elemento aparece automáticamente en el árbol de accesibilidad con la función “botón” y su contenido de texto como nombre accesible. A
does not. The agent doesn’t know it’s clickable.
Search flights
Etiquete sus formularios. Cada entrada necesita una etiqueta asociada. Los agentes leen las etiquetas para comprender qué datos espera un campo.
El autocomplete atributo merece atención. Les dice a los agentes (y a los navegadores) exactamente qué tipo de datos espera un campo, utilizando valores estandarizados como name, email, tel, street-addressy organization. Cuando un agente llena un formulario en nombre de alguien, autocomplete Los atributos marcan la diferencia entre un mapeo de campo seguro y una conjetura.
Establecer jerarquía de encabezados. Usar h1 a través de h6 en orden lógico. Los agentes utilizan encabezados para comprender la estructura de la página y ubicar secciones de contenido específicas. Saltar niveles (saltar de h1 a h4) crean confusión sobre las relaciones de contenido.
Utilice regiones emblemáticas. Elementos emblemáticos HTML5 (
, ,
,
,
) informa a los agentes dónde se encuentran en la página. A
El elemento es inequívocamente navegación. A
requires interpretation. Clarity for the win, always.
Los agentes de prueba Playwright de Microsoft, presentados en octubre de 2025, generan código de prueba que utiliza selectores accesibles de forma predeterminada. Cuando la IA genera una prueba de Dramaturgo, escribe:
const todoInput = page.getByRole('textbox', { name: 'What needs to be done?' });
No selectores de CSS. No XPath. Roles y nombres accesibles. Microsoft creó sus herramientas de prueba de inteligencia artificial para encontrar elementos de la misma manera que lo hacen los lectores de pantalla, porque es más confiable.
La última diapositiva de mi discurso de apertura de Conversion Hotel sobre la optimización de sitios web para agentes de IA. (Crédito de la imagen: Slobodan Manic)
ARIA: útil, no mágica
OpenAI recomienda ARIA (Aplicaciones de Internet enriquecidas accesibles), el estándar W3C para hacer accesible el contenido web dinámico. Pero ARIA es un complemento, no un sustituto. Como los batidos de proteínas: útiles además de una dieta real, contraproducentes como sustituto de la comida real.
La primera regla de ARIA, según la define el W3C:
Si puede utilizar un elemento o atributo HTML nativo con la semántica y el comportamiento que necesita ya integrados, en lugar de reutilizar un elemento y agregar una función, estado o propiedad ARIA para hacerlo accesible, hágalo.
El hecho de que el W3C haya tenido que hacer de “no usar ARIA” la primera regla de ARIA te dice todo sobre la frecuencia con la que se usa mal.
Adrian Roselli, un reconocido experto en accesibilidad web, planteó una preocupación importante en su análisis de octubre de 2025 sobre la guía de OpenAI. Sostiene que recomendar ARIA sin suficiente contexto corre el riesgo de fomentar el uso indebido. Los sitios web que utilizan ARIA son generalmente menos accesibles según la encuesta anual de WebAIM de los millones de sitios web más importantes, porque ARIA a menudo se aplica incorrectamente como una curita sobre una estructura HTML deficiente. Roselli advierte que la guía de OpenAI podría incentivar prácticas como el relleno de palabras clave en aria-label atributos, el mismo tipo de juego que plagaba las meta palabras clave en los inicios del SEO.
El enfoque correcto tiene varias capas:
Comience con HTML semántico. Usar , , , y otros elementos nativos. Estos funcionan correctamente de forma predeterminada.
Agregue ARIA cuando el HTML nativo no sea suficiente. Los componentes personalizados que no tienen equivalentes HTML (paneles de pestañas, vistas de árbol, widgets de divulgación) necesitan roles y estados ARIA para ser comprensibles.
Utilice estados ARIA para contenido dinámico. Cuando JavaScript cambia la página, los atributos ARIA comunican lo que sucedió:
Mantener aria-label descriptivo y honesto. Úselo para proporcionar contexto que no es visible en la pantalla, como distinguir entre varios botones "Eliminar" en la misma página. No lo rellenes con palabras clave.
El principio es el mismo que se aplica a un buen SEO: construir para el usuario primero, optimizar para el sistema después. El HTML semántico se construye para el usuario. ARIA está realizando ajustes para casos extremos en los que HTML se queda corto.
La cuestión del renderizado
Los agentes basados en navegador, como la navegación automática de Chrome, ChatGPT Atlas y Perplexity Comet, se ejecutan en Chromium. Ejecutan JavaScript. Pueden representar su aplicación de una sola página.
Pero no todo lo que visita su sitio web es un agente de navegador completo.
Los rastreadores de IA (PerplexityBot, OAI-SearchBot, ClaudeBot) indexan su contenido para recuperarlo y citarlo. Muchos de estos rastreadores no ejecutan JavaScript del lado del cliente. Si tu página está en blanco Hasta que React se hidrata, estos rastreadores ven una página vacía. Su contenido es invisible para el ecosistema de búsqueda de IA.
La parte 2 de esta serie cubrió el lado de las citas: los sistemas de inteligencia artificial seleccionan fragmentos del contenido indexado. Si su contenido no está en el HTML inicial, no está en el índice. Si no está en el índice, no se cita. La renderización del lado del servidor no es sólo una optimización del rendimiento.
Es un requisito de visibilidad.
Incluso para los agentes de navegador completos, los sitios web con mucho JavaScript crean fricciones. El contenido dinámico que se carga después de las interacciones, el desplazamiento infinito que nunca indica que se ha completado y los formularios que se reconstruyen después de cada entrada crean oportunidades para que los agentes pierdan la noción del estado. La investigación de A11y-CUA atribuyó parte del fracaso de los agentes a “lagunas cognitivas”: los agentes pierden la noción de lo que sucede durante interacciones complejas de varios pasos. Una renderización más simple y predecible reduce estos fallos.
La guía de Microsoft de la Parte 2 se aplica aquí directamente: "No oculte respuestas importantes en pestañas o menús expandibles: es posible que los sistemas de inteligencia artificial no muestren contenido oculto, por lo que se pueden omitir detalles clave". Si la información es importante, colóquela en el HTML visible. No requiere interacción para revelarlo.
Prioridades prácticas de renderizado:
Renderizado del lado del servidor o páginas de contenido pre-renderizado. Si un rastreador de IA no puede verlo, no existe en el ecosistema de IA.
Evite SPA en blanco para páginas de contenido. Marcos como Next.js (que impulsa este sitio web), Nuxt y Astro hacen que SSR sea sencillo.
No oculte información crítica detrás de las interacciones. Los precios, las especificaciones, la disponibilidad y los detalles clave deben estar en el HTML inicial, no detrás de acordeones o pestañas.
Usar estándar enlaces para la navegación. Enrutamiento del lado del cliente que no actualiza la URL ni utiliza onClick Los controladores en lugar de enlaces reales interrumpen la navegación del agente.
Probando la interfaz de su agente
No enviarías un sitio web sin probarlo en un navegador. Probar cómo los agentes perciben su sitio web se está volviendo igualmente importante.
La prueba del lector de pantalla es el mejor proxy. Si VoiceOver (macOS), NVDA (Windows) o TalkBack (Android) pueden navegar por su sitio web correctamente, identificar botones, leer etiquetas de formularios y seguir la estructura del contenido, es probable que los agentes puedan hacer lo mismo. Ambas audiencias dependen del mismo árbol de accesibilidad. Este no es un proxy perfecto (los agentes tienen capacidades que los lectores de pantalla no tienen, y viceversa), pero detecta la mayoría de los problemas.
Playwright MCP de Microsoft proporciona instantáneas de accesibilidad directa. Si desea ver exactamente lo que ve un agente de IA, Playwright MCP genera instantáneas de accesibilidad estructuradas de cualquier página. Estas instantáneas eliminan la presentación visual y muestran las funciones, nombres y estados con los que trabajan los agentes. Publicado como @playwright/mcp En npm, es la forma más directa de ver su sitio web a través de los ojos de un agente.
Si sus elementos interactivos críticos no aparecen en la instantánea o aparecen sin nombres útiles, los agentes tendrán problemas con su sitio web.
Stagehand de Browserbase (v3, lanzado en octubre de 2025 y humildemente autodescrito como “el mejor marco de automatización de navegadores”) ofrece otro ángulo. Analiza tanto el DOM como los árboles de accesibilidad, y su ejecución de autorreparación se adapta a los cambios del DOM en tiempo real. Es útil para probar si los agentes pueden completar flujos de trabajo específicos en su sitio web, como completar un formulario o completar un pago.
El navegador Lynx Es una opción de baja tecnología que vale la pena probar. Es un navegador de sólo texto que elimina toda representación visual y muestra aproximadamente lo que analiza un agente no visual. Un truco que aprendí de Jes Scholz en el podcast.
Un flujo de trabajo de prueba práctico:
Ejecute VoiceOver o NVDA a través de los flujos de usuarios clave de su sitio web. ¿Puedes completar las tareas principales sin visión?
Genere instantáneas de accesibilidad de Playwright MCP de páginas críticas. ¿Los elementos interactivos están etiquetados e identificables?
Vea la fuente de su página. ¿El contenido principal está en HTML o requiere JavaScript para renderizarse?
Cargue su página en Lynx o desactive CSS y compruebe si el orden y la jerarquía del contenido aún tienen sentido. Los agentes no ven su diseño.
Una lista de verificación para su equipo de desarrollo
Si comparte este artículo con sus desarrolladores (y debería hacerlo), aquí está la lista de implementación priorizada. Ordenados por impacto y esfuerzo, comenzando con los cambios que afectan la mayoría de las interacciones de los agentes con el menor trabajo.
Alto impacto, bajo esfuerzo:
Utilice elementos HTML nativos. para acciones, para enlaces, para menús desplegables. Reemplazar
patterns wherever they exist.
Label every form input. Associate elementos con entradas usando el for atributo. Agregar autocomplete atributos con valores estándar.
Representación de páginas de contenido del lado del servidor. Asegúrese de que el contenido principal esté en la respuesta HTML inicial.
Alto impacto, esfuerzo moderado:
Implementar regiones emblemáticas. Envolver contenido en , , y elementos. Agregar aria-label cuando existen varios puntos de referencia del mismo tipo en la misma página.
Arreglar la jerarquía de encabezados. Asegurar un solo h1con h2 a través de h6 en orden lógico sin saltar niveles.
Saque el contenido crítico de los contenedores ocultos. Los precios, las especificaciones y los detalles clave no deberían requerir clics ni interacciones para revelarse.
Impacto moderado, esfuerzo bajo:
Agregue estados ARIA a componentes dinámicos. Usar aria-expanded, aria-controlsy aria-hidden para menús, acordeones y conmutadores.
Utilice texto de enlace descriptivo. "Lea el informe completo" en lugar de "Haga clic aquí". Los agentes utilizan el texto del enlace para comprender adónde conducen los enlaces.
Pruebe con un lector de pantalla. Hágalo parte de su proceso de control de calidad, no una auditoría única.
Conclusiones clave
Los agentes de IA perciben los sitios web a través de tres enfoques: visión, análisis DOM y árbol de accesibilidad. La industria está convergiendo en el árbol de accesibilidad como el método más confiable. OpenAI Atlas, Microsoft Playwright MCP y Perplexity's Comet se basan en datos de accesibilidad.
La accesibilidad web ya no se trata sólo de cumplimiento. El árbol de accesibilidad es la interfaz literal que utilizan los agentes de IA para comprender su sitio web. El estudio de UC Berkeley/Universidad de Michigan muestra que las tasas de éxito de los agentes caen significativamente cuando las funciones de accesibilidad están limitadas.
El HTML semántico es la base. Elementos nativos como , , y Crea automáticamente un árbol de accesibilidad útil. No se requiere marco. No se necesita ARIA para lo básico.
ARIA es un complemento, no un sustituto. Úselo para estados dinámicos y componentes personalizados. Pero comience con HTML semántico y agregue ARIA sólo cuando los elementos nativos se queden cortos. El mal uso de ARIA hace que los sitios web sean menos accesibles, no más.
La representación del lado del servidor es un requisito de visibilidad del agente. Los rastreadores de IA que no ejecutan JavaScript no pueden ver el contenido de los SPA de shell en blanco. Si su contenido no está en el HTML inicial, no existe en el ecosistema de IA.
Las pruebas de lectores de pantalla son el mejor proxy para la compatibilidad de los agentes. Si VoiceOver o NVDA pueden navegar por su sitio web, los agentes probablemente también puedan hacerlo. Para una inspección directa, las instantáneas de accesibilidad de Playwright MCP muestran exactamente lo que ven los agentes.
Las primeras tres partes de esta serie cubrieron por qué es importante el cambio, cómo ser citado y qué protocolos se están creando. Este artículo cubrió la capa de implementación. La noticia alentadora es que no se trata de flujos de trabajo separados. Los sitios web accesibles y bien estructurados funcionan mejor para los humanos, se clasifican mejor en las búsquedas, la IA los cita con más frecuencia y funcionan mejor para los agentes. Es la misma obra al servicio de cuatro públicos.
Y la obra se construye sobre sí misma. El HTML semántico y los datos estructurados que se tratan aquí son exactamente en lo que se basa WebMCP para su enfoque de forma declarativa. El árbol de accesibilidad que su sitio web expone hoy se convierte en la base de las interfaces de herramientas estructuradas del mañana.
A continuación en la Parte 5: la capa de comercio. Cómo Stripe, Shopify y OpenAI están construyendo la infraestructura para que los agentes de IA completen compras y qué significa esto para su flujo de pago.
Más recursos:
Esta publicación se publicó originalmente en No Hacks.
Imagen de portada: Collagery/Shutterstock
Slobodan maníaco Anfitrión del podcast No Hacks y consultor de optimización web para máquinas en No Hacks
Slobodan “Sani” Manić es un consultor de optimización de sitios web con más de 15 años de experiencia ayudando a empresas a hacer sus sitios más rápidos,...
