Web agent-ready — representaciones de máquina: HTML, Markdown y chrome

En resumen

• Los agentes y crawlers suelen leer DOM, árbol de accesibilidad o Markdown — no la página "decorada" que ve un humano.
• La negociación de contenido (Accept: text/markdown) es un mecanismo HTTP estándar, implementado por varias plataformas — no una invención de un único proveedor.
• Las reducciones de HTML a Markdown en casos publicados varían de ~20% a ~99%, pero son ejemplos, no promedios de la web.
• La adopción de negociación de Markdown sigue siendo rara y no todo agente la solicita — mídela en tu tráfico antes de invertir.

Qué lee realmente un agente

Un agente de navegador rara vez “ve” la página como la ve un humano. Según web.dev, las herramientas de IA operan sobre representaciones de máquina — screenshot, HTML/DOM bruto y el árbol de accesibilidad — a menudo combinadas. El árbol de accesibilidad resume roles, nombres y estados de cada elemento e ignora el ruido visual del CSS; por eso, el mismo artículo recomienda HTML interactivo semántico (button, a) en lugar de div/span decorados, asociaciones correctas de label y diseños estables. [1]

La guía de Google Search Central para funciones de IA generativa refuerza este punto: el HTML semántico es una buena práctica para humanos y lectores de pantalla; una validez perfecta de HTML no es obligatoria; y los agentes de navegador pueden usar screenshot, DOM y árbol de accesibilidad. La propia documentación describe la preparación para agentes como opcional — algo que hacer “si hay tiempo extra”, no un requisito. [2]

Cómo servir una representación de máquina

El mecanismo base es HTTP común: content negotiation. El cliente envía una cabecera Accept que indica el formato preferido; el servidor elige la representación y la señala a los cachés con Vary, según la documentación de MDN. [3] Sobre ese mecanismo, varias plataformas documentan patrones similares: Vercel publica una guía para servir Markdown y HTML en la misma URL mediante Accept: text/markdown (rewrites + route handler); Fastly describe un servicio de borde que entrega HTML a navegadores y Markdown a crawlers de IA conocidos o a solicitudes explícitas, siempre variando por Accept y User-Agent; y Cloudflare documenta una conversión equivalente a nivel de zona, eliminando cabecera, navegación, pie de página y scripts del cuerpo Markdown y preservando JSON-LD al final del documento. [4] [5] [6]

Ninguna de estas implementaciones es un estándar único del sector — son la misma idea (content negotiation) aplicada por proveedores diferentes. Publicar archivos Markdown estáticos (como /index.md) o un índice llms.txt es otra estrategia, usada por ejemplo en la propia documentación Cloudflare Docs for agents — más simple de operar, pero con riesgo de que el Markdown se “despegue” del HTML canónico con el tiempo. [7]

Casos publicados: cuánto pesa esto

Los publishers informan reducciones significativas de tamaño al cambiar HTML por Markdown — pero son estudios de caso, no un promedio medido de la web. Cloudflare citó, en un post de blog, un ejemplo con cerca de 16.180 tokens en HTML frente a 3.150 en Markdown (~80% menos) [8]; Checkly midió, en su propia documentación, cerca de 615 KB / 180 mil tokens en HTML frente a 2,3 KB / 478 tokens en Markdown (~99,6% menos) [9]; y Fastly describe, de forma cualitativa, artículos típicos comprimiéndose a 20–30% del tamaño del HTML original [5].

La negociación de Markdown solo ayuda a quien la solicita: Checkly probó siete agentes de código y encontró solo tres (Claude Code, Cursor y OpenCode) enviando Accept para pedir text/markdown — los otros cuatro (Codex, Gemini CLI, GitHub Copilot y Windsurf) no priorizaron Markdown en la muestra observada. [9] Un snapshot de Cloudflare Radar, citado en el blog de Agent Readiness de la propia empresa, midió que la negociación de Accept: text/markdown se da en solo 3,9% de los sitios de alto tráfico escaneados — un retrato puntual de baja adopción, no una línea de base estable. [10]

