Cuando un agente de IA lee uno de nuestros artículos del blog, la versión HTML pesa 466 KB. Las palabras de ese artículo pesan 18 KB. Todo lo demás es markup, estilos y payload del framework que un modelo de lenguaje paga en tokens y luego descarta.
Esta semana desplegamos la solución en todo el blog: cada uno de nuestros 208 artículos, en los tres idiomas, tiene ahora un gemelo en Markdown puro. Toma cualquier URL de artículo, añade .md, y obtienes el texto limpio. Son 624 archivos estáticos, generados en el build, servidos con cero coste en runtime. La versión Markdown del artículo que medimos es un 96 por ciento más pequeña que su hermano HTML.
Este artículo explica por qué lo hicimos, cómo funciona la capa, por qué rompimos deliberadamente con el patrón que usan Vercel y Cloudflare, y qué aporta esto de forma realista a la visibilidad en IA y qué no.
La mitad olvidada del estándar llms.txt#
La mayoría conoce llms.txt como el "robots.txt para IA": un archivo Markdown en la raíz del dominio que explica a los modelos de lenguaje de qué va tu web. Jeremy Howard propuso el estándar en septiembre de 2024, y los estudios de adopción de 2026 lo sitúan en aproximadamente uno de cada diez dominios.
Lo que casi todos se saltan es la segunda mitad de la misma propuesta. La especificación recomienda expresamente que las páginas "ofrezcan una versión Markdown limpia de esas páginas en la misma URL que el original, pero con .md añadido".
En esa segunda mitad está el valor real. Un llms.txt es un índice. Las páginas .md son la comida de verdad. Un índice sin capítulos legibles detrás es exactamente la razón por la que varios análisis independientes de este año concluyeron que un llms.txt por sí solo no mueve las tasas de citación de forma medible.
Las plataformas de documentación lo entendieron primero. Stripe, Anthropic, Neon y FastAPI sirven Markdown limpio si añades .md a una URL de docs. Mintlify integró la negociación de contenido en cada sitio de documentación que aloja. Sentry sirve Markdown a los agentes en las mismas URLs que usan los humanos. En febrero de 2026, Vercel confirmó que Claude Code y OpenCode ya envían cabeceras Accept: text/markdown con sus peticiones, y en marzo Cloudflare lanzó Markdown for Agents, convirtiendo HTML a Markdown en el edge.
Así que la convergencia entre las empresas de infraestructura ya está hecha. Lo que no vemos: webs de negocio y blogs normales siguiendo el ejemplo. Esa brecha es la oportunidad.
Por qué la economía de tokens decide esto#
El argumento no es estético, es aritmética.
Nuestro ejemplo medido: 466.398 bytes de HTML frente a 18.028 bytes de Markdown para un artículo de 2.900 palabras. Un factor de 26. Vercel reporta alrededor de un 90 por ciento de reducción de tamaño en sus páginas negociadas; nuestros gemelos estáticos llegan al 96 por ciento porque no queda boilerplate en absoluto.
Para un agente, esa diferencia no es cosmética. Payloads más pequeños significan menos tokens por página, lo que significa que un agente investigando un tema puede permitirse leer veinte de tus artículos en lugar de uno. También significa menos errores de parsing: sin banners de cookies, sin navegación, sin etiquetas script que los conversores de HTML a texto destrozan a mitad de frase.
El lado del tráfico lo hace urgente. Los datos de Cloudflare Radar de junio de 2026 muestran que las peticiones automatizadas ya suponen más de la mitad del tráfico HTML de la web, con los crawlers de IA en torno a una quinta parte del tráfico de bots verificado. Y las proporciones entre rastreos y visitas son brutales: los crawlers de Anthropic descargan miles de páginas por cada visita que devuelven. Esas descargas ocurren igual, las sirvas bien o mal. Servirlas mal solo significa que pagas el ancho de banda y aun así te leen mal.
Qué construimos exactamente#
La capa tiene cuatro partes, y todas son estáticas. Nada se ejecuta en tiempo de petición, no se llama a ninguna API, no interviene ningún modelo.
Gemelos Markdown. Cada URL de artículo acepta .md: por ejemplo /es/blog/claude-guide-2026.md. Cada archivo empieza con frontmatter YAML con el título, la descripción, el autor, las fechas de publicación y actualización, las etiquetas, la URL HTML canónica y las URLs de las tres versiones de idioma. Debajo está el artículo completo, con cada enlace relativo reescrito a absoluto, más un breve bloque de lecturas relacionadas del mismo clúster temático, también como enlaces .md. Un agente que aterriza en un artículo puede seguir leyendo sin tocar nunca el HTML.
Feeds que llevan el contenido. Nuestros feeds RSS incluyen ahora el HTML completo del artículo para los veinte posts más recientes, no solo descripciones. Hay un endpoint JSON Feed, y cada uno de nuestros 26 clústeres temáticos tiene su propio feed, de modo que un suscriptor, humano o máquina, puede seguir solo "Claude y Claude Code" o solo "visibilidad en IA".
Descubrimiento. El head HTML de cada artículo enlaza su gemelo Markdown vía <link rel="alternate" type="text/markdown">, igual que se anuncia un feed RSS. Nuestro llms.txt lista las 26 rutas de lectura y declara la convención .md una vez, de forma prominente. El JSON Feed lleva la URL Markdown por entrada como campo de extensión.
Consolidación. Cada respuesta .md envía una cabecera HTTP Link que declara la página HTML como canónica. Sin juegos de noindex: los buscadores consolidan las señales en la versión HTML, mientras los agentes consumen el Markdown libremente.
Como los metadatos del blog viven en un único archivo fuente tipado, toda la capa se regenera en cada build. Un artículo nuevo recibe sus tres gemelos, sus entradas de feed y su listado en llms.txt automáticamente.
Por qué elegimos URLs explícitas en lugar de negociación de contenido#
Vercel y Cloudflare defienden la negociación de contenido: una URL, y el servidor decide según la cabecera Accept si devuelve HTML o Markdown. Es elegante, y para su infraestructura es la elección correcta.
Nosotros deliberadamente no lo hicimos, y la razón es el caching.
Cualquier web detrás de una caché edge de CDN tiene que responder una pregunta con honestidad: ¿tu clave de caché incluye la cabecera Accept? En los planes habituales de CDN la respuesta práctica es no. El edge guarda una variante por URL. Imagina que un agente pide tu artículo con Accept: text/markdown justo en el momento en que la caché está fría. La respuesta Markdown queda cacheada bajo la URL del artículo, y los siguientes mil visitantes humanos reciben Markdown crudo en el navegador. La negociación de contenido detrás de un edge que ignora Vary es un incidente de cache poisoning esperando su detonante.
Las URLs .md explícitas hacen el problema estructuralmente imposible. Dos URLs, dos entradas de caché, ninguna ambigüedad. Cuesta un poco de elegancia y compra predictibilidad total. Si controlas tu configuración edge de punta a punta, negocia. Si estás en un plan estándar de CDN, las URLs explícitas son la arquitectura más segura, y además son exactamente lo que la especificación llms.txt recomendó desde el principio.
La parte honesta: lo que esto no hace#
Aquí quiero ser preciso, porque este campo está lleno de promesas infladas.
Servir Markdown no hará, por sí solo, que ChatGPT te cite. Los datos de 2026 son claros: la adopción de llms.txt por sí sola no muestra ningún efecto medible en las citas, y no tengo motivos para creer que los gemelos .md solos se comporten distinto. Las citas nacen de contenido que responde preguntas reales, de datos estructurados que las máquinas pueden verificar, de entidades consistentes y de una indexación real. Nuestras propias cifras, más de 14.100 citas de Bing Copilot en la ventana móvil de 30 días a principios de julio de 2026, salen de todo ese stack trabajando junto durante meses. La capa Markdown es un ladrillo, no el edificio.
Lo que la capa sí entrega hoy: los agentes que ya hablan este dialecto leen tu web por una fracción del coste. Claude Code envía la cabecera Accept de Markdown ahora. Cursor, Windsurf y otros agentes de IDE descargan llms.txt de forma rutinaria cuando los apuntas a una web. Cada una de esas interacciones funciona mejor cuando detrás de la puerta hay Markdown limpio. Y cuando un asistente lee tu artículo limpio en lugar de extraerlo de 466 KB de markup, sube la probabilidad de que represente tu contenido correctamente. Esa es la promesa realista: más barato de leer, más difícil de citar mal, listo para el mix de tráfico hacia el que la web se mueve a la vista de todos.
Cómo montarlo en tu propio stack#
El patrón es portable a cualquier stack que conozca su contenido en tiempo de build.
- Genera los gemelos en el build. Si tu contenido ya vive en Markdown, tienes el 80 por ciento hecho: un archivo
.mdpor página y por idioma, con frontmatter para el título, la URL canónica y las traducciones. Reescribe los enlaces relativos a absolutos para que el archivo sobreviva fuera de su contexto. - Configura la cabecera Link canónica. Cada respuesta Markdown debería declarar a su hermano HTML como canónico. Así tu configuración de buscadores queda intacta.
- Anúncialo. Añade la etiqueta de enlace alternate a tus heads HTML y declara la convención una vez en tu llms.txt. El descubrimiento es la mitad de la funcionalidad; un endpoint que no se puede descubrir no existe.
- Usa los atajos de tu plataforma. En Cloudflare, Markdown for Agents es un ajuste de zona. Para WordPress ya hay plugins que sirven Markdown. Si estás en una plataforma de docs como Mintlify, ya lo tienes.
Un ejemplo funcionando está a un clic: este mismo artículo, como todos los de este blog, tiene su gemelo en esta URL con .md añadido. Si quieres esa misma capa, más los datos estructurados y el stack de medición alrededor, construida para tu web: exactamente eso hacemos.
Hacia dónde va esto#
La web ya cruzó la línea en la que las máquinas piden más HTML que los humanos. Cada línea de tendencia que veo dice que la brecha se amplía: el tráfico de agentes crece, las páginas vistas por humanos por tarea se reducen, y las webs que responden limpio a las peticiones de máquinas se leen más, se citan mal menos, y se citan cuando cuenta.
Los gemelos Markdown parecerán obvios dentro de dos años, igual que el diseño responsive parece obvio hoy. El estándar ya los pide, las herramientas existen en cada stack, y el coste es un paso de build. Lo único genuinamente sorprendente es cuán pocas webs fuera del mundo de la documentación lo han desplegado. Por una vez, llegar pronto sale barato.
