¿Qué es la negociación de contenido (content negotiation) en HTTP?

La negociación de contenido no tiene nada que ver con negociar un precio, ni con un agente que regatea por ti. Es una pieza de HTTP, el protocolo con el que tu servidor responde a cada visita, y resuelve una pregunta muy concreta: cuando una URL tiene varias versiones, cuál entrega a quién. A una tienda le importa más que hace unos años porque ya no la visitan solo navegadores. Un agente de IA puede pedir la misma ficha de producto en Markdown, un rastreador puede pedirla sin decir en qué idioma la quiere, y entre los dos y tu servidor suele haber una caché que guarda copias. Si la negociación está mal hecha, cada uno puede acabar viendo la versión de otro.

Cómo funciona

El estándar es el RFC 9110, publicado en junio de 2022. Su sección 12 parte de una observación: el servidor suele tener varias maneras de representar la misma información (formatos, idiomas, codificaciones), y quien la pide tiene capacidades y preferencias distintas, así que HTTP ofrece mecanismos para negociar cuál se entrega.⁠^{[1]IETF, RFC Editor (junio de 2022). RFC 9110: HTTP Semantics (sección 12, Content Negotiation)} Define tres patrones:⁠^{[1]IETF, RFC Editor (junio de 2022). RFC 9110: HTTP Semantics (sección 12, Content Negotiation)}

• Negociación proactiva (server-driven): el cliente manda sus preferencias y elige el servidor. Para decidir puede usar las cabeceras de negociación y también rasgos implícitos de la petición, como la dirección de red o partes del campo User-Agent.
• Negociación reactiva (agent-driven): el servidor devuelve una lista de alternativas y elige el cliente, con una segunda petición.
• Negociación del contenido de la petición: el servidor dice en su respuesta qué formatos prefiere recibir en las peticiones siguientes.

La proactiva es la que se ve en la web. Las cabeceras que la llevan son cuatro: Accept (el formato), Accept-Charset (el juego de caracteres), Accept-Encoding (la compresión) y Accept-Language (el idioma). Cada preferencia puede llevar un peso q entre 0 y 1, donde 0 significa «no aceptable» y, si no hay peso, vale 1. Una petición sin una de esas cabeceras significa que el cliente no tiene preferencia en esa dimensión. Y si ninguna versión encaja, el servidor puede responder 406 (Not Acceptable) o ignorar la cabecera y servir la de siempre.⁠^{[1]IETF, RFC Editor (junio de 2022). RFC 9110: HTTP Semantics (sección 12, Content Negotiation)}

El propio estándar no la vende como gratis. Enumera sus inconvenientes: el servidor nunca sabe del todo qué es lo mejor para cada cliente, describir capacidades en cada petición es ineficiente y puede afectar a la privacidad, complica el servidor y limita que las cachés compartidas reutilicen las respuestas.⁠^{[1]IETF, RFC Editor (junio de 2022). RFC 9110: HTTP Semantics (sección 12, Content Negotiation)}

La cabecera Vary

Ese último inconveniente se gestiona con Vary. Es una cabecera de respuesta que enumera qué partes de la petición pudieron influir en la versión elegida, y tiene dos funciones: avisar a las cachés de que no pueden usar esa respuesta para otra petición salvo que las cabeceras listadas coincidan, y avisar al cliente de que hay otras versiones. El RFC pide enviarla en cualquier respuesta que se pueda guardar en caché cuando el contenido se ha adaptado a esas cabeceras, por ejemplo al elegir el idioma por Accept-Language.⁠^{[1]IETF, RFC Editor (junio de 2022). RFC 9110: HTTP Semantics (sección 12, Content Negotiation)} El estándar de caché lo remata: una caché no puede reutilizar sin revalidar una respuesta guardada si las cabeceras que nombra Vary no coinciden con las de la nueva petición.⁠^{[2]IETF, RFC Editor (junio de 2022). RFC 9111: HTTP Caching} Por eso la negociación y la caché y CDN para bots van siempre juntas.

