Web preparada para agentes de IA: auditoría de navegación y formularios

Tu web puede aparecer en una respuesta de IA y fallar en el paso siguiente. El usuario pide comparar dos opciones, aplicar un filtro o preparar una solicitud; el agente llega a la página, pero no encuentra el control correcto, pierde la selección al volver atrás o confunde un aviso con una confirmación.

Una auditoría de una web preparada para agentes de IA comprueba tareas, no etiquetas de moda. El resultado útil es una lista de recorridos con condiciones de entrada, evidencia de ejecución, límites de autorización y un criterio explícito para decidir si funcionaron.

Esta guía propone un protocolo de Mentio para equipos de producto, frontend, UX y SEO técnico. Los ejemplos son hipotéticos. No estamos certificando una web ni presentando una puntuación de ranking. La visibilidad en respuestas y la capacidad de usar una interfaz son dos problemas relacionados, pero distintos.

Define qué trabajo vas a evaluar

Empieza por una frase que contenga una persona, un objetivo y una restricción. Por ejemplo: una responsable de compras quiere comparar dos planes para doce usuarios, necesita facturación mensual y no autoriza iniciar una suscripción. Esa tarea es verificable; pedir al agente que explore la web no lo es.

Selecciona recorridos que ya tengan utilidad para usuarios reales. Puedes priorizarlos con búsquedas internas, incidencias de soporte, analítica y sesiones de investigación, siempre con datos que estés autorizado a usar. No inventes una demanda de búsqueda para justificar una prueba técnica.

Separa cuatro preguntas antes de asignar trabajo:

La auditoría de crawlers de IA es la propietaria del acceso. La guía de datos estructurados trata la descripción de entidades. Si tu problema es el contrato de checkout de un protocolo, consulta la auditoría UCP. Aquí evaluamos la interacción con la web, incluso cuando no hay compra.

Observa las tres representaciones de la interfaz

Google describe tres entradas posibles para un agente: la imagen renderizada, el DOM y el árbol de accesibilidad. No todos los agentes usan las mismas entradas ni las combinan igual. Una auditoría debe registrar qué modalidad utilizó la herramienta evaluada, no asumir que ve exactamente lo que ve tu equipo. Fuente: web.dev.

Para cada bloqueo, guarda la captura, el elemento o fragmento relevante y el estado que debía representar. Imagina un selector de plan que visualmente parece activo, cuyo nombre programático dice otra opción y que conserva un valor anterior al enviar. El defecto no se describe bien como “la IA se confundió”: hay tres señales que no coinciden.

No uses texto invisible lleno de instrucciones para compensar una interfaz ambigua. Corrige el control y vuelve a probar el recorrido humano. El objetivo es que los distintos canales describan la misma acción, no mantener una segunda experiencia difícil de auditar.

Escribe un contrato por tarea

Antes de ejecutar, completa una ficha breve. La misma ficha debe servir para decidir el resultado sin leer las intenciones del agente.

Congela navegador, versión del agente, idioma, viewport, sesión y variante de la web. Si alguno no puede controlarse, anótalo como limitación. No mezcles una sesión con cookies antiguas y otra limpia para atribuir la diferencia a un cambio de código.

El criterio de éxito debe existir antes del ensayo. Si lo cambias después de ver un resultado, versiona la ficha y repite también la referencia anterior. Así evitas declarar una mejora solo porque has reducido lo que exigías.

Construye una matriz pequeña pero representativa

No hace falta empezar por cien recorridos. Una primera pasada puede incluir estas ocho familias y tres repeticiones por configuración. Esa cantidad es una propuesta de diagnóstico inicial, no una muestra estadística suficiente ni una recomendación universal.

Añade variantes cuando cambie el riesgo: móvil y escritorio, ES y EN, sesión nueva y autenticada de prueba, resultados vacíos y carga lenta. No multipliques todas las dimensiones de forma automática. Explica qué combinaciones cubres y qué queda sin evaluar.

Incluye una ejecución humana de referencia. Si una persona tampoco puede completar el recorrido, existe un fallo del producto que debe resolverse sin atribuirlo exclusivamente al agente. Si la persona termina y el agente no, conserva la diferencia exacta de pasos y señales.

Evalúa navegación y comparación antes de tocar formularios

Pide un destino o un resultado, no una secuencia de clics dictada por el desarrollador. “Encuentra las condiciones de cancelación del plan mensual” revela más que “abre el segundo enlace del menú”. Evita dar al agente un selector interno que un visitante normal no tendría.

Comprueba entradas alternativas. La tarea puede empezar en una ficha enlazada desde un buscador, no en la portada. Revisa la vuelta a resultados, la paginación, los filtros persistidos y el cambio de idioma. Un enlace que abre la página correcta pero borra las restricciones puede invalidar la comparación.

Para comparar, define una tabla de referencia con unidades y condiciones. Un precio por usuario no debe enfrentarse a un precio por cuenta sin explicarlo. Registra “dato no disponible” cuando falte evidencia: completar la celda con una suposición es un fallo, aunque el resultado parezca ordenado.

