Estándares Web para IA: llms.txt, NLWeb, Schema Maps y Content Negotiation [2026]

TLDR: Cuatro nuevos estándares web compiten por definir cómo los agentes de IA consumen contenido: llms.txt (índice curado en markdown), Content Negotiation (servir markdown vía cabecera Accept), Schema Maps (endpoints de datos estructurados agregados) y NLWeb (protocolo conversacional de Microsoft). No son mutuamente excluyentes: cada uno cubre una capa distinta (descubrimiento, consumo, estructura, conversación). El mejor enfoque en 2026 es implementarlos de forma incremental, empezando por los de menor esfuerzo y mayor impacto.

Por qué la web necesita nuevos estándares para IA

La web fue diseñada para humanos. HTML, CSS y JavaScript producen páginas visualmente ricas pero llenas de ruido para una máquina: barras de navegación, footers, popups de cookies, scripts de tracking, iframes publicitarios. Cuando un LLM intenta extraer información útil de una página web, tiene que filtrar toneladas de basura antes de llegar al contenido real.

Hasta 2024, los agentes de IA se las arreglaban con scraping HTML y alguna heurística. Pero a medida que los modelos se integran en flujos de trabajo reales (búsqueda, compras, reservas, soporte técnico), esa aproximación ad-hoc no escala.

De ahí la explosión de propuestas en 2025-2026: múltiples estándares que intentan resolver, cada uno desde un ángulo distinto, cómo hacer la web legible para máquinas.

El paralelo histórico con XML Sitemaps

En junio de 2005, Google lanzó el formato Sitemaps XML. Era una propuesta unilateral de un solo buscador. Muchos webmasters dijeron: "¿Para qué implementar algo que solo usa Google?". Yahoo se unió en 2006. Microsoft (Live Search) en 2007. Para 2008, era un estándar de facto.

La lección es clara: los estándares web no nacen por consenso universal; nacen porque alguien los construye, los early adopters los implementan, y el resto sigue cuando los beneficios son innegables. Lo mismo ocurrió con robots.txt (1994), RSS (1999), OpenGraph (2010) e IndexNow (2021).

Los estándares web para IA están exactamente en esa fase de 2005-2007. No esperes a que todos los actores se pongan de acuerdo: para cuando eso ocurra, los que implementaron temprano ya llevarán años de ventaja.

¿Quién está moviendo las piezas?

1. llms.txt: El "robots.txt para LLMs"

Qué es

llms.txt es un archivo de texto plano alojado en la raíz de un sitio web (/.well-known/llms.txt o /llms.txt) que proporciona a los modelos de lenguaje un índice curado del contenido del sitio en formato markdown.

Fue propuesto por Jeremy Howard, cofundador de fast.ai y Answer.AI, en septiembre de 2024. La idea es simple: así como robots.txt le dice a los crawlers qué pueden y qué no pueden rastrear, llms.txt le dice a los LLMs dónde está el contenido más relevante y cómo consumirlo.

Cómo funciona

El archivo sigue una estructura markdown sencilla:

1# Nombre del Sitio
2 
3> Descripción breve del sitio y su propósito.
4 
5## Documentación
6 
7- [Guía de inicio rápido](/docs/quickstart.md): Cómo empezar en 5 minutos
8- [API Reference](/docs/api.md): Documentación completa de la API
9- [FAQ](/docs/faq.md): Preguntas frecuentes
10 
11## Blog
12 
13- [Novedades v3.0](/blog/v3-release.md): Changelog de la última versión
14- [Tutorial de autenticación](/blog/auth-tutorial.md): OAuth2 paso a paso
15 
16## Optional
17 
18- [Términos legales](/legal/terms.md)
19- [Política de privacidad](/legal/privacy.md)

Cada enlace apunta a una versión markdown del contenido (no HTML), con una breve descripción de lo que contiene. Los LLMs pueden leer este archivo, entender la estructura del sitio, y navegar directamente al contenido relevante sin parsear HTML.

Variantes del estándar

• llms.txt: Índice con enlaces a documentos markdown individuales
• llms-full.txt: Versión expandida que incluye todo el contenido inline (sin necesidad de seguir enlaces)

Estado de adopción (abril 2026)

La adopción ha sido notable en el ecosistema de documentación técnica:

Cómo implementarlo

Paso 1: Crear el archivo

1# En la raíz de tu sitio web
2touch public/llms.txt

Paso 2: Estructurar el contenido

1# Mi Empresa SaaS
2 
3> Plataforma de automatización para pymes españolas. 
4> Conectamos herramientas de negocio con IA.
5 
6## Documentación principal
7 
8- [Qué es nuestra plataforma](/docs/que-es.md): Explicación general del producto
9- [Guía de inicio](/docs/inicio.md): Primeros pasos en 10 minutos
10- [Integraciones](/docs/integraciones.md): Lista de 50+ integraciones disponibles
11- [Precios](/docs/precios.md): Planes y precios actualizados
12 
13## Casos de uso
14 
15- [Automatizar facturación](/blog/automatizar-facturacion.md): Tutorial paso a paso
16- [CRM con IA](/blog/crm-ia.md): Cómo configurar el CRM inteligente
17 
18## API
19 
20- [Referencia API](/api/reference.md): Endpoints, autenticación, rate limits
21- [Webhooks](/api/webhooks.md): Configuración de webhooks

Paso 3: Asegurar que los recursos apuntados devuelvan markdown

Este es el punto clave y donde muchos fallan: los enlaces de tu llms.txt deben apuntar a contenido en markdown limpio, no a páginas HTML. Tienes varias opciones:

1Opción A: Archivos .md estáticos en /public/
2Opción B: Endpoint API que devuelva markdown
3Opción C: Content Negotiation (siguiente sección)

