Google acaba de publicar en su portal para desarrolladores una lista de siete reglas para hacer webs más navegables por agentes de inteligencia artificial. La novedad tiene truco: según el análisis publicado por el consultor Slobodan Manic en Search Engine Journal el 12 de junio de 2026, esas siete reglas son prácticamente las mismas que llevan dos décadas recogidas en las guías de accesibilidad web WCAG. La diferencia ahora es que Google les pone su nombre encima, y eso cambia el peso que tienen en el sector.
Qué dice exactamente Google en su checklist para agentes de IA
El artículo original fue publicado en web.dev/articles/ai-agent-site-ux por Kasper Kulikowski y Omkar More, y recogido después en Search Engine Journal. Según los datos facilitados por la fuente, Google introduce la lista con la frase «para ayudar a los agentes a navegar tu web, considera seguir:». Es decir, se trata de recomendaciones, no de obligaciones, y el artículo no vincula estas reglas con el posicionamiento ni con ningún producto concreto de Google.
Las siete reglas que recoge la fuente son las siguientes:
- Reflejar cada acción en la interfaz: un clic en un botón debe producir un cambio de estado visible.
- Mantener la maquetación estable: los elementos deben aparecer siempre en el mismo sitio entre páginas.
- Eliminar capas transparentes: cualquier overlay invisible que tape un elemento interactivo lo vuelve inaccesible para el agente.
- Usar HTML semántico: mejor
<button>y<a>que<div>y<span>estilizados. - Añadir
cursor: pointeren CSS: según la fuente, Google lo describe como «una señal fuerte de que el elemento es accionable». - Vincular
<label>a<input>con el atributofor: para que el agente pueda asociar el texto visible al campo correspondiente. - Hacer los elementos interactivos más grandes de 8 píxeles cuadrados: los modelos de visión artificial filtran todo lo que quede por debajo de ese umbral.
De acuerdo con el análisis de la fuente, cinco de estas siete reglas tienen un equivalente directo en criterios WCAG, el estándar internacional de accesibilidad web que llevan años aplicando los equipos de desarrollo orientados a usuarios con discapacidad visual o motriz. La conclusión que se desprende es clara: quien ya hizo ese trabajo está muy cerca de cumplir los requisitos para agentes de IA.
La conexión entre accesibilidad e inteligencia artificial no es nueva, pero sí el respaldo de Google
Según los datos facilitados por la fuente, el interés de búsqueda global por el término «web accessibility» se cuadruplicó en apenas 18 meses, entre finales de 2025 y principios de 2026. Lo curioso es que la curva apenas se movió cuando entró en vigor la Ley Europea de Accesibilidad (EAA) el 28 de junio de 2025, un evento regulatorio que, en teoría, debería haber sido el gran impulso.
Lo que parece haber acelerado el interés, de acuerdo con la fuente, es la convergencia entre el público que busca guías de accesibilidad y el que busca cómo preparar sus webs para agentes de IA. El propio artículo de Google termina con una frase que la fuente destaca: «todo lo que sugerimos para hacer un sitio ‘listo para agentes’ también mejora los sitios para los humanos». No es un detalle menor: es la misma filosofía que lleva años defendiendo la comunidad de accesibilidad web.
Un fallo real encontrado al auditar una web con Tailwind v4
El consultor Slobodan Manic aplicó las siete reglas a su propio sitio, nohacks.co, inspeccionando el HTML en directo de la página de inicio y de una página de artículo representativa. Según detalla la fuente, seis de las siete reglas superaron la auditoría sin problemas. El fallo lo encontró en la regla 5: ninguno de los elementos <button> nativos de la web mostraba cursor: pointer.
La causa, según explica la fuente, está en un cambio introducido en Tailwind CSS v4: esta versión del popular framework eliminó cursor: pointer de sus estilos base para botones, mientras que Tailwind v3 sí lo incluía. El problema es silencioso: el botón sigue funcionando, el lector de pantalla lo anuncia correctamente, el clic se registra. Lo único que falla es la señal visual que indica que el elemento es interaccionable, que es exactamente lo que los modelos de visión de los agentes de IA usan para decidir con qué interactuar.
Según los datos facilitados por la fuente, el fallo afectaba a doce elementos <button> únicos repartidos entre la página de inicio y una página de artículo: el botón del menú móvil, el botón de suscripción al newsletter, seis botones de reproducción de episodios de podcast y el botón flotante de volver arriba, más dos botones adicionales en la página de artículo. Todos con cursor: default en lugar de cursor: pointer.
La solución es un fragmento de tres líneas de código
De acuerdo con la fuente, la corrección es sencilla y cubre de golpe todos los botones del sitio. Basta con añadir este bloque al stylesheet global del proyecto:
@layer base { button:not(:disabled), [role="button"]:not(:disabled) { cursor: pointer; } }
Según explica la fuente, la cláusula :not(:disabled) es importante: preserva el comportamiento existente de disabled:cursor-not-allowed que Tailwind ya aplica a los botones desactivados. Con esas tres líneas añadidas, la regla 5 pasa en todos los botones a la vez. La fuente señala que este es probablemente el arreglo más rentable de toda la lista, porque Tailwind v4 está muy extendido, las herramientas de auditoría de accesibilidad no lo detectan como error (el clic funciona) y apenas se está hablando de ello.
Por qué esto importa aunque Google use la palabra «considera»
Un matiz que la fuente se encarga de señalar es que Google no usa un lenguaje imperativo en su checklist. El verbo es «considera», no «debes» ni «es obligatorio». Tampoco vincula las recomendaciones con el posicionamiento orgánico ni con ningún producto de IA concreto. La prescripción práctica que desarrolla el análisis va por cuenta del autor, no de Google.
Aun así, según la valoración de la fuente, el peso del aval es significativo: cuando el principal buscador del mundo publica la misma lista que lleva décadas en los estándares de accesibilidad, esa lista deja de ser responsabilidad de una comunidad especializada y pasa a ser una disciplina de entrada para cualquier profesional web. La conclusión que propone la fuente es práctica: en lugar de hacer auditorías de accesibilidad y auditorías de compatibilidad con agentes de IA por separado, conviene tratarlas como una sola. El artefacto es el mismo. Los visitantes que se benefician son dos clases distintas.
Tres pasos para actuar esta semana según la fuente
El análisis publicado en Search Engine Journal propone un plan de acción concreto. Según los datos facilitados por la fuente, el proceso recomendado se puede ejecutar en una sola sesión de trabajo y no requiere herramientas de pago:
- Seleccionar las cinco páginas con más tráfico del sitio web.
- Pasarlas por las siete reglas de Google y por un escáner WCAG-AA estándar (Lighthouse, axe DevTools o la extensión WAVE). Anotar los solapamientos.
- Corregir una vez y recuperar las dos clases de visitantes: humanos con necesidades de accesibilidad y agentes de IA.
Si el proyecto usa Tailwind v4, de acuerdo con la fuente, el primer paso debería ser añadir el fragmento de @layer base mencionado antes. Es la corrección más urgente porque afecta a todos los botones nativos del sitio de golpe, no la detectan las herramientas habituales y tiene un impacto directo sobre la señal de accionabilidad que leen los modelos de visión de los agentes. Todo lo demás puede auditarse después con calma.
Fuente: https://www.searchenginejournal.com/googles-agent-friendly-checklist-is-the-accessibility-audit-restated/575495/