Auditoría de Accesibilidad para IA y Preparación para Agentes

Los sistemas de IA no pueden citar, recomendar ni actuar sobre contenido que no pueden recuperar de manera confiable. Esta fase prueba esa base antes de que el equipo mida la visibilidad o encargue contenido destinado a motores de respuesta.

Fase: P4, Etapa A — Comprender. Tiempo estimado: 3–5 días hábiles para un sitio de marketing típico; 5–10 para un gran comercio electrónico, mercado o aplicación con renderizado mayormente del lado del cliente. Responsable: el líder técnico de SEO es accountable, con ingeniería ejecutando pruebas de obtención y renderizado, el líder de contenido revisando la extractabilidad, y un responsable de negocio o legal decidiendo la política de rastreadores.

Por qué esta fase viene aquí

Una auditoría técnica convencional pregunta si los motores de búsqueda pueden rastrear, renderizar, indexar y posicionar el sitio. Esta fase pregunta si los rastreadores de IA, los sistemas de recuperación y los agentes orientados a tareas pueden alcanzar e interpretar la misma información útil. Pueden usar diferentes agentes de usuario, rutas de obtención, capacidades de renderizado, tiempos de espera y métodos de extracción. Una página indexable aún puede devolver una cáscara vacía, un muro de consentimiento, un desafío de bot o fragmentos desconectados a un cliente de IA.

Por lo tanto, una auditoría de accesibilidad para IA pertenece junto a la auditoría de línea base técnica , no al final de la producción de contenido. El renderizado del lado del cliente significa que JavaScript construye contenido importante después de que llega el HTML inicial. Los sistemas de recuperación pueden no ejecutar ese código, pueden detenerse antes de que se complete, o pueden extraer solo la respuesta inicial. Si el nombre del producto, la respuesta, el precio, la disponibilidad o la evidencia existen solo después de que JavaScript se ejecuta, la optimización posterior del contenido no puede reparar la falla de acceso.

Esta fase consume las cuentas verificadas, análisis, registros de rastreadores, fuentes de sitemaps, conjunto de URL críticas y mapa de propiedad de la fase de acceso, seguimiento y fuentes de datos . Ejecutarla antes deja al equipo incapaz de distinguir una ausencia genuina de una falta de acceso. Ejecutarla después de la medición de línea base contamina la línea base: cero citas pueden reflejar un sitio inaccesible, no contenido débil o demanda.

Saltarse la fase desperdicia trabajo: los redactores mejoran pasajes que un rastreador nunca recibe, los desarrolladores añaden esquemas detrás de un desafío, o el equipo confunde un llms.txt válido con preparación integral del sitio. Acceso, extracción, comprensión y acción son capacidades separadas.

Entradas y salidas

Las entradas hacen que las pruebas sean reproducibles. Las salidas forman un contrato con P5: la medición comienza solo después de que las fallas de acceso conocidas se hayan corregido o aceptado explícitamente.

La lista de verificación

Pruebe el conjunto de URL representativas, no solo la página de inicio, y conserve evidencia reproducible.

1. Decidir el acceso de rastreadores deliberadamente

Qué hacer: inventariar las reglas de rastreadores de IA en robots.txt , controles de bots del CDN, firewalls de aplicaciones web, capas de consentimiento y configuración del origen. Por qué importa: un permiso en robots es solo una preferencia; un servicio perimetral aún puede bloquear la solicitud, mientras que un bloqueo accidental con comodín no es política. Cómo hacerlo: comparar las reglas en producción con la matriz de política, obtener URL representativas con los agentes de usuario aplicables y registrar la compensación. Herramienta: Robots.txt y Sitemaps de AmICited, un cliente de solicitudes aprobado y registros de CDN/origen. Listo cuando: cada familia de rastreadores tiene una decisión aprobada de permitir, bloquear o condicional, y el comportamiento en producción coincide con ella.

2. Comparar la respuesta sin JavaScript con la página útil

Qué hacer: comparar el HTML inicial con la página normal del navegador. Por qué importa: un cliente de recuperación puede no ejecutar scripts que insertan respuestas, ofertas, enlaces o datos de producto. Cómo hacerlo: probar cada plantilla importante antes de la hidratación, el proceso que adjunta el comportamiento de la aplicación al HTML del servidor. Herramienta: un navegador sin script o cliente HTTP más la página renderizada. Listo cuando: la respuesta inicial contiene el título, H1, contenido principal, hechos clave y enlaces de descubrimiento; cualquier excepción tiene evidencia y un responsable.

