TL;DR: Los agentes de IA leen tu sitio a través de tres lentes distintas (capturas de pantalla, DOM sin procesar y árbol de accesibilidad), y la mayoría de los sitios les resultan, sin quererlo, hostiles en las tres. Las soluciones se solapan con el trabajo de accesibilidad y Core Web Vitals que ya deberías tener en marcha. A continuación verás un orden de prioridades, una auditoría de 5 minutos y un bucle de medición que puedes poner en marcha hoy mismo.
Hace unas semanas estaba construyendo nuestra herramienta “agent-ready”. La idea era alimentar sitios reales de clientes a un agente basado en Playwright y observar cómo intentaba usarlos. Así que lo apunté a nuestra propia página de inicio —la que he publicado mil veces— y le pedí que encontrara la sección de precios.
Hizo clic en el CTA equivocado. Después intentó pulsar un botón que no era un botón (un <div> con estilo que montamos deprisa y corriendo). Al final se rindió y me preguntó dónde estaban los precios.
El caso es que yo sabía que nuestro sitio tenía estados hover que revelaban la navegación secundaria. Un humano mueve el cursor, aparece el menú y asunto resuelto. El agente trabajaba con una sola captura del estado inactivo. No había cursor que mover. Para él, la navegación solo-hover literalmente no existía.
Aquel día dejé de pensar en los agentes de IA como rastreadores más inteligentes y empecé a verlos como un tipo nuevo de visitante con limitaciones extrañas. (Nota aparte: durante meses di por hecho que funcionaban como Googlebot con pasos extra. Estuve equivocado los primeros seis meses del año pasado). Lo que sigue es lo que he aprendido desde entonces, sobre todo rompiendo cosas y viendo cómo reaccionaban los agentes.
Un agente de IA que aterriza en tu home no está rastreando para un índice de búsqueda. Intenta hacer el encargo que le dio un humano: reservar un vuelo, comparar planes, añadir algo al carrito. Tiene minutos, no horas. Y cada clic erróneo le cuesta al usuario dinero en tokens de inferencia.
Esto cambia el problema de diseño. Un bot de búsqueda puede fallar en silencio y tú ni te enteras. Un agente falla en público, delante de un usuario de pago, y la próxima vez que ese usuario quiera lo mismo le pedirá al agente que se salte tu sitio. Los buscadores con IA empiezan a comportarse igual: si su crawler no logra extraer una respuesta fiable de tu página, la respuesta se la lleva quien sí sea legible. Los clics que antes venían del SERP se sustituyen por citaciones en un resumen de IA, y esas citaciones se ganan con legibilidad, no con presupuesto publicitario.
Para una explicación más extensa sobre la IA como canal de descubrimiento, el pilar silo en ask engine optimization cubre directamente el lado de la búsqueda. Este artículo trata la otra mitad: qué pasa cuando un agente intenta usar tu sitio.
Esto es lo que me habría gustado que alguien me explicara hace un año. No hay una sola manera de ver las páginas web: hay tres, y los grandes proveedores las combinan de forma distinta.
«Los agentes pueden ver tu web de 3 formas principales: capturas de pantalla, HTML sin procesar y el árbol de accesibilidad. El árbol de accesibilidad es una API nativa del navegador que destila el DOM en lo más importante: roles, nombres y estados de los elementos interactivos. Para un agente de IA funciona como un mapa de alta fidelidad que ignora el “ruido” visual del CSS y se centra en la pura utilidad».
— Kasper Kulikowski & Omkar More, web.dev: Build agent-friendly websites
Así se reparte hoy, a principios de 2026. El computer-use de Anthropic usa solo capturas. Claude ve una imagen de 1024×768, razona en coordenadas de píxel y ordena mover el ratón. No hay DOM de entrada por parte de Anthropic. Operator (CUA) de OpenAI superpone capturas con datos de DOM y del árbol de accesibilidad, aunque su propia documentación destaca el bucle de captura y la parte DOM aparece sobre todo en ingeniería inversa de terceros. Project Mariner de Google lee píxeles y DOM subyacente. Los frameworks basados en Playwright, como browser-use, priorizan el árbol de accesibilidad y solo recurren a capturas si aquello falla.
La economía importa más que la arquitectura. Una instantánea del árbol de accesibilidad de una página típica pesa entre 2 y 5 KB. La captura de pantalla de esa misma página supera fácilmente los 100 KB. Es un coste por paso de inferencia de 20× a 50×. Los agentes que pueden leer el árbol de accesibilidad tienen incentivos fuertes para hacerlo. Los sitios que generan un árbol limpio se usan. Los que no, reciben capturas caras, más fallos y, con el tiempo, se omiten.
Puedes ver ahora mismo el árbol de accesibilidad de tu sitio. Abre Chrome DevTools, ve a la pestaña Accessibility y marca “Enable full accessibility tree”. Eso es, más o menos, lo que extraerá un agente como browser-use. Chrome oculta por defecto los nodos ignorados y los nodos genéricos sin nombre; útil, porque esos son justo los elementos con los que los agentes tropiezan.
Las citaciones son los nuevos clics, al menos para ciertas consultas. Según el análisis cruzado de Profound, Wikipedia representa el 47,9 % del top-10 de fuentes en ChatGPT; Reddit, el 21 % de Google AI Overviews y el 46,7 % de Perplexity. Los porcentajes cambian sin parar (por ejemplo, Leapd registró que la cuota de Reddit en ChatGPT cayó del 60 % al 10 % en seis semanas tras un único parámetro de Google), pero la dirección es clara: los motores con IA premian el contenido que pueden parsear con confianza y descartan el resto.
«Algunos LLM, como ChatGPT y Claude, no ejecutan JavaScript (a diferencia de Gemini), lo que hace que el renderizado del lado del servidor (SSR) sea crítico para que el contenido importante aparezca en sus respuestas».
— Aleyda Solis, AI Search: Where Are We & What Can We Do About It?
Esa frase es más concreta que la mayoría del consejo IA-SEO que he leído. Si tu contenido importante se renderiza del lado del cliente, ChatGPT y Claude no lo ven. Gemini sí. Te guste o no, es un requisito técnico falsable, no cuestión de “vibras”. Nuestro artículo the AI crawler playbook profundiza en qué crawlers ejecutan JavaScript y cuáles no.
Voy a ser sincero con lo que no sabemos. No hay un estudio público que correlacione directamente puntuaciones de accesibilidad con tasas de citación en IA. El mecanismo es defendible (el árbol de accesibilidad es la misma estructura que consumen agentes y lectores de pantalla), pero el vínculo empírico aún no está probado. El mejor dato adyacente viene del resumen de accessibility.works sobre un estudio de 10 000 sitios que halló que los sitios conformes a WCAG recibían un 23 % más de tráfico orgánico y posicionaban para un 27 % más de palabras clave que sus pares no conformes. La metodología está poco documentada (sin nivel de conformidad especificado, sin revisión por pares), así que lo tomo como indicio, no como prueba sólida.
Verás muchos listicles de “8 cosas” en este tema. La lista es útil para organizar; deja de serlo cuando tratas las ocho como igual de importantes. No lo son. Aquí la comparación.
| Señal | Lo que ve un agente si lo haces bien | Lo que se rompe si lo haces mal | Esfuerzo |
|---|---|---|---|
| Elementos semánticos nativos | <button>, <a>, <h1> aparecen en el árbol a11y con roles implícitos |
Botones estilo <div> desaparecen del árbol a11y |
Bajo |
| Nombres accesibles en inputs | "input, type=email, label='Dirección de correo'" | "input, type=text" (el placeholder no genera nombre) | Bajo |
| Objetivos interactivos visibles | Botones > ~8 px² (mínimo empírico de web.dev) e idealmente 24×24 px CSS (WCAG 2.5.8 AA) | Los modelos de visión filtran objetivos pequeños; los agentes por coordenadas los fallan | Bajo |
| Layout estable (bajo CLS) | Las coordenadas caen en el elemento correcto | Imágenes lazy-load desplazan la página; el agente hace clic donde no toca | Medio |
| Contenido renderizado en servidor | ChatGPT y Claude ven el HTML completo al primer fetch | Contenido solo hidratado es invisible para crawlers sin JS | Medio-Alto |
| Jerarquía de headings | Un <h1>, <h2>/<h3> anidados con roles implícitos |
Headings visuales como <p> = sin esquema de documento |
Bajo |
| Sin overlays fantasmas / focus traps | Los clics llegan al elemento visible | Capas transparentes se tragan los clics; el agente no puede recuperarse | Medio |
| URLs y formularios predecibles | El agente retoma tras navegar; los campos se describen solos | Rutas SPA que tragan history confunden tareas multipasos | Medio |
Dos señales mandan. Elementos semánticos nativos y nombres accesibles son la base. Si fallas ahí, lo demás da igual. En los pocos cientos de sitios que hemos pasado por nuestro check “agent-ready” desde el lanzamiento, el fallo más común es exactamente este: un CTA construido como <div> con estilo, que luego desaparece del árbol de accesibilidad. Aproximadamente la mitad de las home auditadas tiene al menos uno. El suelo de 8 px² que mencioné (de web.dev) es empírico, no un límite duro de arquitectura; los codificadores de visión para modelos tipo CLIP usan parches de 14×14 o 16×16 px, un suelo aún mayor. Tómalo como mínimo sensato, no como número mágico.
Esto casi nunca lo veo en otros artículos de agent-readiness. La mayoría te suelta una checklist de 8 a 30 cosas y te apañas. Esto es lo que hago realmente cuando tengo 5 minutos entre reuniones.
Minuto 1. Ejecuta nuestro agent-ready check gratuito. Alimenta tu home a un agente Playwright y devuelve cosas como un <div role="button"> sin tabindex, un input oculto que atrapa el foco o un CTA que el agente vio en la captura pero no encontró en el árbol a11y. Es la herramienta que Lida y yo lanzamos tras el momento “GPT no ve estados hover” (discrepamos en cuándo —ella quería datos más limpios; yo publiqué la versión tosca). Es gratis y no pide email.
Minuto 2. Abre tu sitio en Chrome, DevTools, pestaña Accessibility, árbol completo. Busca nodos con role "generic" y sin nombre. Cada uno es un lugar donde el agente tiene que adivinar.
Minuto 3. Pasa el vibe-coded scanner a la misma URL. Es un escáner de calidad de código que hicimos para cazar patrones que Cursor, Copilot y Lovable generan por defecto: <div onClick> como botón, labels que faltan, headings disfrazados de párrafo. (Lo hice porque la mitad de los sitios que auditamos ya los genera IA y estas aún no aprenden HTML semántico).
Minuto 4. Ejecuta una auditoría Lighthouse. Apunta el CLS. Por encima de 0,1 es límite; por encima de 0,25 rompe clics de agentes con regularidad. Anota también la puntuación de accesibilidad: el mismo informe detecta labels faltantes y problemas de contraste que afectan a lectores de pantalla y agentes.
Minuto 5. Elige el peor problema único de esos cuatro informes y anótalo. Mañana, arregla solo eso. No intentes arreglar la lista entera.
Cinco minutos es el presupuesto real que tiene la mayoría de responsables de marketing. Si tienes más, genial: profundiza. Si no, este bucle basta para sacar a la superficie el mayor problema de tu sitio, que suele ser todo lo que necesitas saber.
Tres patrones causan la mayoría de fallos que veo. El primero es el <div> estilizado como botón. Parece un botón, tiene estado hover, dispara onClick, pero para el árbol de accesibilidad no es un botón.
«No uses un
<div>,<span>u otro elemento no interactivo. Si no puedes llegar a él con el tabulador, probablemente sea una pésima idea usarlo».— Adrian Roselli, Links, Buttons, Submits, and Divs, Oh Hell
Roselli escribió eso en 2016, una década antes de que alguien dijera “agente de IA” en este contexto. La heurística de “tab con teclado” que describe se traslada perfecta a la legibilidad para agentes: si el teclado no llega, el árbol a11y no lo expone y un agente Playwright no lo ve. La factura por una década de botones div estilizados está llegando.
El segundo patrón es la inestabilidad de layout. Lo vimos mucho en nuestra migración de .io a .com. Algunas imágenes hero lazy-load del lado .com desplazaban el botón “Get started” 40 px unos 800 ms después del render inicial. Para humanos casi imperceptible. Los agentes Playwright identificaban el botón en la posición original, esperaban un beat y hacían clic en el hueco vacío. No es hipotético: issue #6238 de Playwright documenta layout shift por lazy-load que provoca clics en el elemento equivocado y sigue abierto. Lighthouse CLS es mi proxy de confianza: por encima de 0,1 sospechoso.
El tercer patrón son los overlays fantasma. Banners de cookies que no se cierran de verdad, pop-ups GDPR con backdrops transparentes que quedan tras cerrar el modal, widgets de intercom flotando a z-index 9999 sobre tu CTA. Todos interceptan clics que el agente pensaba dirigir a algo visible debajo. Web.dev los señala explícitamente y nuestro vibe-coded scanner los marca.
«Estos dispositivos dependen del árbol de accesibilidad —el mecanismo que los ordenadores usan para que la tecnología asistiva lea e interprete programáticamente el contenido de la interfaz de usuario— para funcionar. Al basarnos en marcado bien soportado y probado, hacemos nuestro trabajo versátil y robusto».
— Eric Bailey, Truths about digital accessibility
Bailey escribió eso en 2019, hablando de lectores de pantalla y AT en general. Lo que no paro de retener es “el mecanismo que los ordenadores usan”. Definió el árbol de accesibilidad como una interfaz programática para máquinas, no solo para humanos con discapacidad. La llegada de los agentes de IA colapsa lo que antes eran tres trabajos (accesibilidad, rastreabilidad SEO, legibilidad para agentes) en uno: producir una descripción legible por máquina de lo que hace tu interfaz.
Encontrarás un tratamiento más amplio del lado SEO de esta convergencia en nuestro pilar de accesibilidad para SEO. La versión corta: los mismos arreglos (HTML semántico, nombres accesibles, layout estable) mueven tres métricas a la vez.
Si no haces nada más de este artículo, haz esto en este orden.
<div>/<span> por <button>. Máximo apalancamiento, mínimo coste. Pasa de “invisible” a “visible” en agentes a11y-first como browser-use, Mariner y crawlers Playwright.<label for> a cada input. El placeholder no es un nombre accesible. Si el campo email de tu formulario no tiene label, el agente ve un input sin nombre, punto.<h1> por página. <h2> para secciones. No estilices un <p> como heading.
He visto equipos pasar dos semanas publicando un llms.txt antes de arreglar su botón div de checkout. Ese orden está del revés.
Has publicado los cambios. Y ahora qué.
Para la estabilidad de layout, la auditoría Lighthouse es la medición fiable más barata. Ejecútala antes y después sobre la misma URL y observa cómo se mueven CLS, accesibilidad e INP. (Cuando limpiamos los botones
Para la legibilidad por agentes, vuelve a lanzar el agent-ready check. El informe da una puntuación de parseabilidad y lista los CTAs que el agente pudo y no pudo alcanzar. La métrica que miro es “CTAs identificados con éxito”: si no es 100 %, el agente aún adivina en algún sitio.
Para las citaciones de IA (el resultado SEO que de verdad te importa), usa nuestro backlink checker para rastrear menciones en resúmenes de IA. Las citaciones de ChatGPT, Perplexity y AI Overviews se parecen a backlinks, solo que de nuevas fuentes. Si tus arreglos funcionan, las verás aparecer en semanas, no días. Nuestra metodología de auditoría de visibilidad IA cubre la medición a bucle lento.
Quiero señalar la estadística de Wil Reynolds que se repite mucho vía Orbit Media: «0,8 % del tráfico, 10 % de los leads». Es un dato real y útil, pero proviene de una sola empresa en una ventana concreta, y el propio Reynolds ha dejado claro que no es multiplicador universal. Yo lo tomo como evidencia de que el tráfico IA convierte por encima de su peso, no como multiplicador para previsiones. Si tu tráfico IA convierte 5× tu media orgánica, enhorabuena. Si no, ese multiplicador no va contigo.
WebMCP es la especificación a vigilar. Permite a un sitio registrar herramientas JavaScript que los agentes de IA pueden invocar directamente, convirtiendo la página en un servidor Model Context Protocol. Chrome 146 Canary añadió un preview tras bandera. Edge 147 añadió soporte en marzo 2026. El draft del Community Group de W3C se publicó el 23-04-2026.
Me gusta. También soy realista con los plazos. El propio spec avisa: «No es un estándar W3C ni está en el track de estándares». Ningún gran proveedor LLM ha documentado consumir WebMCP aún. Los datos de crawl de Cloudflare encontraron menos de 15 sitios globales con MCP Server Cards. Hablaríamos de 2 a 5 años, siendo optimistas.
«El navegador web está diseñado para usuarios humanos y desarrolladores, no para sistemas de IA agente. La mayor parte del contenido está estructurado para consumo visual, no programático, con elementos dinámicos, layouts complejos y componentes interactivos que resisten un parseo sencillo».
— Cobus Greyling, The Future of Web Browsing AI Agents
Greyling argumenta que la checklist agent-friendly (este artículo, básicamente) es un parche para un desajuste arquitectónico más profundo que estándares como WebMCP intentan resolver. Puede que tenga razón. No sé si WebMCP será el estándar ganador, si lo será llms.txt o NLWeb de Microsoft, o si aparecerá algo nuevo que absorba a los tres. Lo que sí sé es que la pirámide de prioridades anterior es el trabajo que hay que hacer ahora, mientras la capa de estándares se decanta. Nuestra visión de hacia dónde va esto está en agentic SEO workflows.
Un sitio que los agentes de IA (Claude computer-use, OpenAI Operator, Project Mariner, crawlers Playwright) pueden leer y usar de forma fiable, además de las personas. El requisito central es que los elementos interactivos se expongan de forma clara vía el árbol de accesibilidad del navegador, el layout no se desplace mientras el agente trabaja y el contenido importante se renderice en servidor para que los crawlers sin JavaScript lo lean.
Usan una o varias de tres vías de entrada: capturas de pantalla, HTML sin procesar o el árbol de accesibilidad. Los agentes solo-captura (computer-use de Anthropic) razonan en píxeles y pierden objetivos menores de 8 px² empíricos. Los agentes con DOM (Project Mariner, Operator) superponen datos de elementos. Los agentes a11y-first (browser-use, la mayoría de crawlers Playwright) obtienen un mapa estructural limpio, pero pierden todo lo que no se expone semánticamente.
Bing ha confirmado que schema ayuda a Copilot a entender el contenido. Google reconoce que los datos estructurados dan ventaja en resultados de búsqueda. La evidencia directa de que schema eleve las citaciones IA es mixta: un estudio no vio correlación; otro vio que schema rico en atributos producía un 61,7 % de citaciones. Trátalo como ayuda para la búsqueda IA, no como multiplicador garantizado.
Es un formato propuesto (similar a robots.txt) que indica a los crawlers IA dónde encontrar tu contenido importante de forma limpia. Más de 844 000 sitios lo habían publicado en octubre 2025. La adopción es alta, el consumo bajo: John Mueller y Gary Illyes de Google han dicho que ningún gran sistema IA lo usa como señal operativa. Publicarlo vale si tienes 10 minutos libres; no vale la pena priorizarlo sobre arreglar tus botones div.
El camino más rápido es una auditoría de 5 minutos: ejecuta nuestro agent-ready check, abre la pestaña Accessibility de DevTools, pasa Lighthouse y ejecuta un escaneo de calidad con vibe-coded. Entre los cuatro afloran el problema más grande de tu sitio. Arregla el peor antes de ir al siguiente.
Los agentes de IA leen tu sitio mediante capturas, DOM y árbol de accesibilidad, en proporciones que varían por proveedor. La mayoría de las correcciones son arreglos de accesibilidad que ya deberías hacer: elementos semánticos nativos, nombres accesibles, layout estable, contenido renderizado en servidor. La capa de estándares (WebMCP, llms.txt, NLWeb) es real pero lenta; los arreglos poco glamorosos son urgentes.
Ejecuta nuestro agent-ready check gratuito y averigua qué tan legible es tu sitio para ChatGPT, Claude y Perplexity. Te dirá qué CTAs se perdió el agente, qué botones desaparecieron del árbol de accesibilidad y qué desplazamientos de layout están robando clics. Es la herramienta que habría querido el día que GPT no vio nuestros estados hover.
no credit card required
No related articles found.