Chrome, costo y tráfico de bots

El “chrome” de la página — menú, pie de página, scripts, decoración — no tiene valor semántico para un agente, pero consume tokens de contexto de su lado y bytes de ancho de banda del lado de quien sirve el sitio. Las redes de borde informan un volumen creciente de tráfico de bots de IA: Fastly registró crawlers de IA representando casi 80% del tráfico de bots de IA observado en su análisis de mediados de 2025 (con Meta, Google y OpenAI como las mayores fracciones), y tráfico de bots automatizado general en 37% de la actividad de su propia red en el período; Akamai informó un crecimiento de aproximadamente 300% interanual en la actividad de bots de IA en su plataforma. [11] [12]

Reducir el chrome puede, en teoría, reducir bytes por solicitud de bot — pero es una hipótesis operativa, no un retorno financiero comprobado. Sin un estudio público de costo de origen/egress medido antes y después de un cambio de representación, el consejo práctico es medir bytes, estado y user-agent en los propios logs antes de prometer ahorro.

llms.txt: índice o vitrina

llms.txt funciona como un índice al estilo sitemap, pensado para herramientas que ya lo consumen — así lo describe la propia Cloudflare. [10] Pero la guía oficial de Google Search Central incluye llms.txt y markup especial de IA entre los errores que se deben evitar: no es requisito para aparecer en funciones de IA generativa en Search. [2] Un estudio de Ahrefs, que analizó cerca de 137 mil dominios, encontró que 28% publicaba un llms.txt válido, pero 97% de esos archivos no recibió ninguna solicitud en el mes medido — y, de los que recibieron tráfico, 96% de las solicitudes procedían de bots, no de lectura editorial. [13]

Esto no prueba que llms.txt sea inútil para siempre; prueba que, hoy, publicarlo rara vez cambia algo observable. Trátalo como una comodidad opcional para herramientas que ya consumen el formato — no como entregable prioritario.

Incertidumbres

• No hay estudio público que aísle el efecto de la conformidad con accesibilidad (WCAG) en el éxito de tareas de agentes, fuera del argumento cualitativo de Google/web.dev.
• No se sabe qué agentes y crawlers enviarán Accept: text/markdown de forma estable — la muestra de Checkly (3 de 7) es un retrato puntual.
• No existen datos operativos publicados sobre el costo real de mantener un árbol Markdown estático paralelo al HTML, incluido el riesgo de desalineación.
• No existe un estudio de caso público que mida ahorro de ancho de banda u origen en valores concretos, antes y después de servir Markdown negociado a bots.

Referencias

1. web.dev — Build agent-friendly websites. web.dev. Acceso el 07 ago. 2026.
2. Google Search Central — Optimizing your website for generative AI features on Google Search. Google. Acceso el 07 ago. 2026.
3. MDN — Content negotiation. MDN. Acceso el 07 ago. 2026.
4. Vercel — How to serve documentation for agents. Vercel. Acceso el 07 ago. 2026.
5. Fastly — Give AI Agents the Markdown They Actually Want. Fastly. Acceso el 07 ago. 2026.
6. Cloudflare — Markdown for Agents (docs). Cloudflare. Acceso el 07 ago. 2026.
7. Cloudflare — Docs for agents. Cloudflare. Acceso el 07 ago. 2026.
8. Cloudflare — Introducing Markdown for Agents. Cloudflare. Acceso el 07 ago. 2026.
9. Checkly — The Current State of Content Negotiation for AI Agents. Checkly. Acceso el 07 ago. 2026.
10. Cloudflare — Introducing the Agent Readiness score. Cloudflare. Acceso el 07 ago. 2026.
11. Fastly — New Fastly threat research reveals AI crawlers make up almost 80% of AI bot traffic. Fastly. Acceso el 07 ago. 2026.
12. Akamai — AI Bots Threaten Foundation of Web-Based Business Models. Akamai. Acceso el 07 ago. 2026.
13. Ahrefs — We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read. Ahrefs. Acceso el 07 ago. 2026.