¿Qué es la cabecera HTTP Link con rel=alternate?

La cabecera Link no es un enlace que se vea en la página ni el elemento <link> del <head>, aunque dice lo mismo que él: es una línea entre las cabeceras de la respuesta, invisible en el navegador si no abres sus herramientas de desarrollo. A una tienda le sirve en tres casos. Cuando tiene archivos que no son HTML, como la ficha técnica en PDF, y no puede ponerles un <head>. Cuando publica versiones en varios idiomas. Y cuando quiere ofrecer a los agentes de IA una versión en Markdown de cada página sin tocar las plantillas del tema. Es la forma de declarar relaciones entre URL desde el servidor o la CDN, no desde el HTML.

Cómo funciona

La cabecera Link la define el RFC 8288, Web Linking, que M. Nottingham publicó en octubre de 2017 y que sustituyó al RFC 5988. El estándar describe un enlace con cuatro piezas: el contexto (la URL que responde), el tipo de relación, el destino y, si hacen falta, unos atributos del destino. En la cabecera se escribe la URL de destino entre ángulos, después rel con el tipo de relación y, separados por punto y coma, los atributos. Caben varios enlaces en una sola cabecera, separados por comas, o en varias cabeceras Link seguidas.⁠^{[1]IETF (M. Nottingham). RFC 8288: Web Linking}

Los atributos que el estándar define para el destino son hreflang, una pista del idioma; type, una pista del tipo de archivo; media; title; y anchor, que cambia el contexto del enlace. Sobre este último, el RFC avisa de que una cabecera con anchor es una afirmación de terceros y no es de fiar sin comprobarla.⁠^{[1]IETF (M. Nottingham). RFC 8288: Web Linking}

alternate es uno de los tipos de relación registrados en la IANA, con una descripción de una línea: se refiere a un sustituto de este contexto. Para el detalle, el registro remite al estándar de HTML.⁠^{[2]IANA. Link Relations} Y ahí el significado depende de lo que acompañe a la relación:⁠^{[3]WHATWG. HTML Standard: Link type "alternate"}

• Con hreflang en un idioma distinto del de la página, el destino es una traducción.
• Con type, el destino es una reformulación de la misma página en otro formato. Con los tipos de RSS o Atom, es un canal de sindicación.
• Los dos atributos se pueden combinar, para una versión en otro idioma y otro formato a la vez.

Lo que alternate no dice es cuál de las versiones manda. Para eso existe otra relación, canonical, que la IANA describe como la que designa la versión preferida de un recurso.⁠^{[2]IANA. Link Relations}

Tres usos en una tienda

Idiomas, con hreflang. Google admite tres maneras de indicarle las versiones localizadas de una página: elementos en el HTML, el sitemap y cabeceras HTTP, y dice que para él las tres son equivalentes. La cabecera es la que sirve para archivos que no son HTML, como los PDF. Las reglas son las mismas en los tres métodos: cada versión se lista a sí misma y a todas las demás, las URL van completas, con su https://, y si dos páginas no se apuntan la una a la otra, Google ignora las indicaciones. Para quien no encaje en ningún idioma está el valor x-default.⁠^{[4]Google Search Central. Tell Google about localized versions of your page}

Formatos, con type. La propuesta de llms.txt, en su versión del 10 de agosto de 2026, pide que las páginas útiles para los agentes tengan una versión limpia en Markdown en la misma URL con .md añadido, y recomienda anunciarla con relaciones estándar: rel="alternate" type="text/markdown" hacia la versión en Markdown y rel="describedby" hacia el llms.txt que la cubre. Lo propone en el HTML o en la cabecera, y señala la ventaja de la segunda: se configura en el servidor o en la CDN sin modificar ninguna página.⁠^{[5]llmstxt.org (Jeremy Howard). The /llms.txt file} Es una de las formas de servir Markdown para agentes. Google, por su parte, dice que no hace falta crear archivos legibles por máquinas, archivos de texto para IA, marcado ni Markdown para aparecer en su Búsqueda.⁠^{[6]Google Search Central. Optimizing your website for generative AI features on Google Search} La versión en Markdown es una oferta para los agentes que quieran pedirla, no un requisito de Google.

