SEO internacional

SEO multidioma y hreflang: cómo decirle a Google qué versión mostrar a cada usuario

Estructura de URLs, códigos de idioma y región, x-default, enlaces de retorno y su relación con la etiqueta canonical. Todo lo que necesitas para que cada mercado vea la página correcta.

SEO internacionalActualizado: 12 min de lecturaPor el equipo de UrbanElevate

Tener la web traducida no significa que Google vaya a mostrar la versión en inglés a un comprador británico ni la versión en alemán a uno de Múnich. Para eso existe hreflang: una anotación sencilla en apariencia que, mal implementada, es una de las fuentes de errores más frecuentes en las auditorías de sitios internacionales.

Qué es hreflang y qué problema resuelve

hreflang es un atributo que indica a los buscadores que una página tiene versiones equivalentes en otros idiomas o para otras regiones, y cuál es la URL de cada una. No es un factor de posicionamiento: no hace que una página posicione mejor. Lo que hace es ayudar a Google a elegir cuál de las versiones equivalentes mostrar en función del idioma y la ubicación de quien busca.

Resuelve dos problemas concretos:

  • La versión equivocada en los resultados. Sin hreflang, un usuario en Alemania puede ver la versión en inglés de tu página porque es la que más enlaces ha acumulado.
  • Contenido casi idéntico entre regiones. Si tienes una página en inglés para Reino Unido y otra para Irlanda que solo cambian en moneda y datos de contacto, hreflang aclara que no son duplicados accidentales, sino variantes pensadas para públicos distintos.

Conviene tener claro su alcance: Google utiliza hreflang; otros buscadores lo tratan de forma distinta. Bing, por ejemplo, ha explicado en su documentación que se apoya más en señales como el atributo lang del HTML o la meta content-language. Por eso una implementación sólida combina hreflang con un lang correcto en cada página. Si quieres repasar los términos básicos, los tienes en nuestro glosario SEO.

Antes de hreflang: elegir la estructura del sitio

hreflang se apoya en una arquitectura de URLs. Antes de escribir una sola etiqueta, decide cómo vas a organizar los idiomas y los países. Las opciones habituales son cuatro:

EstructuraEjemploVentajasInconvenientes
Dominio de país (ccTLD)ejemplo.de, ejemplo.frSeñal geográfica muy clara; confianza localCada dominio construye su autoridad por separado; más coste de gestión
Subdirectorioejemplo.com/de/Comparte la autoridad del dominio; fácil de mantenerLa señal de país es menos evidente sin hreflang
Subdominiode.ejemplo.comPermite alojar o gestionar cada versión por separadoSuele requerir más trabajo para consolidar autoridad
Parámetrosejemplo.com/?lang=deRápido de implementarDesaconsejado: difícil de rastrear, segmentar y medir

Para la mayoría de empresas medianas que trabajan desde España hacia varios mercados europeos, el subdirectorio es la opción más equilibrada: un solo dominio, una sola propiedad de autoridad y la posibilidad de crecer por idiomas sin multiplicar infraestructuras. Los ccTLD tienen sentido cuando hay operaciones locales reales (entidad, logística, atención al cliente) y presupuesto para trabajar cada mercado como un proyecto propio.

Dos reglas que se aplican a cualquier estructura:

  • Una URL por idioma o región. Nunca sirvas idiomas distintos en la misma URL en función de cookies o de la IP: Google rastrea sobre todo desde Estados Unidos y vería solo una versión.
  • Nada de redirecciones automáticas por IP o idioma del navegador. Si quieres sugerir otra versión, usa un banner que el usuario pueda cerrar. Las redirecciones forzadas impiden que el rastreador acceda a todas las versiones.

Si la decisión implica cambiar URLs existentes, trátala como una migración: lee nuestra guía para migrar una web sin perder SEO.

Códigos de idioma y región: el formato correcto

El valor de hreflang se compone de un código de idioma en formato ISO 639-1 y, opcionalmente, un código de región en formato ISO 3166-1 alfa-2, separados por un guion.

  • es: español, para cualquier usuario que hable español.
  • es-ES: español para usuarios en España.
  • es-MX: español para usuarios en México.
  • en-GB: inglés para Reino Unido (no en-UK, que no existe).
  • de-AT: alemán para Austria.

Puntos que generan errores con frecuencia:

  • El idioma es obligatorio; la región, no. Un valor como ES o GB solo, sin idioma, no es válido.
  • No inventes combinaciones. Códigos como en-EU o es-LA no corresponden a países y Google los ignora.
  • Mayúsculas y minúsculas. Los valores no distinguen entre ellas, pero la convención (es-ES) facilita la lectura y la revisión.
  • Solo segmenta por región si hay diferencias reales. Si tu versión en inglés es la misma para todo el mundo, basta con en. Crear en-GB, en-IE y en-US con el mismo texto multiplica el mantenimiento sin aportar nada al usuario.