Después del ensayo, clasifica el problema: destino no localizable, control ambiguo, estado perdido, información insuficiente o interpretación incorrecta. Cada categoría conduce a una corrección distinta. No cambies todo el diseño por un error que realmente estaba en el enunciado de la tarea.

Prueba los formularios como una secuencia de estados

Un formulario no termina cuando sus campos tienen texto. Debe distinguir datos pendientes, validación, envío en curso, error y resultado confirmado. Para los nombres de los controles, W3C recomienda asociar las etiquetas a sus campos; un placeholder no sustituye por sí solo esa relación. Fuente: etiquetas de formularios de W3C.

Usa datos sintéticos inequívocos y comprueba lo que realmente queda seleccionado. Fechas, prefijos telefónicos, autocompletados, listas dependientes y unidades pueden producir valores diferentes de los que el agente cree haber introducido. Conserva una vista previa o registro de prueba que permita contrastarlos.

Incluye al menos un caso inválido. El mensaje debe permitir localizar el problema y corregirlo; la confirmación debe distinguir un éxito real de una mera recepción de clic. W3C documenta la importancia del feedback de error y de éxito. Fuente: notificaciones de formularios de W3C.

Tu auditoría añade una comprobación operativa: tras corregir el campo, ¿los demás datos siguen intactos?, ¿el estado ya no muestra el error?, ¿el formulario está listo para la siguiente acción autorizada? No premies al agente por repetir todo a ciegas hasta que desaparece el aviso.

Comprueba recuperación sin duplicar efectos

Simula los errores en un entorno controlado: una respuesta lenta, una sesión de prueba caducada, un resultado vacío o un recurso temporalmente no disponible. No provoques fallos deliberados en servicios de usuarios reales.

El caso más importante es el estado incierto. Si el navegador no recibe confirmación, el agente no debe deducir automáticamente que nada ocurrió. Tu ficha debe indicar cómo comprobar el registro de prueba antes de repetir una operación con efectos. La interfaz puede ofrecer consulta de estado, un identificador de solicitud o una instrucción de recuperación.

Valora por separado la recuperación autónoma y el traspaso correcto a una persona. Detenerse ante una autorización ausente puede ser el resultado esperado. En cambio, detenerse porque el mensaje no explica qué hacer es un bloqueo del flujo.

No conviertas esta prueba en un atajo para desactivar controles de seguridad. Mantén las comprobaciones de sesión, permisos y protección frente a abuso. Si un control exige intervención humana, registra ese requisito como parte del recorrido soportado, no como un obstáculo que deba eludirse.

Usa herramientas sin confundir auditoría y resultado

Chrome documenta una categoría Agentic browsing de Lighthouse desde M150, con controles sobre accesibilidad, estabilidad e integración WebMCP. Su resultado se describe como informativo y sin benchmark, no como una clasificación de posicionamiento. Registra la versión y el informe utilizado. Fuente: toolkit de Chrome.

Combina tres capas de verificación. Una inspección estática localiza defectos del marcado. Una prueba determinista comprueba que el flujo se mantiene. Una ejecución con el agente elegido revela si interpreta y completa la tarea. Ninguna sustituye a las otras.

Para regresiones de interfaz, Playwright recomienda probar comportamiento visible para el usuario, aislar las pruebas y usar localizadores resistentes basados en atributos orientados al usuario. Un script que conoce todos los pasos no demuestra, por sí mismo, que un agente pueda descubrirlos. Fuente: buenas prácticas de Playwright.

WebMCP es una propuesta para exponer herramientas estructuradas en páginas web. La documentación de Chrome, actualizada el 7 de agosto de 2026, la presenta como mejora progresiva y ofrece un origin trial desde Chrome 149. No presupongas soporte universal: registra navegador, cliente y condiciones concretas. Fuente: WebMCP.

Si incorporas ese camino a un piloto, evalúalo en una configuración separada. La prueba debe comprobar el estado visible y el efecto autorizado, no solo que una llamada devuelva una respuesta. Conserva además la ruta convencional para usuarios y clientes que no lo utilicen.

Registra evidencia suficiente, no conversaciones enteras

Cada ensayo necesita un identificador, tarea versionada, entorno, fecha, resultado y enlaces a las pruebas. Añade el primer punto de divergencia, el paso de recuperación y quién validó el resultado. No hace falta conservar todos los datos que vio el navegador.

Un registro mínimo puede seguir este formato:

run_id: audit-2026-09-05-COMP02-03
task_version: COMP-02-v1
configuration: desktop-es-session-clean-agent-version-recorded
expected: two eligible monthly plans; no subscription
observed: second plan compared using annual billing
outcome: failed
first_divergence: billing toggle state not carried into comparison
evidence: redacted screenshot + task trace + reference table
owner: product-pricing
retest: same configuration after fix

Elimina correos, teléfonos, tokens, identificadores de sesión y otros datos que no sean necesarios. Limita el acceso y la retención. Una captura de pantalla puede contener información sensible aunque el formulario principal use datos sintéticos.

