Can AI agents use your website?

Un nuevo tipo de visitante

Durante treinta años, un sitio web tuvo exactamente un tipo de visitante que importaba: una persona, en un navegador, mirando páginas renderizadas. Todo en la web moderna — los paquetes de JavaScript, los banners de cookies, los desafíos visuales antibots — se construyó para ese visitante. Los agentes de IA rompen el supuesto. Un agente que trabaja para un usuario suele obtener HTML en bruto sin ejecutar JavaScript, se identifica honestamente con un agente de usuario como GPTBot o ClaudeBot, lee los archivos orientados a máquinas que un sitio publica (robots.txt, mapas del sitio, llms.txt, especificaciones OpenAPI) y decide en unas pocas peticiones si este sitio puede entenderse y usarse siquiera. Los sitios que no pasan esa prueba no son castigados a gritos; el agente simplemente se va a otra parte, y la visita nunca aparece en ningún panel de analítica que poseas.

Esto importa ahora, y no con el tiempo, porque los agentes se están convirtiendo en un canal real: asistentes que investigan compras, agentes que reservan y compran, agentes de soporte que leen tu documentación para responder a clientes, rastreadores que construyen los índices desde los que esos sistemas responden. Cada uno de ellos califica tu sitio por legibilidad para máquinas, y la mayoría de los sitios nunca fueron diseñados para ser leídos así. La brecha rara vez es malicia o negligencia — es que la superficie orientada a máquinas (las reglas de rastreo, el HTML en bruto, las descripciones de API) creció por accidente mientras la superficie orientada a personas recibía toda la atención de diseño. La preparación para agentes es la disciplina de cerrar esa brecha a propósito.

Las cuatro capas de la preparación para agentes

El comprobador puntúa cuatro capas, en el orden en que un agente las experimenta. El descubrimiento (20 puntos) es si el agente puede encontrar el mapa del sitio: un robots.txt analizable y lo que dice a los principales rastreadores de IA, un mapa del sitio alcanzable, un archivo llms.txt, datos estructurados, una URL canónica que apunta a sí misma. El acceso (30 puntos) es si el agente puede entrar una vez que llega: páginas que responden a un cliente HTTP simple, ningún rechazo de agentes de usuario de IA, ningún intersticial de desafío antibots, contenido real en el HTML en bruto en lugar de una carcasa vacía esperando JavaScript, una redirección limpia a HTTPS y códigos de estado honestos — un 404 auténtico para lo que no existe, porque un agente que no puede distinguir una página ausente de una real no puede fiarse de nada más que el sitio diga.

La usabilidad (40 puntos) es la capa mayor, porque llegar no es lo mismo que transaccionar. Pregunta si el sitio expone maquinaria a través de la cual un agente pueda actuar: una especificación OpenAPI en las rutas que los agentes buscan, documentación que una máquina pueda encontrar, un endpoint MCP que responde a una sonda de protocolo, metadatos de descubrimiento de autenticación cuando hay una API a la que entrar, y los humildes formularios web — registro, contacto, captación — alcanzables sin desafío y etiquetados lo bastante bien para rellenarlos correctamente. Los pagos (10 puntos) preguntan si un agente podría pagar: un archivo de descubrimiento para uno de los protocolos emergentes de comercio agentivo (ACP, UCP, AP2, x402) y un pago que no planta un desafío en la cara del agente. Los pagos solo se puntúan cuando un sitio vende algo de verdad; en un sitio sin señales de comercio, toda la capa no es aplicable y la puntuación se reescala sin ella.

Cómo leer una puntuación

La puntuación va de 0 a 100, con notas en letras A desde 85, B desde 70, C desde 55, D desde 40 y F por debajo — y 70, el umbral de la B, es donde la convención de la categoría pone la línea de «preparado para agentes». Trata el número como un resumen, no como el producto. El producto es la lista de hallazgos: cada comprobación que falló o advirtió, la evidencia recogida para ella, lo que significa, la corrección y los puntos que la corrección recupera. El orden «corrige primero» es simplemente esa lista ordenada por puntos recuperables, que casi nunca es el orden que daría una lista genérica — un llms.txt ausente puede valer más que tres advertencias cosméticas juntas, y la ordenación es lo que te lo dice.

Dos hábitos de lectura mantienen honesto el número. Primero, respeta el mecanismo de no aplicable: las comprobaciones y las capas enteras desaparecen cuando su precondición está ausente, y la puntuación se renormaliza, así que un sitio de documentación no está siendo calificado por su pago. Una puntuación solo tiene sentido frente a las capas que se aplicaron. Segundo, recuerda lo que significa un veredicto: «no encontrado» es siempre «no encontrado en las rutas que un agente probaría, desde la red del escáner, en el momento del análisis». Los agentes prueban las rutas convencionales — ese es el sentido del ejercicio —, pero un análisis es una muestra de la superficie orientada a máquinas, no una auditoría de todo lo que un agente decidido podría acabar descubriendo con un humano guiándolo.

Los fallos que más cuestan, y sus correcciones

El mismo puñado de fallos explica la mayoría de los puntos perdidos en sitios reales. Rastreadores de IA bloqueados por defecto: un robots.txt copiado de una plantilla, o un preajuste de seguridad de un CDN, rechaza sin más a GPTBot, ClaudeBot y compañía — a veces lo contrario de lo que el propietario pretende, ya que los mismos rastreadores alimentan los motores de respuestas en los que el propietario quiere aparecer. La corrección es una política de robots deliberada: decide por rastreador, escríbela, mantén el mapa del sitio permitido. La carcasa vacía: la página de inicio devuelve un paquete de JavaScript y una rueda girando, con el contenido real renderizado solo en el cliente; los humanos nunca lo notan, los agentes ven una página vacía. Renderiza en el servidor, o prerenderiza, el contenido que importa. Sin mapa para máquinas: sin mapa del sitio, sin llms.txt, sin datos estructurados — cada uno barato de añadir, cada uno un hallazgo separado hasta que lo haces.

El segundo puñado trata de actuar, no de leer. Seguridad de desafío primero: un muro antibots que desafía a cada cliente desconocido también desafía a cada agente; la corrección es desafiar por comportamiento y señales de riesgo en lugar de solo por desconocimiento, y mantener alcanzable la superficie pública de solo lectura. APIs indocumentadas o indescubribles: la API existe, pero no hay especificación OpenAPI en una ruta encontrable, así que cada integración de un agente se convierte en un juego de adivinanzas a medida; publicar la especificación es una exportación única en la mayoría de los marcos. Formularios que un agente no puede rellenar: campos sin etiquetar, indicaciones solo en el marcador de posición y flujos de envío que exigen resolver un rompecabezas visual para un formulario de contacto rutinario. Ninguna de estas correcciones exige rediseñar el sitio humano — la capa orientada a máquinas es casi enteramente aditiva, y por eso los puntos están ahí para quien los quiera.

Caso de estudio: este sitio, analizado

Una revelación antes del número. El propio sysosx.com no puede analizarse con el comprobador público de arriba: como cada comprobación de sysosx, el endpoint rechaza sysosx.com como objetivo bloqueado, por diseño, para que la herramienta no pueda apuntarse a su propia infraestructura. El caso de estudio de abajo se produjo por tanto de otro modo — el mismo motor de análisis, con las mismas comprobaciones y puntuación, ejecutado localmente contra el sitio sysosx.com en vivo. La puntuación es salida real del motor, no una estimación; solo difiere el punto de vista.

Dónde se fueron los puntos: los principales hallazgos

Preguntas frecuentes