En una tienda

El caso que más se ve en 2026 es el del formato. Cloudflare ofrece una función, Markdown for Agents, que hace exactamente esto: cuando un cliente añade Accept: text/markdown a la petición, pide al origen la versión HTML, la convierte a Markdown y la sirve con Content-Type: text/markdown; charset=utf-8, con Accept incluido en Vary para que las cachés guarden las dos versiones por separado. Está disponible en los planes Pro, Business y Enterprise.⁠^{[3]Cloudflare, documentación. Markdown for Agents} El formato en sí tiene su propia entrada, Markdown para agentes.

Así se vería el intercambio en una tienda ejemplo ficticio. El agente prefiere Markdown (peso 1, por omisión) y acepta HTML como segunda opción (peso 0,8):

GET /productos/moka-inox-6 HTTP/1.1
Host: cafeteras-ejemplo.es
Accept: text/markdown, text/html;q=0.8

HTTP/1.1 200 OK
Content-Type: text/markdown; charset=utf-8
Vary: Accept

La línea que importa es la última. Sin Vary: Accept, una caché compartida que guardó esta respuesta podría dársela al siguiente navegador que pida la misma URL.⁠^{[2]IETF, RFC Editor (junio de 2022). RFC 9111: HTTP Caching}

El otro caso es el idioma, y ahí el riesgo lo pone el rastreador. Google dice que Googlebot hace sus peticiones sin la cabecera Accept-Language y que sus direcciones IP por defecto parecen estar en Estados Unidos, aunque también rastrea desde fuera. Si tu tienda elige el idioma por esa cabecera, Google avisa de que puede no rastrear, indexar ni clasificar todo tu contenido en cada idioma, y recomienda URL separadas por idioma, anotadas con hreflang.⁠^{[4]Google Search Central. How Google crawls locale-adaptive pages} Con la regla de ausencia del RFC, una petición sin Accept-Language no expresa preferencia,⁠^{[1]IETF, RFC Editor (junio de 2022). RFC 9110: HTTP Semantics (sección 12, Content Negotiation)} así que Googlebot verá la versión por defecto y solo esa.

Cómo comprobarlo

1. Pide tu ficha en Markdown con curl -sI -H "Accept: text/markdown" https://tu-dominio/productos/tu-producto y mira Content-Type. Si sigue siendo text/html, tu servidor ignora esa preferencia, que es una respuesta válida según el RFC.⁠^{[1]IETF, RFC Editor (junio de 2022). RFC 9110: HTTP Semantics (sección 12, Content Negotiation)}
2. Mira Vary cada vez que cambie el formato o el idioma. Si la respuesta cambia según Accept o Accept-Language y Vary no nombra esa cabecera, una caché compartida puede servir la versión equivocada.⁠^{[2]IETF, RFC Editor (junio de 2022). RFC 9111: HTTP Caching}
3. Pide la página sin Accept-Language. Es lo que hace Googlebot, y lo que recibas es lo que puede rastrear.⁠^{[4]Google Search Central. How Google crawls locale-adaptive pages}
4. Compara el precio y la disponibilidad en todas las versiones. Si no coinciden, el problema ya no es de formato.

Concepto cercano: user agent

El user agent es el nombre con el que se presenta el cliente, no una preferencia. El RFC admite que la negociación proactiva use partes de ese campo como señal implícita,⁠^{[1]IETF, RFC Editor (junio de 2022). RFC 9110: HTTP Semantics (sección 12, Content Negotiation)} pero son cosas distintas: Accept dice qué quiere el cliente; el user agent dice quién dice ser, y cualquiera puede escribirlo. Elegir la versión por el user agent es adivinar; elegirla por Accept es responder a lo que se pidió. Para comprobar quién llama de verdad hace falta otra cosa, como Web Bot Auth.

Para seguir, la ruta de lectura de rastreo e indexación ordena el resto de piezas que deciden qué ve un bot en tu tienda.