3. Probar la extractabilidad del DOM renderizado

Qué hacer: extraer el contenido principal del Modelo de Objetos del Documento (DOM) renderizado, la representación estructurada de la página del navegador, sin navegación, texto de consentimiento o variantes ocultas. Por qué importa: recibir texto no es lo mismo que identificar el texto correcto; el ruido de la plantilla puede corromper la recuperación. Cómo hacerlo: comparar el título extraído, respuesta, editor, fechas, hechos y enlaces con la fuente visible en páginas largas, escasas y comerciales. Herramienta: inspección del navegador, extracción de texto y fuente de la página. Listo cuando: el registro conserva el significado principal y los hechos sin posición visual ni selectores no documentados.

4. Inspeccionar el árbol de accesibilidad

Qué hacer: revisar el árbol de accesibilidad: roles, nombres, estados, encabezados, puntos de referencia y controles. Por qué importa: la semántica distingue encabezados de decoración, botones de iconos y contenido principal de navegación. Cómo hacerlo: probar plantillas críticas para un H1, encabezados ordenados, controles con nombre, puntos de referencia, enlaces descriptivos y alternativas de imagen significativas. Herramienta: verificador de Árbol de Accesibilidad de AmICited e inspección del navegador. Listo cuando: la puntuación cumple el umbral, ningún control crítico carece de nombre, y la región principal y la siguiente acción son identificables.

5. Validar la cobertura y veracidad de los datos estructurados

Qué hacer: comparar los hechos visibles con los datos estructurados , marcado estandarizado como Schema.org JSON-LD. Por qué importa: el marcado aclara entidades, ofertas, autoría y fechas, pero un marcado inexacto comunica el hecho equivocado. Cómo hacerlo: validar los esquemas aplicables y reconciliar nombres, URL, precios, moneda, disponibilidad, fechas, calificaciones e identificadores con los sistemas de origen. Herramienta: validador, HTML renderizado y registros fuente. Listo cuando: las plantillas críticas tienen marcado aplicable válido, los valores coinciden con los hechos visibles y cada advertencia material está resuelta o explicada.

6. Revisar llms.txt como guía, no como barrera

Qué hacer: verificar si /llms.txt resume con precisión la organización y enlaza a recursos públicos canónicos. Es una guía propuesta en texto plano, no control de acceso ni una señal de posicionamiento garantizada. Por qué importa: un mapa conciso reduce la ambigüedad; uno desactualizado desorienta a los agentes. Cómo hacerlo: verificar el estado, la estructura Markdown, la descripción, los destinos, las URL canónicas y el responsable. Herramienta: revisión de llms.txt de AmICited y obtención directa. Listo cuando: el archivo, si se usa, no tiene enlaces rotos/privados y tiene un responsable de mantenimiento; la ausencia es un hallazgo de mejora, no una prueba de invisibilidad.

7. Examinar pasajes autocontenidos

Qué hacer: revisar definiciones, respuestas, hechos, comparaciones, pasos y limitaciones recuperados de forma independiente. Por qué importa: la recuperación puede separar un párrafo de su encabezado; “funciona mejor para ellos” pierde entonces su sujeto y comparación. Cómo hacerlo: leer al menos 20 pasajes sin su título ni párrafo anterior. Herramienta: salida de extracción y revisión editorial. Listo cuando: cada uno nombra su sujeto, responde una pregunta identificable, conserva condiciones o unidades y evita referencias no resueltas.

8. Confirmar la claridad de la entidad canónica

Qué hacer: verificar que el sitio indique quién es la organización, qué ofrece y cómo se relacionan sus marcas, productos, personas, ubicaciones y perfiles. Una entidad canónica es la cosa real y principal a la que se refiere un nombre. Por qué importa: nombres inconsistentes, logotipos antiguos, descripciones contradictorias y URL de perfiles desconectados facilitan fusionar dos entidades o dividir una en varias. Cómo hacerlo: comparar la página de inicio, la página Acerca de, datos de contacto, datos estructurados, perfiles sociales, páginas de autor, nombre legal y perfiles importantes de terceros. Herramienta: hoja de datos de entidad, páginas renderizadas y salida de datos estructurados. Listo cuando: una hoja de datos aprobada resuelve el nombre oficial, alias, URL canónica, logotipo, descripción, propiedad, ofertas principales y perfiles de misma entidad, con conflictos registrados para corrección.