Tres formas de implementar hreflang

Google admite tres métodos equivalentes. Elige uno por conjunto de páginas: combinarlos no aporta nada y multiplica las posibilidades de contradicción.

1. Etiquetas link en el <head> del HTML

Es el método más común. Cada página incluye una etiqueta por cada versión, incluida ella misma:

<link rel="alternate" hreflang="es" href="https://ejemplo.com/es/servicios/" />
<link rel="alternate" hreflang="en" href="https://ejemplo.com/en/services/" />
<link rel="alternate" hreflang="de" href="https://ejemplo.com/de/leistungen/" />
<link rel="alternate" hreflang="x-default" href="https://ejemplo.com/en/services/" />

Ventaja: es visible y fácil de auditar. Inconveniente: en sitios con muchos idiomas, el bloque crece y añade peso a cada página; y si el CMS genera las etiquetas con JavaScript, dependes de que el renderizado funcione correctamente.

2. Cabeceras HTTP

Para archivos que no son HTML, como los PDF, la anotación se envía en la cabecera Link de la respuesta:

Link: <https://ejemplo.com/es/guia.pdf>; rel="alternate"; hreflang="es",
      <https://ejemplo.com/en/guide.pdf>; rel="alternate"; hreflang="en"

Se configura en el servidor o en la CDN. Es útil para documentos descargables, pero más difícil de revisar a simple vista.

3. Sitemap XML

En sitios grandes es la opción más limpia: las anotaciones se centralizan en el sitemap y no recargan el HTML. Cada <url> lista todas sus alternativas, incluida ella misma:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
  <url>
    <loc>https://ejemplo.com/es/servicios/</loc>
    <xhtml:link rel="alternate" hreflang="es" href="https://ejemplo.com/es/servicios/"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://ejemplo.com/en/services/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://ejemplo.com/en/services/"/>
  </url>
  <url>
    <loc>https://ejemplo.com/en/services/</loc>
    <xhtml:link rel="alternate" hreflang="es" href="https://ejemplo.com/es/servicios/"/>
    <xhtml:link rel="alternate" hreflang="en" href="https://ejemplo.com/en/services/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://ejemplo.com/en/services/"/>
  </url>
</urlset>

El inconveniente es que las anotaciones quedan «fuera» de la página, por lo que hay que asegurarse de que el sitemap se regenera cada vez que se publica, se elimina o se traduce una URL.

MétodoIdeal paraRiesgo principal
HTML headSitios pequeños y medianos, CMS con plugins multidiomaEtiquetas inyectadas por JavaScript o plantillas incompletas
Cabecera HTTPPDF y otros archivos no HTMLConfiguración olvidada tras cambios de servidor o CDN
Sitemap XMLSitios grandes, catálogos, muchos idiomasSitemaps desactualizados respecto al contenido real

x-default, autorreferencia y enlaces de retorno

x-default

x-default indica qué URL mostrar cuando ninguna de las versiones declaradas encaja con el idioma o la región del usuario. Suele apuntar a la versión internacional (a menudo en inglés) o a una página selectora de idioma. No es obligatorio, pero es recomendable: sin él, Google decide por su cuenta qué versión mostrar a un usuario de, por ejemplo, Polonia, si no tienes versión en polaco.

Autorreferencia

Cada página debe incluirse a sí misma en su propio conjunto de anotaciones. La versión española lista la española, la inglesa y el resto; la inglesa, exactamente lo mismo.

Enlaces de retorno (bidireccionalidad)

Es la regla que más se incumple: si la página A apunta a la página B como alternativa, B tiene que apuntar a A. Si la relación no es recíproca, Google puede ignorar las anotaciones. Esto evita que un tercero declare su página como «versión alternativa» de la tuya.

Regla práctica: el conjunto de etiquetas hreflang debe ser idéntico en todas las páginas del grupo. Si lo copias de una versión a otra y algo cambia, hay un error.

hreflang y canonical: cómo conviven

La etiqueta canonical indica cuál es la URL preferida dentro de un grupo de duplicados. hreflang relaciona páginas equivalentes en distintos idiomas. Son compatibles siempre que respetes una regla: cada versión idiomática debe tener una canonical que apunte a sí misma.

El error clásico es canonicalizar todas las versiones a la principal, por ejemplo, que la página en alemán tenga como canonical la versión en inglés. Con eso le estás diciendo a Google que la versión alemana es un duplicado que no debe indexarse, lo que contradice la anotación hreflang. El resultado suele ser que la versión alemana desaparece de los resultados.

