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 <script type="application/ld+json">
4. Agregar todo manualmente

Esto es lento, costoso e ineficiente. Schema Maps propone un atajo: un archivo JSON accesible en una URL conocida que contiene o enlaza todos los datos estructurados del sitio.

Cómo funciona

Paso 1: Archivo de descubrimiento

El sitio publica un archivo en /.well-known/schema-map.json (o similar) que lista todos los endpoints de datos estructurados disponibles:

1{
2  "@context": "https://schema.org",
3  "@type": "DataFeed",
4  "name": "Schema Map de Mi Sitio",
5  "url": "https://ejemplo.com/.well-known/schema-map.json",
6  "dateModified": "2026-04-13T10:00:00Z",
7  "dataFeedElement": [
8    {
9      "@type": "DataFeedItem",
10      "url": "https://ejemplo.com/api/schema/articles",
11      "name": "Artículos del blog",
12      "description": "Datos estructurados de todos los artículos",
13      "encodingFormat": "application/ld+json"
14    },
15    {
16      "@type": "DataFeedItem",
17      "url": "https://ejemplo.com/api/schema/products",
18      "name": "Productos",
19      "description": "Datos estructurados de todos los productos",
20      "encodingFormat": "application/ld+json"
21    },
22    {
23      "@type": "DataFeedItem",
24      "url": "https://ejemplo.com/api/schema/faq",
25      "name": "FAQs",
26      "description": "Preguntas frecuentes estructuradas",
27      "encodingFormat": "application/ld+json"
28    }
29  ]
30}

Paso 2: Endpoints individuales

Cada endpoint del schema map devuelve un array de objetos JSON-LD:

1{
2  "@context": "https://schema.org",
3  "@graph": [
4    {
5      "@type": "Article",
6      "headline": "Cómo implementar IA en tu empresa",
7      "datePublished": "2026-04-01",
8      "author": {
9        "@type": "Person",
10        "name": "Javier Santos"
11      },
12      "url": "https://ejemplo.com/blog/implementar-ia-empresa"
13    },
14    {
15      "@type": "Article",
16      "headline": "n8n vs Make vs Zapier",
17      "datePublished": "2026-03-15",
18      "url": "https://ejemplo.com/blog/n8n-vs-make-vs-zapier"
19    }
20  ]
21}

Implementación en Next.js

1// app/.well-known/schema-map.json/route.ts
2import { NextResponse } from 'next/server'
3 
4export async function GET() {
5  const schemaMap = {
6    "@context": "https://schema.org",
7    "@type": "DataFeed",
8    "name": "Schema Map",
9    "url": "https://www.ejemplo.com/.well-known/schema-map.json",
10    "dateModified": new Date().toISOString(),
11    "dataFeedElement": [
12      {
13        "@type": "DataFeedItem",
14        "url": "https://www.ejemplo.com/api/schema/articles",
15        "name": "Blog articles",
16        "encodingFormat": "application/ld+json"
17      }
18    ]
19  }
20 
21  return NextResponse.json(schemaMap, {
22    headers: {
23      'Cache-Control': 'public, max-age=3600',
24    }
25  })
26}
27 
28// app/api/schema/articles/route.ts
29import { getBlogPosts } from '@/lib/data'
30 
31export async function GET() {
32  const posts = await getBlogPosts()
33  
34  const graph = posts.map(post => ({
35    "@type": "Article",
36    "headline": post.title,
37    "datePublished": post.date,
38    "url": `https://www.ejemplo.com/blog/${post.slug}`,
39    "description": post.excerpt,
40  }))
41 
42  return NextResponse.json({
43    "@context": "https://schema.org",
44    "@graph": graph
45  })
46}

Relación con Schema.org existente

Schema Maps no reemplaza los datos estructurados que ya tienes en tus páginas. Es una capa adicional de descubrimiento. La analogía perfecta:

• JSON-LD en cada página = el contenido de cada página individual
• Schema Map = el sitemap de tus datos estructurados
• XML Sitemap = el sitemap de tus URLs