9. Probar el tiempo de respuesta y la fiabilidad de la obtención

Qué hacer: medir el estado, el Tiempo hasta el Primer Byte (TTFB), redirecciones, tiempos de espera y consistencia de la respuesta en condiciones normales y con agentes de usuario de rastreadores relevantes. TTFB es el intervalo desde el inicio de la solicitud hasta que llega el primer byte de respuesta. Por qué importa: 403s, 429s, respuestas 5xx intermitentes, cadenas largas de redirecciones u orígenes lentos hacen que el contenido no sea confiable incluso cuando una visita única del navegador tiene éxito. Cómo hacerlo: ejecutar la muestra repetible definida en la tabla de umbrales desde más de una ubicación de red cuando la geografía importa, luego reconciliar las fallas con los registros y las Métricas Web Fundamentales. Herramienta: monitor de solicitudes, registros de CDN/origen y AmICited Web Vitals. Listo cuando: las URL críticas satisfacen los umbrales de fiabilidad y latencia, o tienen una severidad, causa, responsable y fecha de nueva prueba.

10. Evaluar WebMCP y protocolos de comercio donde crean valor

Qué hacer: probar WebMCP y la preparación para comercio solo donde el modelo de negocio respalde las acciones de los agentes. WebMCP es una forma emergente para que un sitio web exponga herramientas invocables, como búsqueda, reserva o añadir un artículo al carrito. El comercio agéntico cubre el descubrimiento de productos y transacciones asistidas por agentes, incluidos protocolos como ACP o UCP. Por qué importa: el contenido legible respalda respuestas; las herramientas explícitas y los datos comerciales respaldan acciones confiables sin extracción de pantalla. Cómo hacerlo: mapear tareas útiles del usuario, inspeccionar las herramientas o protocolos declarados, validar las descripciones de entrada y salida, y verificar el comportamiento de confirmación, autenticación, permiso, precio, inventario y errores. Herramienta: verificaciones de WebMCP y Comercio Agéntico de AmICited más un entorno de prueba controlado. Listo cuando: las capacidades aplicables se detectan y son comprobables de forma segura, o la verificación se marca como no aplicable con una razón aprobada basada en el modelo de negocio y un desencadenante de revisión.

Herramientas en AmICited

Abra https://app.amicited.com/accessibility para la auditoría consolidada y la explicación de la función Accesibilidad para IA y Preparación para Agentes . El producto reporta lecturas independientes en lugar de ocultar diferentes tipos de fallas dentro de una puntuación combinada.

1. Use el resumen para consultar la Puntuación de Accesibilidad para Agentes y registrar cada componente, no solo el estado general.
2. Use Robots.txt y Sitemaps para consultar la cobertura de robots.txt y sitemaps , luego compare la regla declarada con una obtención en vivo estilo rastreador.
3. Use la revisión de archivos para revisar llms.txt y abrir cada destino listado.
4. Use el verificador de páginas para inspeccionar el árbol de accesibilidad de una página para cada plantilla crítica.
5. Use las verificaciones de preparación para verificar la preparación para WebMCP y verificar la preparación para comercio agéntico cuando esas capacidades apliquen.
6. Abra https://app.amicited.com/audit/web-vitals para consultar las Métricas Web Fundamentales y conectar el rendimiento de campo con las pruebas de solicitud en condiciones de rastreador.

Reglas de decisión

Estos son umbrales operativos de aceptación, no afirmaciones sobre algoritmos de posicionamiento. Ajústelos para recorridos críticos de ingresos o contenido regulado, y registre cualquier alternativa antes de probar para que el resultado no se ajuste después del hecho.

Las puntuaciones nunca anulan la evidencia concreta. Una puntuación de accesibilidad de 85 no excusa un botón de pago sin etiqueta, y un permiso en robots no supera una página de desafío devuelta a la solicitud real. “No verificado” es desconocido, no una aprobación ni un cero.

Entregable: el registro de hallazgos de preparación para agentes