La canonical de lo que no es HTML. La misma cabecera lleva otras relaciones. Google acepta rel="canonical" en la respuesta para los archivos que no son HTML, por ejemplo para indicar que la versión en PDF de un documento es la canónica frente a su .docx, y solo para los resultados de búsqueda web. Recomienda elegir un método y no mezclarlo con la etiqueta del HTML, porque es fácil acabar declarando una URL en la cabecera y otra en el <link>.⁠^{[7]Google Search Central. How to specify a canonical URL with rel="canonical" and other methods}

En una tienda

Un ejemplo ficticio: una tienda de fotografía publica la ficha técnica de un trípode en PDF, en español y en inglés. Así responde el PDF en español:

HTTP/2 200
content-type: application/pdf
link: <https://tienda.example/docs/t20-ficha-es.pdf>; rel="alternate"; hreflang="es", <https://tienda.example/docs/t20-ficha-en.pdf>; rel="alternate"; hreflang="en"

La cabecera se lista a sí misma y a la versión inglesa, con las URL completas, y el PDF en inglés tiene que responder con los mismos dos enlaces. Si uno de los dos no devuelve el par, Google ignora los dos.⁠^{[4]Google Search Central. Tell Google about localized versions of your page}

La ficha del mismo trípode, en HTML, anuncia su versión en Markdown y el llms.txt del sitio:

HTTP/2 200
content-type: text/html; charset=utf-8
link: </products/tripode-viaje-t20.md>; rel="alternate"; type="text/markdown", </llms.txt>; rel="describedby"

Es la misma forma que el ejemplo de la propuesta de llms.txt, con rutas relativas al dominio.⁠^{[5]llmstxt.org (Jeremy Howard). The /llms.txt file} El requisito de URL completas es de Google para hreflang;⁠^{[4]Google Search Central. Tell Google about localized versions of your page} para quien lea esta segunda cabecera, la ruta se resuelve contra la URL que respondió. Ninguna de las dos líneas se ve en la página: quien compra no nota nada, y quien lee las cabeceras sabe que hay otra versión y dónde está.

Cómo comprobarlo

1. Pide la URL con curl -I y busca las líneas que empiezan por link:. Puede haber varias, o varios enlaces separados por comas en una sola.⁠^{[1]IETF (M. Nottingham). RFC 8288: Web Linking}
2. Mira la misma respuesta en el navegador: en las herramientas de desarrollo, pestaña Red, elige el documento y abre sus cabeceras de respuesta.
3. Abre cada URL que anuncia la cabecera. Tienen que responder con un 200, y en el caso de hreflang, cada versión tiene que devolver el mismo grupo de enlaces, con URL completas y con ella misma incluida.⁠^{[4]Google Search Central. Tell Google about localized versions of your page}
4. Comprueba que Google recibe la cabecera. En la inspección de URLs de Search Console, «Probar URL publicada» y después «Ver página probada» muestran las cabeceras HTTP de la respuesta.⁠^{[8]Ayuda de Search Console. Herramienta de inspección de URLs}
5. Si declaras la canonical en cabecera, que no choque con la del HTML. Mejor un solo método que dos con URL distintas.⁠^{[7]Google Search Central. How to specify a canonical URL with rel="canonical" and other methods}

Concepto cercano: negociación de contenido

La negociación de contenido resuelve lo mismo desde el otro lado. Con alternate, cada versión tiene su propia URL y el servidor la anuncia; con la negociación, la URL es una sola y es el cliente quien pide el formato en la cabecera Accept de su petición. Cloudflare lo aplica en su función Markdown for Agents: cuando un agente pide una página con Accept: text/markdown, convierte el HTML en Markdown en el borde, responde con Content-Type: text/markdown y añade Accept a la cabecera Vary, para que las cachés guarden las dos versiones por separado.⁠^{[9]Cloudflare Docs. Markdown for Agents} Las dos cosas se pueden combinar: una versión .md con su URL, anunciada con alternate, y la URL de siempre sirviendo Markdown a quien lo pida.

Para seguir, la comparativa de los archivos que se ofrecen a buscadores y agentes pone a cada uno en su sitio, y la ruta de lectura de este tema ordena el resto de términos.