Etiquetas Hreflang Bien Hechas: Guía de Campo para Sitios Multilingües

La Pregunta Que hreflang Realmente Responde

La mayoría de equipos tratan hreflang como un metadato accesorio — una etiqueta que el CMS emite porque alguien añadió el requisito a un ticket de Jira hace tres años. Luego un usuario francés acaba en la página alemana, un hispanohablante en México aterriza en la versión en español-de-España con la divisa equivocada, y la bandeja de soporte se llena de reportes que parecen bugs de producto pero son bugs de SEO. Hreflang existe para responder a una única pregunta concreta: ¿cuál de mis URLs debe enviar Google a un usuario que busca en idioma I desde el país P? Todo lo que viene a continuación regresa a esa pregunta.

El mecanismo importa porque Google no usa hreflang como señal de ranking. Lo usa como señal de enrutamiento. Si la etiqueta está mal, rankea la URL equivocada. Si falta, Google recurre a su propia detección de idioma — que funciona sorprendentemente bien en sitios simples y sorprendentemente mal en cuanto tus locales se solapan o tus URLs no contienen pistas evidentes de idioma. Este artículo es la guía de campo que me hubiera gustado tener la primera vez que envié hreflang en un proyecto multilingüe serio. La herramienta complementaria — el Verificador de Hreflang que se ejecuta solo en el navegador — implementa las reglas de validación descritas a continuación para que puedas auditar tu propia implementación en segundos.

Los Tres Métodos de Entrega (y Por Qué el de Sitemap Escala)

Google acepta declaraciones hreflang en tres lugares, y los tres son equivalentes para el motor de búsqueda. La elección entre ellos es puramente de ingeniería, pero tiene consecuencias reales cuando tu sitio crece.

Etiquetas link en el head HTML. El enfoque más común. Cada página emite un <link rel="alternate" hreflang="..." href="..."> para sí misma y cada hermana. Fácil de implementar porque los metadatos por página se plantillan de forma natural. Difícil de depurar a escala porque necesitas rastrear el sitio para ver qué se emitió realmente, y un bug de plantilla en una URL rompe el cluster entero en silencio.

Cabeceras HTTP Link de respuesta. Mismo contenido, distinto transporte. Útil cuando el cuerpo de la respuesta no es HTML (PDFs, imágenes, JSON) pero quieres declarar alternates. Rara vez se usa en páginas HTML porque las cabeceras son más difíciles de inspeccionar que las etiquetas del head.

Anotaciones xhtml:link en el sitemap XML. El enfoque al que convergen los sitios empresariales grandes. Cada entrada <url> del sitemap declara sus alternates en línea usando elementos <xhtml:link rel="alternate" hreflang="..." href="..."/>. La ventaja: cada declaración internacional vive en un único artefacto regenerable. El CMS lo exporta como parte de la construcción del sitemap, el archivo entra en el control de versiones, y la topología completa del cluster pasa a ser un archivo de texto diff-amistoso en vez de un crawl de mil páginas.

Si tu sitio tiene menos de unos pocos miles de páginas y uno o dos locales, el enfoque del head HTML está bien. Si tienes más locales de los que cuentas con una mano, más de 10.000 páginas o un equipo de contenido que regenera el sitemap desde un export del CMS de todos modos, el enfoque del sitemap se amortiza en un ciclo de release porque el validador puede leer el sitemap directamente y responder "¿la topología del cluster es correcta?" sin un crawl.

Bidireccionalidad del Cluster: La Regla Que Tropieza a Todo el Mundo

La regla es sencilla de enunciar y brutal en la práctica: cada URL en un cluster hreflang debe declarar todas las demás URLs del cluster, incluida ella misma. Si el cluster tiene tres URLs (inglés, español, francés), cada una de las tres debe emitir tres etiquetas <link rel="alternate" hreflang=...> — una auto-referencia y dos hermanas. Si solo una URL olvida solo una etiqueta de retorno, Google puede descartar silenciosamente el cluster entero de su lógica de enrutamiento. El aviso "problema de segmentación internacional" de Search Console es la única señal que recibes, y no te dice qué URL falta a qué etiqueta — solo te dice que el cluster está roto.

El verificador hreflang reporta la etiqueta exacta que falta. No "cluster roto" sino "a la URL /en/pricing/ le falta una etiqueta de retorno apuntando a /fr/tarifs/". Esa precisión importa porque la corrección suele ser un cambio de una línea en una plantilla, y convertir un aviso vago de Search Console en una edición de código precisa es la diferencia entre "lo miramos el próximo sprint" y "lo arreglamos antes de comer".