Entregue un solo registro de hallazgos, no una presentación y un backlog de IA separado. Añada cada hallazgo a la lista de prioridades de P2 con estos campos:

ID y título:
URL/plantillas afectadas:
Verificación y condición observada:
Condición/umbral esperado:
Evidencia: marca de tiempo, agente de usuario, estado, captura o referencia de registro
Consecuencia de negocio:
Severidad: Crítica | Grave | De asesoría
Acción recomendada:
Responsable y aprobador:
Esfuerzo y dependencia:
Fecha de vencimiento y fecha de nueva prueba:
Decisión de política, si corresponde:
Impacto en la medición de P5:
Estado: Abierto | Riesgo aceptado | Corregido | Verificado

Crítico significa que la falla impide el acceso confiable, cambia materialmente el significado extraído o permite una acción insegura. Grave significa que el acceso o la comprensión están degradados pero un cliente representativo aún puede recuperar el contenido principal. De asesoría significa una mejora útil sin evidencia de falla actual. Riesgo aceptado requiere el dueño del negocio nombrado, la justificación, el alcance afectado, la fecha de vencimiento o revisión, y una forma de detectar condiciones cambiadas.

Desduplique por causa raíz: un desafío del CDN que afecta a rastreadores convencionales y de IA es un elemento con múltiples registros de evidencia.

Qué sale mal

Tratar la fase como opcional. El seguimiento de indicaciones y las reescrituras de contenido no pueden compensar una recuperación fallida. Haga de P4 una condición de entrada para una línea base interpretable.

Bloquear por defecto y llamarlo política retroactivamente. Una regla sin responsable de decisión, justificación ni fecha de revisión es configuración, no política. Presente la compensación entre descubrimiento y control, y obtenga una decisión explícita.

Añadir llms.txt y declarar finalización. El archivo no puede anular las reglas de robots, los bloqueos del CDN, el HTML inicial vacío, el marcado engañoso, los pasajes débiles ni los tiempos de espera. Trátelo como una guía dentro del conjunto de evidencia más amplio.

Probar solo un agente de usuario amigable o la página de inicio. Los controles perimetrales varían según la ruta, geografía, velocidad e identidad. Pruebe cada plantilla de alto valor y agente de usuario en la matriz de política.

Confundir apariencia con extractabilidad. Una página pulida puede exponer duplicados ocultos, nombres de control sin sentido o una respuesta en blanco sin script. Conserve la fuente, DOM, árbol de accesibilidad y evidencia de texto extraído por separado.

Tratar lo desconocido como éxito o fracaso. Vuelva a probar los tiempos de espera y los rastreadores no verificados; nunca convierta evidencia faltante en una puntuación conveniente.

Instalar capacidades experimentales de agentes sin un caso de uso. Los protocolos WebMCP o de comercio deben exponer acciones valiosas y con permisos. Implementar una acción insegura o inexacta es peor que marcar la capacidad como no aplicable.

Transferencia a la medición de línea base

La fase de medición de línea base recibe la lista de prioridades fusionada, el paquete de evidencia de prueba, el registro de política de rastreadores, el conjunto de URL representativas y la nota de preparación. El responsable de P4 debe identificar cualquier limitación que cambie la interpretación: familias de rastreadores bloqueadas, plantillas inaccesibles, regiones intermitentes, pasajes faltantes o una corrección reciente cuyo efecto no se haya propagado.

P5 puede proceder cuando las URL críticas sean intencionalmente accesibles para las familias de rastreadores incluidas en la medición, el contenido principal válido sea extraíble y no haya ningún hallazgo Crítico no resuelto que haga que una puntuación baja o cero sea no interpretable. Puede proceder con anotaciones cuando un bloqueo deliberado excluya a un rastreador conocido o un problema Grave afecte a una plantilla acotada. Debe esperar cuando la intención de acceso sea desconocida, las páginas críticas fallen en las obtenciones, o el contenido extraído contradiga materialmente la fuente visible.

La transferencia está completa cuando el responsable de P5 pueda responder tres preguntas sin reabrir la auditoría: qué agentes debían tener acceso, qué páginas y hechos podían recuperar de manera confiable, y qué limitaciones conocidas deben aparecer junto a la línea base.

Preguntas frecuentes

Preguntas frecuentes