Cloudflare ha puesto sobre la mesa una idea sencilla con implicaciones enormes para cualquiera que trabaje con modelos de lenguaje: servir una versión en Markdown de una página web bajo demanda, sin tocar el sitio ni mantener “dobles” versiones. El nombre del lanzamiento es Markdown for Agents y su promesa se entiende en una cifra: una página que, en HTML, podía consumir 16.180 tokens, pasaría a 3.150 tokens al entregarse en Markdown, es decir, alrededor de un 80 % menos de “presupuesto” de contexto.
La medida llega en un momento en el que el tráfico ya no depende solo de buscadores y usuarios humanos. Cada vez más herramientas y agentes de Inteligencia Artificial rastrean documentación, comparan información o extraen contenido para responder preguntas, generar código o automatizar tareas. En ese escenario, el HTML —diseñado para renderizar una interfaz— se convierte en un lastre: menús, capas, estilos, scripts y plantillas ocupan tokens… aunque no aporten significado al modelo.
Cómo funciona: negociación de contenido en HTTP y conversión en el edge
El mecanismo se apoya en una pieza clásica de Internet: la negociación de contenido por cabeceras HTTP. Si el cliente (un agente, un crawler o una herramienta de programación) envía una petición con:
Accept: text/markdown
y el dominio tiene la opción activada, Cloudflare recoge el HTML original del servidor, lo convierte a Markdown en su red y devuelve un documento “limpio” con content-type: text/markdown, además de Vary: accept para separar variantes en caché.
La propia Cloudflare señala que algunos agentes de codificación ya están enviando este tipo de cabeceras por defecto, como Claude Code u OpenCode, lo que convierte el cambio en algo prácticamente automático para parte del ecosistema.
Y hay un detalle muy orientado a “gente de LLMs”: la respuesta en Markdown puede incluir una cabecera x-markdown-tokens con una estimación del tamaño del documento en tokens, útil para decidir si cabe en ventana de contexto o si conviene trocearlo.
Tabla comparativa: HTML vs Markdown para agentes de IA
| Aspecto | HTML (web “para humanos”) | Markdown (web “para agentes”) | Impacto práctico en LLMs/agents |
|---|---|---|---|
| Tamaño en tokens | Alto: incluye estructura, estilos, scripts y “ruido” | Más bajo: texto y jerarquía mínima | Más contenido útil por ventana de contexto; menos coste por consulta |
| Legibilidad semántica | Depende de la calidad del marcado (semántica vs “divitis”) | Depende de la conversión desde HTML | Si el HTML es caótico, el Markdown también puede serlo (no hay milagros) |
| Jerarquía de contenido | Existe, pero puede quedar diluida por plantillas | Títulos, listas y secciones suelen quedar más claros | Mejor chunking y recuperación por secciones en RAG y agentes |
| Negociación de formato | Nativo del navegador | Nativo para agentes (mediante Accept) | Permite servir el mismo contenido con representaciones distintas sin otra URL |
| Control del publisher | Entrega HTML “tal cual” | Opt-in a una representación alternativa | El editor decide si habilita el modo agente y cómo se integra en su estrategia |
| Señales de uso para IA | No necesariamente explícitas | Puede incluir Content-Signal por defecto | Abre un debate sobre gobernanza del uso de contenido por sistemas de IA |
| Compatibilidad con contenido dinámico | Completa (renderizado final en cliente) | Limitada si el HTML no trae contenido real | Para SPAs puede ser insuficiente; Cloudflare sugiere alternativas con renderizado real |
| Riesgos de “doble realidad” | Menor: un único formato | Mayor: una variante específica para bots | Surge el debate de “cloaking” y necesidad de verificación |
Lo interesante para un medio tech: eficiencia, trazabilidad y métricas
Más allá del ahorro, hay dos lecturas técnicas de peso:
1) Observabilidad del consumo por agentes. Cloudflare afirma que Radar ya muestra insights por tipo de contenido servido a bots y crawlers, con filtros para ver el reparto por MIME type y detectar peticiones de Markdown por agente concreto (incluido el ejemplo con OAI-Searchbot).
En un mundo donde la “audiencia” ya no es solo humana, poder medir qué consumen las máquinas se vuelve una variable de negocio.
2) Un estándar en lugar de heurísticas privadas. Hasta ahora, muchos agentes convertían HTML a texto/Markdown con sus propias reglas, lo que generaba resultados inconsistentes. Aquí, la conversión pasa a producirse “en el borde” de la red, de forma más homogénea. La contrapartida es evidente: se delega una capa de representación en un intermediario, y la fidelidad dependerá de cómo Cloudflare interprete el HTML.
Limitaciones (y por qué importan en producción)
Cloudflare marca límites concretos en su documentación. Por ejemplo, el sistema no devuelve Markdown si la respuesta del origen no incluye content-length o si supera 1 MB (1.048.576 bytes); en esos casos, devuelve el HTML original. Además, no soporta respuestas comprimidas desde el origen y, de momento, solo convierte HTML.
Para quienes trabajan con documentación extensa o páginas muy pesadas, esto no es un detalle menor: obliga a revisar cabeceras, tamaños y comportamiento de caché si se quiere que la conversión funcione con fiabilidad.
En cuanto a contenido dinámico, Cloudflare sugiere vías alternativas como un endpoint de Browser Rendering para convertir a Markdown tras renderizar “en un navegador real”, precisamente para cubrir los casos donde el HTML estático no representa lo que ve el usuario final.
El debate inevitable: ¿optimización para agentes o puerta al cloaking?
Como era previsible, el lanzamiento también ha encendido alertas en el ecosistema SEO. Hay quien ve el riesgo de que, al existir una variante “para máquinas”, algunos sitios intenten servir contenido diferente a agentes. Search Engine Land recoge este debate y lo enmarca como una posible forma de “AI cloaking” si se abusa de la dualidad de representaciones.
Cloudflare, en su planteamiento, intenta minimizar esa fricción: no hay “otra URL”, sino variantes por cabecera. Pero, desde el punto de vista de un sistema externo, el reto es el mismo: si existen dos representaciones, alguien tendrá que decidir cuál es la realidad (o si hay que compararlas).
La conclusión: el Markdown ayuda, pero no arregla un HTML malo
Markdown for Agents es una mejora pragmática para la web que consumen agentes: menos tokens, más contenido utilizable y una ruta estándar para pedirlo. Pero la calidad final sigue dependiendo de lo de siempre: HTML semántico y bien estructurado. Si la página está construida como una maraña de contenedores y elementos sin significado, la conversión tendrá poco que “rescatar”.
En la práctica, el lanzamiento abre una nueva disciplina para equipos tech y de contenido: no se trata solo de escribir para humanos o para buscadores, sino de diseñar páginas que puedan traducirse con fidelidad a formatos que las máquinas consumen mejor.
Preguntas frecuentes
¿Cómo se activa Markdown for Agents en una web?
Se habilita a nivel de zona en Cloudflare (opción “Markdown for Agents”) y los agentes lo solicitan con Accept: text/markdown.
¿Qué ahorro real de tokens se puede esperar al pasar de HTML a Markdown?
Depende de la página, pero Cloudflare ha compartido ejemplos con reducciones cercanas al 80 %, como pasar de 16.180 tokens (HTML) a 3.150 (Markdown).
¿Qué limitaciones técnicas tiene la conversión?
No convierte si falta content-length o si el contenido supera 1 MB (1.048.576 bytes). Tampoco soporta respuestas comprimidas desde el origen y, por ahora, solo convierte HTML.
¿Puede considerarse “cloaking” servir Markdown a agentes y HTML a humanos?
El debate existe: no crea otra URL, pero sí una representación diferente por cabecera. Parte del sector SEO advierte de posibles abusos y de la necesidad de controles.