Las causas más comunes de bidireccionalidad rota: (a) una plantilla CMS que emite "otros idiomas" sin el actual, rompiendo la regla de auto-referencia; (b) un despliegue parcial donde algunos locales recibieron la nueva plantilla y otros no; (c) un fragmento de sitemap editado a mano que se desincronizó del resto; (d) un rollout de región donde el CMS del nuevo locale conoce a los antiguos pero las plantillas de los antiguos no se han actualizado para conocer al nuevo.

Códigos de Locale: ISO 639-1 + ISO 3166-1, No Lo Que Tú Inventes

El valor hreflang es una etiqueta de idioma BCP 47. En la práctica eso significa un código de idioma de dos letras ISO 639-1, seguido opcionalmente de un guion y un código de región de dos letras ISO 3166-1 alpha-2. Ejemplos que pasan: en, es, en-US, es-MX, zh-CN, pt-BR. Ejemplos que fallan y aparecen sistemáticamente en producción: en-USA (la región es de tres letras), en-UK (UK no es un código ISO 3166-1 — Gran Bretaña es GB), en_US (el separador debe ser un guion), english (el idioma debe ser un código de dos letras), br solo (br es el idioma bretón; si querías decir Brasil necesitas pt-BR).

El error más común de esta categoría es en-UK. Suena bien porque UK es la abreviatura cotidiana de Reino Unido, y artículos de SEO en internet a veces lo usan informalmente. Pero el código ISO 3166-1 para el Reino Unido de Gran Bretaña e Irlanda del Norte es GB. en-UK falla la validación y Google lo ignora. La corrección es en-GB. Si encuentras en-UK en tu código, haz una búsqueda en todo el repositorio del literal y reemplaza cada aparición — estará en plantillas, en el CMS y posiblemente en el generador del sitemap.

El verificador hreflang valida cada valor de locale contra estos patrones y reporta INVALID_LOCALE con el string exacto que falla. El valor literal x-default se reconoce como sentinela y se exime de la validación — es el único caso especial de la especificación.

x-default: Casi Siempre Vale la Pena Declararlo

El alternate x-default es el comodín. Le dice a Google: si el locale del usuario no coincide con ninguno de mis alternates explícitos, envíalo aquí. Para la mayoría de sitios internacionales, x-default apunta a la página global — a menudo la versión en inglés (porque el inglés es el fallback de facto para audiencias internacionales) o una página selectora de idioma si la tienes. La especificación es permisiva: x-default puede ser la misma URL que uno de los alternates específicos o una URL completamente separada.

El coste de omitir x-default es que Google tiene que adivinar. La adivinanza está sesgada hacia el locale con más autoridad de enlaces acumulada, lo que a menudo significa que un usuario japonés que intenta leer tu página global termina enviado a tu URL alemana porque la alemana lleva más tiempo activa y ha acumulado más backlinks. Eso casi nunca es lo que quieres. La solución es una declaración extra <link rel="alternate" hreflang="x-default" href="..."/> por cluster, apuntando a la URL que quieras que vean los usuarios con locale no manejado.

El verificador hreflang reporta la falta de x-default como aviso por defecto porque algunos casos de nicho (clusters de un solo locale, clusters reducidos de dos idiomas mutuamente excluyentes) realmente no lo necesitan. Para cualquier caso más amplio, activa Exigir x-default en las opciones de validación para escalar el aviso a error y que el problema no se envíe en silencio.

Auto-Referencia: El Bug Que Todo CMS Ha Enviado Alguna Vez

La regla de auto-referencia dice: el bloque hreflang de la URL A debe incluir a A misma como uno de los alternates. La plantilla CMS natural emite "todos los OTROS idiomas en los que esta página está disponible" — y el error natural es escribir esa plantilla literalmente, excluyendo el idioma actual. El resultado es un cluster donde cada URL declara cada hermana pero ninguna se declara a sí misma, y el cluster entero es inválido.

Si solo arreglas un bug de hreflang en tu código a raíz de este artículo, arregla este. Es el error más barato de cometer y el más barato de corregir. El verificador hreflang lo reporta como MISSING_SELF_REFERENCE con la URL exacta que omite su propio enlace de vuelta.

Locales Duplicados: Dos URLs Reclamando la Misma Audiencia

Menos común pero más confuso en la práctica. El bloque hreflang de una URL declara dos alternates con el mismo valor de locale apuntando a URLs distintas. Ejemplo: una página declara tanto hreflang="en-US" href="/en/" como hreflang="en-US" href="/en-us/". Google no tiene cómo decidir cuál es correcto, y la entrada normalmente se descarta.