Así como un sitemap XML no reemplaza a tus páginas sino que las indexa, un Schema Map no reemplaza tu JSON-LD sino que lo agrega y hace descubrible.

Pros y contras

4. NLWeb: El protocolo conversacional de Microsoft

Qué es

NLWeb (Natural Language Web) es un protocolo abierto publicado por Microsoft en mayo de 2025. A diferencia de los anteriores, que se centran en hacer contenido legible para IA, NLWeb permite que un agente de IA converse con un sitio web usando lenguaje natural.

Piensa en ello como: en lugar de que el agente lea tu contenido, le hace preguntas a tu sitio y tu sitio responde.

Cómo funciona

NLWeb define un protocolo de petición-respuesta basado en JSON:

Petición del agente:

1{
2  "query": "¿Cuánto cuesta el plan profesional?",
3  "context": {
4    "user_language": "es",
5    "user_location": "ES",
6    "previous_queries": []
7  },
8  "response_format": {
9    "type": "structured",
10    "schema": "https://schema.org/Offer"
11  }
12}

Respuesta del sitio:

1{
2  "status": "success",
3  "response": {
4    "text": "El plan profesional cuesta 29€/mes facturado anualmente o 39€/mes facturado mensualmente.",
5    "structured_data": {
6      "@type": "Offer",
7      "price": "29",
8      "priceCurrency": "EUR",
9      "description": "Plan Profesional - facturación anual",
10      "url": "https://ejemplo.com/precios#profesional"
11    },
12    "sources": [
13      {
14        "url": "https://ejemplo.com/precios",
15        "title": "Página de precios"
16      }
17    ],
18    "confidence": 0.95
19  }
20}

Arquitectura técnica

NLWeb usa una arquitectura de tres capas:

1Agente IA (cliente)
2    ↓ Petición JSON con query en lenguaje natural
3Endpoint NLWeb (servidor)
4    ↓ Procesa query con LLM + base de conocimiento local
5Respuesta estructurada (JSON + Schema.org)
6    ↓ El agente integra la respuesta en su flujo

El servidor NLWeb puede implementarse de varias formas:

1. RAG (Retrieval Augmented Generation): Busca en tu contenido y genera respuesta
2. Base de datos estructurada: Consulta directa a tu DB y respuesta formateada
3. Híbrido: Combina búsqueda semántica con datos estructurados

SDK y herramientas

Microsoft publicó un SDK de referencia en Python:

1# pip install nlweb
2from nlweb import NLWebServer, NLWebRequest
3 
4app = NLWebServer(
5    name="Mi Tienda",
6    description="Tienda online de electrónica",
7    content_sources=[
8        "./data/products.json",
9        "./data/faq.json",
10    ]
11)
12 
13@app.route("/nlweb")
14async def handle_query(request: NLWebRequest):
15    # El SDK maneja RAG internamente
16    response = await app.process_query(request.query)
17    return response
18 
19app.run(port=8080)

Descubrimiento: NLWeb + llms.txt

NLWeb se descubre a través del HTML de la página, mediante un <link> tag:

1<link rel="nlweb" href="https://ejemplo.com/api/nlweb" />

O a través de llms.txt:

1# Mi Sitio
2 
3## NLWeb Endpoint
4- [Consultas en lenguaje natural](https://ejemplo.com/api/nlweb): Endpoint NLWeb para consultas sobre productos y precios

Relación con MCP (Model Context Protocol)

NLWeb y MCP (el protocolo de Anthropic para herramientas de IA) son complementarios pero diferentes. Si te interesa saber más sobre MCP, tenemos una guía completa de MCP Servers.

Pros y contras

Cómo encajan todos los estándares juntos

Estos cuatro estándares no compiten entre sí. Cada uno cubre una capa distinta de la interacción IA-web:

1┌─────────────────────────────────────────────────┐
2│  Capa 4: CONVERSACIÓN                           │
3│  NLWeb → Consultas en lenguaje natural          │
4├─────────────────────────────────────────────────┤
5│  Capa 3: ESTRUCTURA                             │
6│  Schema Maps → Datos estructurados agregados    │
7├─────────────────────────────────────────────────┤
8│  Capa 2: CONSUMO                                │
9│  Content Negotiation → Markdown por URL         │
10├─────────────────────────────────────────────────┤
11│  Capa 1: DESCUBRIMIENTO                         │
12│  llms.txt → Índice de contenido relevante       │
13└─────────────────────────────────────────────────┘

El flujo completo de un agente IA

Imagina que un agente de IA quiere responder a la pregunta "¿Cuál es la mejor herramienta de automatización para pymes españolas?":

1. Descubrimiento (llms.txt): El agente lee ejemplo.com/llms.txt y descubre que existe un artículo sobre herramientas de automatización
2. Consumo (Content Negotiation): Pide esa URL con Accept: text/markdown y recibe el contenido limpio
3. Estructura (Schema Maps): Consulta el schema map para obtener datos estructurados adicionales (precios, ratings, comparativas)
4. Conversación (NLWeb): Si necesita una respuesta más específica, consulta el endpoint NLWeb con su pregunta

No todos los sitios necesitan las cuatro capas. Un blog puede funcionar con llms.txt + Content Negotiation. Un e-commerce probablemente necesita las cuatro.

Tabla resumen: cuándo usar cada estándar

El debate: construir ahora vs esperar

Hay dos escuelas de pensamiento en la comunidad SEO/web sobre estos estándares. Vale la pena entender ambas.

Postura A: "Constrúyelo ahora" (Yoast, Rank Math)

Joost de Valk (Yoast) y otros plugins de SEO para WordPress han adoptado la filosofía de implementar los estándares desde el primer momento, incluso antes de que haya adopción masiva por parte de los consumidores (agentes de IA).

Su argumento:

• Los sitemaps XML se implementaron años antes de que todos los buscadores los usaran
• IndexNow fue adoptado por millones de sitios antes de que Google mostrara interés
• El coste de implementación es bajo
• El riesgo de no implementar (quedarse atrás) es alto
• Los early adopters siempre tienen ventaja cuando el estándar madura

Postura B: "Esperemos a ver" (The SEO Framework)

Otros, como el equipo detrás de The SEO Framework (otro plugin SEO para WordPress), argumentan que implementar estándares inmaduros puede generar problemas:

• Los estándares pueden cambiar o desaparecer
• El mantenimiento tiene coste
• Sin consumidores que los usen, no hay beneficio real
• Mejor esperar a que haya masa crítica

Nuestra posición

La historia de la web es clara: los estándares que triunfaron fueron los que tuvieron early adopters agresivos. robots.txt, sitemaps XML, OpenGraph, JSON-LD, IndexNow... todos siguieron el mismo patrón: un actor los propone, los constructores los implementan, y el resto sigue.

Si estás leyendo esto y tienes una web, no esperes. El coste de implementar llms.txt es literalmente crear un archivo de texto. Content Negotiation requiere algo más de trabajo pero es un mecanismo HTTP estándar de 30 años. Schema Maps es más complejo pero si ya usas JSON-LD, es incremental.

Si te interesa profundizar en cómo los protocolos de indexación están evolucionando para la era de la IA, te recomendamos nuestro artículo sobre IndexNow, Sitemaps XML y la nueva indexación para buscadores e IA.

Guía de implementación: de menor a mayor esfuerzo

Nivel 1: llms.txt (30 minutos)

Esfuerzo: Mínimo Impacto: Medio-alto (descubrimiento)

1. Crea un archivo llms.txt en la raíz de tu sitio
2. Lista tus páginas más importantes con descripciones
3. Apunta los enlaces a versiones markdown (o a las URLs normales si aún no tienes Content Negotiation)
4. Despliega

1# Verifica que funciona
2curl https://tu-sitio.com/llms.txt

Nivel 2: Content Negotiation (2-4 horas)

Esfuerzo: Bajo-medio Impacto: Alto (consumo directo)

1. Implementa detección de Accept: text/markdown en tu servidor
2. Genera versiones markdown de tu contenido
3. Añade la cabecera Vary: Accept
4. Testea con curl

Nivel 3: Schema Maps (4-8 horas)

Esfuerzo: Medio Impacto: Alto (datos estructurados accesibles)

1. Crea endpoint /.well-known/schema-map.json
2. Implementa endpoints por tipo de contenido
3. Genera JSON-LD agregado desde tu base de datos
4. Actualiza llms.txt para referenciar el schema map

Nivel 4: NLWeb (2-5 días)

Esfuerzo: Alto Impacto: Muy alto (pero solo para ciertos tipos de sitio)

1. Configura un servicio RAG con tu contenido
2. Implementa el protocolo NLWeb
3. Añade el tag <link rel="nlweb"> en tu HTML
4. Testea con consultas reales
5. Monitoriza costes del LLM backend

Impacto en SEO y GEO

SEO tradicional

Estos estándares no reemplazan el SEO clásico. Tu sitio sigue necesitando:

• Contenido de calidad
• Meta tags optimizados
• Velocidad de carga
• Core Web Vitals
• Backlinks de calidad

Pero añaden una nueva dimensión: GEO (Generative Engine Optimization). Si quieres que tu contenido aparezca citado en respuestas de ChatGPT, Claude, Gemini o Perplexity, estos estándares facilitan que los agentes de IA encuentren, lean y citen tu contenido correctamente. Para una guía completa sobre cómo usar IA para SEO, te recomendamos ChatGPT para SEO.

Métricas a seguir

Un equipo especializado como Javadex puede ayudarte a implementar estos estándares y medir su impacto real en tu posicionamiento tanto en buscadores tradicionales como en motores generativos.

Estado del ecosistema por plataforma

WordPress

WordPress es donde más actividad hay, gracias a los plugins de SEO:

• Yoast SEO: Soporta llms.txt, Content Negotiation y Schema Maps desde la versión 24.x
• Rank Math: Soporta llms.txt y datos estructurados avanzados
• The SEO Framework: Postura de espera, sin implementación nativa aún
• All in One SEO: Soporte parcial de llms.txt

Next.js / React

No hay plugins out-of-the-box, pero la implementación manual es directa:

• llms.txt: Archivo estático en /public/ o route handler
• Content Negotiation: Middleware o route handlers
• Schema Maps: API routes
• NLWeb: API routes + servicio RAG externo

Si trabajas con Next.js y quieres profundizar en automatización, nuestra guía de APIs de IA para desarrolladores cubre los aspectos técnicos fundamentales.

Plataformas SaaS (Shopify, Wix, Squarespace)

La adopción en plataformas cerradas es más lenta:

• Shopify: Apps de terceros para llms.txt (limitadas)
• Wix: Sin soporte nativo
• Squarespace: Sin soporte

Para estos casos, la opción más viable es implementar un proxy o servicio externo que genere los archivos necesarios.

Predicciones para 2026-2027

Basándonos en la velocidad de adopción actual y los patrones históricos:

Muy probable (>80%)

• llms.txt se convierte en estándar de facto para documentación técnica
• Content Negotiation con markdown se integra en los principales CMS
• Google empieza a consumir llms.txt como señal de descubrimiento
• Al menos un buscador IA anuncia soporte oficial para Schema Maps

Probable (50-80%)

• NLWeb se integra en Bing y Copilot de forma nativa
• IETF formaliza alguno de estos estándares como RFC
• Los principales CDN (Cloudflare, Vercel, Netlify) añaden soporte nativo para Content Negotiation con markdown
• WordPress.com ofrece soporte nativo (no solo plugins)

Posible (20-50%)

• Google adopta NLWeb o crea su propia variante
• Se crea un estándar unificado que combine los cuatro
• Los generadores de sitios estáticos (Hugo, Astro, 11ty) incluyen estos estándares por defecto

Preguntas frecuentes

¿Necesito implementar los cuatro estándares?

No. Empieza por llms.txt (coste mínimo, impacto inmediato) y Content Negotiation si tu stack lo permite. Schema Maps es el siguiente paso si manejas datos estructurados. NLWeb solo tiene sentido para e-commerce, SaaS con documentación extensa o portales de servicios donde la interacción conversacional añade valor real.

¿llms.txt sustituye a robots.txt?

No, son complementarios. robots.txt controla el acceso (qué puede y qué no puede crawlear un bot). llms.txt facilita el descubrimiento (qué contenido es relevante y dónde encontrarlo en formato legible). Un agente de IA debería respetar robots.txt primero, y luego usar llms.txt como guía de contenido.

¿Qué pasa si Google no adopta estos estándares?

Google no adoptó IndexNow cuando se lanzó en 2021. A día de hoy, más de 60 millones de sitios lo usan porque Bing y Yandex sí lo soportan. El valor de un estándar no depende de un solo actor. Además, los agentes de IA (ChatGPT, Claude, Perplexity) son consumidores independientes de Google. Incluso si Google ignora estos estándares, los motores generativos los usarán.

¿Content Negotiation funciona con CDN como Cloudflare o Vercel?

Sí, pero necesitas configurar correctamente la cabecera Vary: Accept. Cloudflare y Vercel respetan la cabecera Vary para gestionar la caché. Sin ella, podrías servir markdown a navegadores o HTML a agentes. En Vercel con Next.js, los route handlers manejan esto nativamente.

¿NLWeb requiere tener un LLM corriendo en mi servidor?

No necesariamente en tu servidor, pero sí necesitas acceso a un LLM. Puedes usar APIs externas (OpenAI, Anthropic, etc.) para procesar las queries. El SDK de Microsoft permite configurar diferentes backends. El coste depende del volumen de consultas, pero para la mayoría de sitios es marginal (unos pocos euros al mes con modelos como GPT-4o-mini o Claude Haiku).

¿Estos estándares afectan mi posicionamiento en Google?

Directamente, no (por ahora). Google no ha confirmado usar ninguno como señal de ranking. Indirectamente, sí: facilitan que tu contenido sea citado en AI Overviews y en respuestas de agentes IA, lo que genera tráfico referido y señales de autoridad. Además, Schema Maps mejoran la calidad de tus datos estructurados, que sí es un factor de SEO reconocido.

¿Puedo usar estos estándares para controlar qué contenido ven los agentes de IA?

Parcialmente. llms.txt te permite curar qué contenido destacas, pero no impide que un agente crawlee el resto de tu sitio. Para control de acceso, sigue usando robots.txt con directivas específicas para user-agents de IA (como GPTBot, ClaudeBot, Google-Extended). Los estándares de esta guía son para facilitar el acceso, no para restringirlo.

¿Cuánto cuesta implementar todo esto?

Depende de tu stack. Para un sitio WordPress con Yoast, el coste es cero (viene incluido). Para un sitio Next.js custom, estima unas 8-16 horas de desarrollo para llms.txt + Content Negotiation + Schema Maps. NLWeb añade 2-5 días adicionales. Si contratas a un especialista en implementación de estándares web para IA, el coste típico en España ronda los 500-2.000 euros dependiendo de la complejidad.

Conclusión

Los estándares web para IA no son ciencia ficción: son protocolos reales, con implementaciones funcionales, que están definiendo cómo interactúan los agentes de IA con el contenido web. La pregunta no es si implementarlos, sino cuándo y en qué orden.

La recomendación pragmática para abril de 2026:

1. Hoy: Crea tu llms.txt (30 minutos)
2. Esta semana: Implementa Content Negotiation si tu framework lo permite
3. Este mes: Añade Schema Maps si manejas contenido estructurado
4. Este trimestre: Evalúa NLWeb si tienes un caso de uso conversacional claro

Los que construyen primero, ganan primero. Esa es la lección de cada estándar web que ha triunfado en los últimos 30 años.