No aceptes como única evidencia la frase “hecho” del agente. Comprueba el destino, el valor final o el registro del sistema de prueba. Cuando el resultado no sea verificable, conserva esa categoría; no lo conviertas en éxito por falta de error visible.

Decide por tarea y riesgo, no por una media cómoda

Define estados mutuamente excluyentes: éxito verificado, fallo, bloqueo externo e inconcluso. Si detenerse era el objetivo de una tarea de autorización y se respeta el límite, cuenta como éxito de esa tarea; no como una compra completada.

En un ejemplo hipotético de veinte ensayos hay catorce éxitos, tres fallos, dos bloqueos externos y un resultado inconcluso. El éxito verificado es 14/20, un 70 %. No lo presentes como 14/17 sin explicar que has excluido tres ensayos. Publica siempre los recuentos y los criterios de exclusión.

Separa tareas críticas de informativas. Encontrar una FAQ no compensa enviar datos sin permiso o comparar una opción incorrecta. Como regla interna de este protocolo, cualquier efecto no autorizado o resultado comercial equivocado bloquea el lanzamiento del flujo afectado hasta corregirlo y repetir la prueba.

Entrega cada hallazgo con impacto, condición reproducible, responsable y prueba de cierre. Vuelve a ejecutar tanto la tarea que falló como una tarea vecina que pudiera sufrir una regresión. La mejora existe cuando el defecto deja de reproducirse sin empeorar otro recorrido, no cuando cambia el texto del informe.

Checklist de salida

• Objetivo, autorización y evidencia de éxito escritos antes de ejecutar.
• Navegador, agente, idioma, viewport y sesión registrados.
• Tareas de navegación, comparación, formularios y recuperación cubiertas.
• Casos inválidos, vacíos y límites de autorización probados.
• Resultado contrastado con evidencia independiente del relato del agente.
• Datos de prueba e integraciones aislados de usuarios reales.
• Trazas depuradas de datos sensibles y con retención definida.
• Recuentos, denominadores, bloqueos e inconclusos publicados.
• Fallos críticos con responsable y prueba de cierre.
• Regresión comprobada en el recorrido humano y en el agente evaluado.

FAQ

¿Qué significa que una web esté preparada para agentes de IA?

En esta auditoría significa que un agente puede completar tareas concretas dentro de su autorización, interpretar el estado de la interfaz y demostrar el resultado. No es una certificación universal ni una garantía de ranking, conversión o compatibilidad con todos los agentes.

¿En qué se diferencia de una auditoría de crawlers?

La auditoría de crawlers comprueba acceso y contenido recuperable. Esta prueba evalúa acciones dentro de la interfaz: buscar, filtrar, comparar, completar un formulario y recuperarse de un error. Una web puede permitir el rastreo y, aun así, impedir que un agente termine esas tareas.

¿Una buena accesibilidad garantiza que cualquier agente complete el flujo?

No. La accesibilidad debe atender primero a las personas y requiere su propia evaluación. El resultado de un agente también depende de sus capacidades, sesión, permisos, estado de la web y tarea. Comprueba cada flujo sin convertir una auditoría parcial en una garantía general.

¿Necesito implementar WebMCP antes de empezar?

No para ejecutar el protocolo de esta guía. Empieza por las tareas y la interfaz disponible. Si pruebas WebMCP, evalúa ese camino por separado y conserva el flujo convencional: una integración opcional no debe esconder fallos ni eliminar los controles de autorización.

¿Cuántas pruebas hacen falta para declarar una web fiable?

No existe un número universal. Define tareas y variantes según uso y riesgo, repite los recorridos críticos y publica siempre el denominador. Una primera pasada pequeña detecta fallos evidentes, pero no permite extrapolar una tasa de éxito a todos los modelos, usuarios y sesiones.

¿Cómo pruebo compras o formularios sin afectar a usuarios reales?

Usa un entorno de prueba con cuentas y datos sintéticos, integraciones aisladas y efectos reversibles. Detén la ejecución antes de pagos, mensajes, reservas o envíos reales si no hay autorización específica. Verifica también que el agente respeta ese límite y no declara una operación que no ocurrió.

Conecta visibilidad y uso sin mezclar las señales

Una marca puede ganar presencia en respuestas y perder oportunidades cuando el visitante, humano o asistido por un agente, intenta utilizar su web. También puede tener una interfaz impecable y no aparecer en las recomendaciones. Mide ambos extremos de forma independiente.

La introducción al comercio agéntico sitúa este cambio de recorrido. La auditoría de esta guía aporta el control práctico: qué tareas funcionan, dónde se rompen y qué evidencia permite dar por cerrada una corrección.

Consulta los planes de Mentio para medir tu visibilidad en respuestas de IA. Usa ese dato junto con una auditoría de tareas de tu web, sin presentar Mentio como una herramienta que certifique automáticamente la navegación o la accesibilidad.

¿Quieres saber si la IA menciona tu marca?

Descubre tu visibilidad en ChatGPT, Claude y Gemini en minutos.

Artículos relacionados