Etiquetas hreflang: La guía completa de implementación de 2026 de ConveyThis

Resume este post con: 11 min de lectura

ChatGPT Perplejidad Grok Inteligencia artificial de Google

Las implementaciones de hreflang tienden a fallar de una pequeña cantidad de maneras repetibles: códigos no válidos, enlaces de retorno faltantes, objetivos redirigidos, conflictos canónicos y grupos de lenguaje incompletos. Esta guía explica cómo evitar esos fallos y validar el resultado.

Si Google muestra la URL del idioma incorrecto en los resultados de búsqueda o sus páginas traducidas son difíciles de descubrir, esta guía es para usted. Google documenta los enfoques admitidos en su guía de versiones localizadas.

hreflang es uno de esos temas técnicos de SEO que se explica una y otra vez pero nunca llega a funcionar, porque la mayoría de las explicaciones omiten las partes que realmente interrumpen la producción. El ejemplo de cuatro líneas funciona bien hasta que tienes 23 idiomas, variantes regionales, formatos de página alternativos y un flujo de pago que se encuentra en un subdominio. Entonces, pequeñas inconsistencias pueden dejar partes del grupo lingüístico sin reconocer.

Esta guía cubre la implementación que funciona en el mundo real. No la versión del libro de texto. La versión donde Cloudflare almacena en caché sus encabezados, Next.js genera páginas bajo demanda y su CMS agrega barras diagonales que no existen en su mapa del sitio.

Lo que hreflang realmente hace (y no hace)

hreflang indica a los motores de búsqueda qué versión de una página mostrar a los usuarios en diferentes idiomas o regiones. Es una señal de relación, no una señal de clasificación.

Esta distinción importa. Agregar hreflang no hace que su página en francés tenga una mejor clasificación en Francia. Le dice a Google: “esta página en inglés y esta página en francés son traducciones equivalentes del mismo contenido. Cuando alguien busque en francés desde Francia, muéstrele el francés.” Sin él, Google aún podría clasificar su página en francés, pero también podría servir su página en inglés a los buscadores franceses — o peor aún, tratar ambos como contenido duplicado y elegir uno para degradar.

Tres cosas que hace hreflang:

• Enruta la versión de idioma correcta al usuario correcto.
• Ayuda a Google a comprender que páginas traducidas similares están destinadas a diferentes públicos.
• Conecta idiomas equivalentes o variantes regionales como un clúster.

Tres cosas que hreflang no hace:

• Traduce tu contenido (obvio, pero vale la pena decirlo).
• Mejorar las clasificaciones dentro de un mercado único.
• Corrija la mala calidad de la traducción o el contenido escaso.

La sintaxis básica (y por qué la mayoría de los ejemplos están incompletos)

Aquí está la versión que te muestran la mayoría de las guías. Es correcto y también le falta la línea más importante:

<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />

Este fragmento declara versiones en tres idiomas. Funcionará parcialmente. El problema: cada página que utiliza estas etiquetas debe hacer referencia a sí misma en la lista. De lo contrario, Google trata las referencias como unidireccionales y puede descartarlas.

La versión completa en la página en inglés se ve así:

<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Dos cosas cambiaron:

• Hreflang autorreferencial. La página en inglés ahora se declara como la versión en inglés. Sin él, el conjunto queda incompleto y no puede interpretarse como se pretende.
• x-predeterminado. Esto declara la página alternativa para los usuarios cuyo idioma no coincide con ninguna versión especificada. Si un usuario coreano llega a su sitio y usted no tiene coreano, x-default le indica a Google qué página servir.

Ahora bien, aquí está la parte que casi nunca se explica correctamente: la misma lógica se aplica a la página francesa y a la página alemana. Cada página debe enumerar todas las versiones de idioma, incluido él mismo y x-default. No sólo la fuente en inglés.

En la página francesa:

<link rel="alternate" hreflang="en" href="https://example.com/" />
<link rel="alternate" hreflang="fr" href="https://example.com/fr/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Idéntico a la página en inglés. Ese es el punto. Las declaraciones hreflang deben ser recíprocas — cada versión de idioma debe hacer referencia a todas las demás versiones de idioma. Si la página A apunta a la página B, la página B debe apuntar nuevamente a la página A. Google las llama “etiquetas de retorno” y son la regla de validación más fallida en el SEO internacional.

Códigos de idioma: la hoja de trucos

Los códigos hreflang siguen el formato language o language-REGION. Los idiomas utilizan la norma ISO 639-1 (dos letras, minúsculas). Las regiones utilizan la norma ISO 3166-1 Alpha 2 (dos letras, mayúsculas). Las confusiones más comunes:

El Reino Unido no es un código de país. Este es el error más frecuente que he visto en 10 años de auditorías. El código ISO 3166-1 para el Reino Unido es GB. Uso en-GB, no en-UK. Google ignora códigos no válidos de forma silenciosa — tu etiqueta existe, pero no hace nada.

Tres métodos de implementación

hreflang se puede declarar en tres lugares. Cada uno tiene sus ventajas y desventajas.

Método 1: HTML <head> etiquetas (más comunes)

Etiquetas colocadas en el <head> sección de cada página. Fácil de depurar, fácil de inspeccionar, compatible con todos los CMS. La desventaja: cada página debe incluir la etiqueta de todos los demás idiomas, lo que significa que un sitio de 50 páginas en 10 idiomas requiere que se generen y mantengan sincronizadas 500 declaraciones hreflang.

Utilice este método si su sitio tiene menos de ~10 000 páginas o su CMS maneja la generación de hreflang automáticamente.

Método 2: encabezados HTTP (para archivos que no son HTML)

hreflang se puede enviar como un encabezado de enlace HTTP. Esta es la única forma de declarar hreflang para recursos que no son HTML como archivos PDF:

Link: <https://example.com/en/file.pdf>; rel="alternate"; hreflang="en",
      <https://example.com/fr/file.pdf>; rel="alternate"; hreflang="fr"

Utilice encabezados HTTP cuando tenga activos descargables que existan en varios idiomas — manuales de productos, documentos reglamentarios, libros blancos.

Método 3: Mapa del sitio XML (para sitios grandes)

Para sitios con cientos de miles de páginas, declarando hreflang en <head> las etiquetas se vuelven difíciles de manejar. Hreflang basado en mapas de sitio es más eficiente y mantiene su HTML ágil:

<url>
  <loc>https://example.com/</loc>
  <xhtml:link rel="alternate" hreflang="en"
              href="https://example.com/" />
  <xhtml:link rel="alternate" hreflang="fr"
              href="https://example.com/fr/" />
  <xhtml:link rel="alternate" hreflang="x-default"
              href="https://example.com/" />
</url>

Se aplican las mismas reglas de reciprocidad. Cada entrada de URL en el mapa del sitio debe enumerar todas las versiones de idioma, incluida ella misma.

Google trata los tres métodos de implementación como equivalentes y dice que no hay ningún beneficio de búsqueda en usarlos todos. Elija el método que sea más fácil de generar y mantener consistente; si utiliza intencionalmente más de uno, asegúrese de que las declaraciones coincidan.

Cinco errores comunes de implementación

1. Falta hreflang autorreferencial

La página en inglés enumera las versiones en francés y alemán, pero no hace referencia a sí misma como la versión en inglés. Google ignora todo el clúster hreflang. Solución: cada página debe incluir una etiqueta hreflang que apunte a sí misma.

2. Etiquetas de retorno no recíprocas

La página en inglés apunta a la página en francés. La página en francés no apunta hacia atrás. Google considera que esto está roto y puede descartar la relación. Solución: cada referencia debe ser mutua. La página en francés debe incluir la página en inglés como su alternativa en inglés.

3. Apuntando hreflang a las URL redirigidas

Su página en inglés declara la versión en francés en https://example.com/fr/ pero esa URL 301 redirecciona a https://example.com/fr/home/. Google sigue la redirección, pero la señal hreflang se debilita — y en algunos casos se ignora por completo.

Solución: hreflang debe apuntar a la URL canónica final, no a una cadena de redireccionamiento. Auditoría con un rastreador que marca objetivos que no sean de 200 hreflang.

4. hreflang y conflictos canónicos

Su página en francés tiene un canónico que apunta a la página en inglés (porque alguien copió y pegó la etiqueta canónica). Google lee esto como “la página en francés es solo un duplicado de la página en inglés” y la relación hreflang se ignora. Solución: cada página traducida debe autocanonicalizarse. El canónico de la página francesa apunta a sí misma, no al original inglés.

5. Mezclar códigos de idioma y región de manera inconsistente

Algunas páginas declaran hreflang="en", otros declaran hreflang="en-US". Google los trata como grupos de idiomas separados. Elija una estrategia por idioma y manténgala en todo el sitio.

Casos extremos de producción para planificar

Caso extremo 1: Orientación solo por región (en-CA sin en)

Tienes una variante inglés-canadiense de tu página pero no una versión global en inglés. No usar hreflang="en" solo — Google puede servir su página canadiense a usuarios del Reino Unido, lo que probablemente no sea lo que desea. En lugar de eso, declara hreflang="en-CA" específicamente y dejar x-default manejar hablantes de inglés no canadienses.

Caso extremo 2: Mismo contenido, diferentes regiones

Versiones en inglés de EE. UU., Reino Unido y Australia de la misma página de producto con texto idéntico. Esto está bien — declara cada región explícitamente:

<link rel="alternate" hreflang="en-US" href="https://example.com/" />
<link rel="alternate" hreflang="en-GB" href="https://example.com/uk/" />
<link rel="alternate" hreflang="en-AU" href="https://example.com/au/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Incluso cuando el contenido es idéntico, las variantes regionales de hreflang son valiosas para productos con precios, moneda o envío específicos de la región.

Edge case 3: Variantes móviles y de escritorio

Si tiene páginas móviles con subdominios m separados, cada página móvil necesita sus propias declaraciones hreflang que apunten a otras variantes de idiomas móviles. No apunte una página móvil en francés a una página de escritorio en inglés — Google considera que este es un clúster roto.

Caso extremo 4: subdominios versus subdirectorios

Ambos funcionan para hreflang. fr.example.com y example.com/fr/ son igualmente válidos. La elección es operativa (DNS, hosting, analítica) — no un factor SEO en sí mismo. Lo que importa es la coherencia: elija una estructura y aplíquela en todos los idiomas.

Caso extremo 5: Paginación

La página 2 del índice de su blog en francés debe declarar hreflang en la página 2 del índice de su blog en inglés, no en la página 1. Asigne páginas equivalentes a páginas equivalentes, incluida la paginación, los parámetros de consulta y los filtros.

Caso Edge 6: 404 y 410 páginas

Si no existe (todavía) una versión traducida de una página, no declare hreflang para ese idioma. Señalar hreflang a un 404 es peor que no declararlo en absoluto — Google lo ve como una relación rota y puede degradar todo el clúster.

Cómo validar antes de salir en vivo

Utilice comprobaciones complementarias porque ningún informe demuestra que cada par de URL sea correcto:

• Consola de búsqueda de Google. Envíe los mapas de sitios de idiomas, inspeccione las URL representativas con Inspección de URL y compare la indexación de páginas y los datos de rendimiento por directorio de idiomas. El antiguo informe de segmentación internacional ya no está disponible en la interfaz actual de Search Console.
• Rana chillona. Rastrea todo tu sitio e informa hreflang no recíproco, etiquetas de retorno faltantes, URL hreflang rotas e inconsistencias. La mejor herramienta para el control de calidad previo al lanzamiento.
• Herramienta de prueba de etiquetas hreflang de Merkle. Gratuito, basado en navegador, ideal para realizar comprobaciones puntuales durante el desarrollo.

Ejecute la validación del rastreador y las verificaciones de URL representativas antes de un lanzamiento importante, luego supervise Search Console después de que Google vuelva a rastrear las páginas.

Cómo las herramientas automatizadas manejan hreflang

Si está utilizando una plataforma de traducción de sitios web como ConveyThis, Weglot o similar, la generación de hreflang debería ser automática. La plataforma rastrea su contenido, detecta nuevas páginas e inserta las etiquetas hreflang correctas en cada versión traducida —, incluidas etiquetas autorreferenciales, etiquetas de retorno y x-default.

Este es el argumento más sólido para utilizar una plataforma de traducción en lugar de un proceso de traducción manual. Mantener hreflang manualmente en un sitio de 200 páginas en 12 idiomas significa rastrear 31.200 relaciones de etiquetas. Cada nueva página agrega 12 nuevas relaciones que deben agregarse en 12 lugares. El mantenimiento manual se rompe a escala.

Si está utilizando una plataforma y aún ve errores de hreflang en Search Console, la causa suele ser una de tres cosas: una capa de almacenamiento en caché de CDN que elimina encabezados, un complemento de CMS que sobrescribe etiquetas o una regla de redirección que interfiere con la estructura canónica. Los tres se pueden arreglar, pero requieren coordinación entre su plataforma de traducción, su configuración de alojamiento y su CDN.

El resultado final

hreflang no es complicado. Es verboso. La complejidad proviene del volumen de declaraciones y de la fragilidad de cualquier etiqueta faltante. Obtenga los fundamentos correctos — autorreferencial, recíproco, alineado canónicamente, presente x-default — y el resto es solo mantenimiento.

Correct hreflang elimina la ambigüedad sobre qué URL equivalente está destinada a un idioma o región determinados. Primero corrija los conceptos básicos, luego monitoree las impresiones, los clics y las URL canónicas seleccionadas a medida que Google vuelve a rastrear el clúster.

Sobre el autor

Alex Buran, Fundador de ConveyThis

Alex ha pasado la última década construyendo infraestructura para sitios web multilingües. Escribe sobre localización, búsqueda con IA y el aspecto técnico de la globalización.

LinkedIn: https://www.linkedin.com/in/alexburan/

¿Estás cansado de depurar hreflang manualmente? ConveyThis genera automáticamente etiquetas hreflang válidas, recíprocas y autorreferenciales en cada página traducida —, incluidos los casos x-default y edge. Consulte la documentación de la API