Durante años, el reto de una web “bien hecha” se resumía en dos obsesiones sanas: que cargase rápido y que Google la entendiera. En 2026, ese mapa empieza a quedarse corto. Cada vez más tráfico llega mediado por asistentes, resúmenes automáticos y agentes de Inteligencia Artificial que “leen” páginas para citar, recomendar o ejecutar acciones. Y esos nuevos visitantes no consumen la web como un humano.
En ese contexto aparece AgentReady.md, una herramienta online gratuita que promete algo muy concreto: poner nota en segundos a una URL y decir, con una lista de tareas priorizada, qué hay que tocar para que una página sea más “legible” para agentes. El servicio funciona sin registro y, en su beta, limita el uso a 5 análisis por hora.
La propuesta no es “otro SEO tool” con métricas opacas, sino una auditoría técnica con una idea de fondo: si el contenido llega limpio, estructurado y con señales claras, los agentes fallan menos… y cuesta menos procesarlo.
Qué analiza AgentReady.md (y por qué le interesa a sistemas)
El informe de AgentReady.md parte de un flujo simple: se introduce una URL, la plataforma extrae el contenido y analiza su estructura; después devuelve una puntuación y recomendaciones para subirla. En el propio sitio, el proyecto resume su scoring en 5 dimensiones con 21 comprobaciones.
Para un equipo de desarrollo o un administrador de sistemas, la gracia está en que esas dimensiones se reparten responsabilidades de forma bastante realista:
- HTML semántico: si la página usa bien
main,article, jerarquía de encabezados yalten imágenes. - Eficiencia del contenido: cuánto “ruido” (wrappers, estilos inline, navegación redundante) acompaña al contenido útil.
- Descubribilidad para IA: señales como
llms.txt,robots.txt,sitemapy negociación de Markdown. - Datos estructurados: Schema.org/JSON-LD, Open Graph, canonical, idioma.
- Accesibilidad: si el contenido depende de JavaScript, tamaño de página y posición del contenido en el HTML.
La clave es que, a diferencia del usuario humano (que “se apaña” con interfaces recargadas), un agente suele operar con extracción: se queda con lo que entiende y descarta el resto. Si la estructura es pobre, el agente no solo “ve menos”: interpreta peor.
El elefante en la habitación: tokens, coste y contexto
En paralelo, la industria está empujando el mismo argumento desde el otro lado: convertir HTML a Markdown reduce coste y mejora el contexto útil. Cloudflare, por ejemplo, ha presentado “Markdown for Agents”, un sistema que convierte páginas HTML a Markdown en el edge cuando el cliente solicita Accept: text/markdown.
El dato que mejor explica el incentivo económico es brutal: en el caso del propio anuncio de Cloudflare, la página pasa de 16.180 tokens en HTML a 3.150 tokens en Markdown, lo que supone un 80 % menos.
AgentReady.md se apoya en el mismo razonamiento: una página bien estructurada puede requerir entre un 70 % y un 80 % menos de tokens si el consumo se hace en un formato limpio.
Para un sysadmin, eso se traduce en dos derivadas prácticas:
- Menos fricción para pipelines RAG/agents que consumen tu contenido.
- Más control sobre qué parte del sitio se considera “contenido principal” frente a navegación, footers o componentes repetidos.
Tabla rápida: “problema típico” → “arreglo típico” (y quién lo hace)
| Señal que penaliza a agentes | Qué suele ocurrir | Arreglo típico | Responsable habitual |
|---|---|---|---|
Botones/CTAs hechos con div + JS | El agente no identifica acciones | Usar elementos nativos (button, a) y nombres accesibles | Frontend |
Encabezados caóticos (h1 repetidos, saltos) | El contenido se chunk-ea mal | Jerarquía h1 → h2 → h3, regiones (main, article) | Contenido + Frontend |
| Demasiado “boilerplate” | El extractor mete ruido | Reducir wrappers, minimizar inline styles, plantillas más limpias | Frontend |
| Contenido clave tarda en aparecer | El agente se queda “arriba” | Subir el contenido útil en el HTML, SSR donde tenga sentido | Frontend + Backend |
No hay señales para agentes (llms.txt, sitemap) | Descubre peor el sitio | Publicar llms.txt, mantener sitemap.xml, revisar robots.txt | Sistemas + SEO/Contenido |
| No hay negociación de formato | Cada agente convierte por su cuenta | Servir Markdown si Accept: text/markdown (o usar un edge converter) | Sistemas |
No es una receta única, pero sí un mapa operativo: lo que se arregla en servidor, lo que toca plantillas, y lo que depende de contenido/estructura editorial.
Negociar Markdown sin duplicar URLs: la parte que le interesa a infraestructura
Uno de los puntos más prácticos (y más “de sistemas”) es el de servir el mismo recurso en formatos distintos según la cabecera Accept. La idea ya aparece en el debate del sector y se resume así: mantener una URL canónica, pero devolver HTML a navegadores y Markdown a agentes si lo piden.
Cloudflare lo ejemplifica con claridad: si el cliente incluye Accept: text/markdown, la red detecta esa preferencia, recupera el HTML del origen y lo convierte a Markdown antes de entregarlo. Y añade dos detalles importantes para operar esto con garantías:
- La respuesta puede incluir
Vary: accept, para que caches intermedias no mezclen HTML y Markdown. - También puede incluir una cabecera
x-markdown-tokenscon una estimación de tokens del Markdown, útil para monitorizar costes y estrategias de chunking.
En otras palabras: ya no se trata solo de “publicar contenido”, sino de publicarlo con negociación, igual que se negocia compresión, idiomas o tipos MIME.
llms.txt: cuando la documentación se convierte en capa editorial
AgentReady.md insiste además en un estándar emergente: llms.txt, un archivo en Markdown en la raíz del dominio que funciona como guía para agentes (un “índice editorial” con enlaces a páginas clave). En algunos enfoques se diferencia también una variante llms-full.txt, pensada como versión extendida con contenido embebido.
Para devs y sysadmins esto tiene un punto interesante: llms.txt no sustituye SEO ni accesibilidad, pero sí crea una “puerta de entrada” explícita para consumidores no humanos. Y, si el tráfico agéntico crece, esa puerta puede convertirse en un activo real: reduce ambigüedad y evita que el agente “adivine” qué páginas son las importantes.
Preguntas frecuentes
¿Qué tipo de webs se benefician más de AgentReady.md a nivel técnico?
Especialmente las que viven de contenido y estructura (medios, documentación, blogs técnicos, knowledge bases), y también ecommerce con fichas de producto donde la semántica y los metadatos determinan si un agente entiende precio, disponibilidad o variaciones.
¿Qué cambios suelen mejorar más rápido la “AI-readiness” sin rehacer el sitio?
Normalmente: jerarquía correcta de encabezados, uso de main/article/section, textos alternativos en imágenes informativas, limpieza de plantillas con menos “ruido” y señales básicas de descubrimiento (sitemap y llms.txt).
¿Cómo se sirve Markdown a agentes sin mantener dos webs distintas?
Con negociación de contenido: el cliente solicita Accept: text/markdown y el servidor (o el edge) entrega Markdown manteniendo la misma URL canónica.
¿Por qué se habla tanto de tokens y coste al hablar de agentes?
Porque HTML suele arrastrar mucho “peso” no semántico. En el ejemplo publicado por Cloudflare, una página pasa de 16.180 tokens en HTML a 3.150 en Markdown (-80 %), lo que impacta directamente en coste de procesamiento y en el contexto útil disponible para el modelo.