Paso 4: Servir con cabeceras correctas

1# nginx
2location /llms.txt {
3    default_type text/plain;
4    add_header Cache-Control "public, max-age=86400";
5}

En Next.js (App Router):

1// app/llms.txt/route.ts
2import { NextResponse } from 'next/server'
3import fs from 'fs'
4import path from 'path'
5 
6export async function GET() {
7  const filePath = path.join(process.cwd(), 'public', 'llms.txt')
8  const content = fs.readFileSync(filePath, 'utf-8')
9  
10  return new NextResponse(content, {
11    headers: {
12      'Content-Type': 'text/plain; charset=utf-8',
13      'Cache-Control': 'public, max-age=86400',
14    },
15  })
16}

Pros y contras

2. Content Negotiation / Markdown for Agents

Qué es

Content Negotiation es un mecanismo HTTP que ya existe desde los años 90 (RFC 2616, sección 12): permite que un cliente solicite un formato específico de contenido usando la cabecera Accept. La propuesta de Joost de Valk (creador de Yoast SEO) es usar este mecanismo para que los agentes de IA soliciten versiones markdown de páginas web.

La idea: cuando un navegador pide una página, envía Accept: text/html. Cuando un agente de IA pide la misma URL, envía Accept: text/markdown. El servidor devuelve la misma información, pero en formato limpio y legible para máquinas.

Cómo funciona

1Petición humana (navegador):
2GET /blog/mi-articulo HTTP/1.1
3Accept: text/html
4→ Respuesta: página HTML completa con CSS, JS, nav, footer...
5 
6Petición agente IA:
7GET /blog/mi-articulo HTTP/1.1
8Accept: text/markdown
9→ Respuesta: contenido markdown limpio, sin adornos

La belleza de este enfoque es que usa la misma URL. No necesitas crear endpoints separados ni archivos duplicados. Es la misma URL, distinto formato según quién pida.

Implementación en Next.js

1// app/blog/[slug]/route.ts
2import { NextRequest, NextResponse } from 'next/server'
3import { getPostBySlug } from '@/lib/data'
4 
5export async function GET(
6  request: NextRequest,
7  { params }: { params: { slug: string } }
8) {
9  const accept = request.headers.get('accept') || ''
10  const post = await getPostBySlug(params.slug)
11  
12  if (!post) {
13    return new NextResponse('Not found', { status: 404 })
14  }
15  
16  // Si el agente pide markdown
17  if (accept.includes('text/markdown')) {
18    return new NextResponse(post.markdownContent, {
19      headers: {
20        'Content-Type': 'text/markdown; charset=utf-8',
21        'Vary': 'Accept',
22      },
23    })
24  }
25  
26  // Si no, renderizar HTML normal
27  // (Next.js lo maneja automáticamente vía page.tsx)
28}

Implementación en WordPress (Yoast)

Yoast SEO ya incluye esta funcionalidad de forma nativa desde la versión 24.x:

1// functions.php (si quieres personalizar)
2add_filter('yoast_markdown_content', function($markdown, $post) {
3    // Personalizar el markdown generado
4    return $markdown;
5}, 10, 2);

Con Yoast instalado y actualizado, cualquier petición con Accept: text/markdown a una URL de tu sitio WordPress devuelve automáticamente el contenido en markdown limpio.

Implementación en nginx (cualquier sitio)

1# Servir .md si existe y el cliente pide markdown
2map $http_accept $markdown_suffix {
3    default "";
4    "~text/markdown" ".md";
5}
6 
7server {
8    location /blog/ {
9        try_files $uri$markdown_suffix $uri $uri/ =404;
10    }
11}

La cabecera Vary

Un detalle técnico importante: cuando implementas Content Negotiation, debes incluir Vary: Accept en la respuesta. Esto le dice a cachés y CDNs que la respuesta varía según la cabecera Accept, evitando que un CDN cachee la versión markdown y la sirva a navegadores (o viceversa).

1HTTP/1.1 200 OK
2Content-Type: text/markdown; charset=utf-8
3Vary: Accept
4Cache-Control: public, max-age=3600

El debate: ¿nuevo media type o extensión existente?

Hay un debate abierto en la comunidad sobre si text/markdown (RFC 7763) es suficiente o si debería crearse un subtipo específico como text/markdown+agent. La propuesta de Joost sugiere que text/markdown es suficiente, pero algunos proponen añadir un parámetro de perfil:

1Accept: text/markdown; profile="https://llmstxt.org/v1"

Esto permitiría diferenciar entre "quiero markdown genérico" y "quiero markdown optimizado para LLMs". Por ahora, text/markdown sin más es lo que la mayoría implementa.

Pros y contras

Testear Content Negotiation

1# Petición como navegador
2curl -H "Accept: text/html" https://ejemplo.com/blog/mi-articulo
3 
4# Petición como agente IA
5curl -H "Accept: text/markdown" https://ejemplo.com/blog/mi-articulo
6 
7# Ver cabeceras de respuesta
8curl -I -H "Accept: text/markdown" https://ejemplo.com/blog/mi-articulo

3. Schema Maps / Schema Endpoints

Qué es

Schema Maps (también llamados Schema Endpoints) es una propuesta de Joost de Valk que extiende el concepto de datos estructurados (Schema.org) con un mecanismo de descubrimiento y agregación. En lugar de tener JSON-LD fragmentado dentro de cada página HTML, Schema Maps proporciona un endpoint centralizado donde un agente puede obtener todos los datos estructurados del sitio de golpe.

El problema que resuelve

Hoy, si un agente quiere obtener los datos estructurados de un sitio web, tiene que:

1. Crawlear cada página individualmente
2. Parsear el HTML de cada una
3. Extraer los bloques