Otras situaciones frecuentes:

  • Páginas con parámetros. Si /en/services/?utm_source=x tiene canonical a /en/services/, las anotaciones hreflang deben usar siempre la URL canónica, nunca la variante con parámetros.
  • Paginación y filtros. Solo deben llevar hreflang las URLs indexables. Si una página está en noindex o canonicalizada a otra, no la incluyas en el grupo.
  • Versiones regionales casi idénticas. Si en-GB y en-IE comparten texto, cada una mantiene su propia canonical y hreflang las relaciona. Google puede agruparlas, pero mostrará la URL adecuada a cada mercado.

Traducir no es localizar

hreflang le dice a Google qué página mostrar, pero no hace que esa página merezca posicionar. Los mercados buscan de forma distinta: un comprador británico de vivienda en Marbella no usa las mismas palabras que uno neerlandés, y ninguno de los dos traduce literalmente lo que buscaría un español.

  • Investigación de palabras clave por mercado. No traduzcas tu lista de keywords: investígala en cada idioma, con herramientas configuradas para cada país.
  • Elementos locales. Moneda, formatos de fecha y teléfono, unidades, referencias legales, medios de pago y prueba social del mercado concreto.
  • Metadatos y URLs traducidos. Title, meta description, encabezados, texto alternativo y, cuando sea posible, slugs en el idioma de la página.
  • Revisión nativa. La traducción automática es un buen punto de partida, pero las páginas de negocio necesitan revisión por alguien que hable el idioma como nativo.
  • Enlazado interno coherente. Los enlaces de cada versión deben llevar a páginas del mismo idioma. Un selector de idioma visible en todas las páginas completa el sistema.

Este trabajo de localización es el núcleo de nuestro servicio de SEO internacional y encaja con lo que contamos en empresas internacionales.

Errores habituales que vemos en auditorías

  1. Falta de enlaces de retorno. Una versión nueva se publica con hreflang, pero las antiguas no se actualizan para apuntar a ella.
  2. Códigos inválidos. en-UK, es-LA, regiones sin idioma o guiones bajos en lugar de guiones (es_ES).
  3. URLs que no devuelven 200. Anotaciones que apuntan a redirecciones, páginas 404 o URLs bloqueadas por robots.txt.
  4. Canonical contradictoria. Versiones idiomáticas canonicalizadas a otra versión, o a la home.
  5. Hreflang hacia páginas no equivalentes. Enlazar la ficha de un producto en español con la home en inglés porque el producto no existe en ese idioma. Si no hay equivalente, simplemente no lo declares.
  6. URLs relativas. Los atributos href deben ser URLs absolutas, con protocolo y dominio.
  7. Métodos mezclados y contradictorios. Etiquetas en el HTML que dicen una cosa y el sitemap, otra.
  8. Contenido sin traducir. Páginas con la plantilla traducida pero el cuerpo en el idioma original: Google puede considerar que no son realmente una versión en ese idioma.

Cómo verificar la implementación

Search Console ya no ofrece el antiguo informe de segmentación internacional, así que la verificación se hace con otras herramientas:

  1. Rastreo completo con un crawler como Screaming Frog o Sitebulb, que detectan enlaces de retorno ausentes, códigos no válidos, URLs no indexables y conflictos con la canonical.
  2. Inspección de URL en Search Console para comprobar qué canonical ha elegido Google en cada versión y si coincide con la tuya.
  3. Informe de indexación de páginas para detectar versiones marcadas como «duplicada» o «página alternativa con etiqueta canónica adecuada».
  4. Rendimiento por país en Search Console: filtra por país y revisa qué URLs reciben impresiones. Si en Alemania aparecen URLs en inglés, algo falla.
  5. Revisión tras cada publicación. Incluye hreflang en tu checklist de despliegue; puedes partir de nuestra checklist SEO.

Conclusión

hreflang es una pieza pequeña de un sistema más grande. Funciona bien cuando la estructura de URLs es clara, cada versión tiene su propia canonical, las anotaciones son recíprocas y el contenido está realmente adaptado a cada mercado. Falla cuando se añade a última hora sobre una web traducida a medias. Si estás preparando la expansión a nuevos idiomas o sospechas que Google muestra la versión equivocada en algún país, una auditoría SEO es el punto de partida para detectar el problema antes de invertir en más contenido.

¿Tu web internacional muestra la versión correcta en cada país?

Revisamos tu estructura, tus anotaciones hreflang y tu contenido por mercado, y te entregamos un plan priorizado.