La causa raíz suele ser una migración de CMS donde dos convenciones de URL coexisten temporalmente y la plantilla emite ambas. La corrección es canonicalizar sobre un único patrón de URL y eliminar el duplicado de la lista de alternates. El verificador hreflang lo reporta como DUPLICATE_LOCALE con ambas URLs de destino.

Un Flujo de Auditoría Que Realmente Detecta Errores

El flujo que ejecuto para cualquier sitio multilingüe no trivial:

1. Exporta el sitemap de producción y aliméntalo al verificador. Si hreflang vive en anotaciones xhtml:link dentro del sitemap, este único paso audita la topología del sitio en una sola pasada. El verificador te dirá exactamente qué URLs no tienen etiquetas de retorno, cuáles tienen locales inválidos y qué clusters no tienen x-default.
2. Para sitios con head HTML, muestrea una URL por cluster y pega el head en el modo HTML. Revisa primero los clusters de mayor tráfico. Un bug en la plantilla del head suele afectar a cada página que usa esa plantilla, así que un único cluster malo es señal de que la plantilla entera está rota.
3. Tría los hallazgos por severidad. Los errores bloquean el SEO internacional. Los avisos lo degradan. Arregla cada error antes del próximo despliegue; agenda los avisos en el backlog de SEO.
4. Exporta los hallazgos como CSV. Súbelo a un gestor de incidencias y asigna responsabilidad por plantilla. La columna code te deja agrupar por tipo de error, lo que a menudo revela que todos los errores vienen de una única plantilla rota.
5. Reejecuta la comprobación tras la corrección. La auditoría completa tarda menos de un minuto sobre un sitemap, así que la verificación es barata. Hazla parte del smoke test post-despliegue.
6. Conecta la comprobación a CI a largo plazo. La misma lógica de validación está expuesta por el paquete open-source @anthropic-tools/tools-core. Llamar a validateHreflangEntries en un script de CI y romper el build ante cualquier error convierte la corrección de hreflang en una propiedad regresivamente verificada del código en vez de una auditoría trimestral.

Lo Que hreflang No Puede Hacer

Un cluster hreflang limpio es necesario pero no suficiente para el SEO internacional. Garantiza que Google enruta a los usuarios a la URL pretendida; no hace nada respecto a si esa URL es la mejor experiencia de aterrizaje para esos usuarios. Los modos de fallo más comunes que parecen problemas de hreflang pero no lo son:

• Contenido traducido automáticamente. Una página traducida automáticamente al español es técnicamente una página en español, pero la calidad de la traducción suele ser visible para los usuarios y casi siempre peor que la copia específica de mercado. Los sistemas de calidad de Google detectan contenido auto-traducido y lo degradan independientemente de hreflang.
• Segmentación por país sin ccTLDs ni ajustes de país en Search Console. Hreflang informa a Google sobre el ajuste idioma-país; por sí solo no establece que tu sitio esté pensado para, digamos, el mercado mexicano. Combina hreflang con una propiedad de Search Console segmentada por país para ccTLDs o con el ajuste de segmentación internacional del Search Console legado para gTLDs.
• Supuestos de divisa y precio. Un usuario enviado a la URL española sigue viendo precios en euros si eso es lo que la página emite. Hreflang enruta al usuario; la página debe localizar la experiencia.
• Conflictos de canonicalización. Si dos alternates de un cluster tienen etiquetas canonical apuntando entre sí o a una tercera URL, Google puede colapsar el cluster y tratar una URL como la canónica para todos los locales. Ejecuta una auditoría de canonical aparte de la auditoría de hreflang y resuelve los conflictos antes de que provoquen degradaciones silenciosas.

Conclusión

Hreflang es un sistema de cinco reglas: clusters bidireccionales, auto-referencias incluidas, códigos ISO válidos, sin locales duplicados y x-default declarado. El verificador hreflang aplica las cinco en segundos sobre un sitemap o cabecera HTML. El coste de ejecutarlo es prácticamente cero; el coste de saltárselo es tráfico mal enrutado y avisos en Search Console que tardan días en diagnosticarse sin reportes precisos. Conéctalo a tu checklist pre-despliegue, corrige los errores que aparezcan y los cimientos de SEO internacional bajo tu contenido dejan de ser un lastre.

Pega un sitemap o el head HTML de una página en el Verificador de Hreflang y mira lo que tu implementación actual dice realmente. Si dice "0 errores", has hecho la parte difícil. Si no, el informe te dice exactamente qué líneas cambiar.