El atributo hreflang es uno de esos elementos técnicos que generan más confusión entre los profesionales de SEO internacional. No por ser especialmente complejo en teoría, sino porque cualquier error en su implementación puede hacer que Google ignore por completo las señales de idioma y región que has configurado, con el consiguiente daño en visibilidad orgánica.
Qué es hreflang y para qué sirve exactamente
Hreflang es un atributo HTML que le indica a Google (y a Yandex) que una página tiene versiones equivalentes en otros idiomas o para otras regiones. Se introdujo en 2011 y sigue siendo el mecanismo estándar para gestionar sitios multilingües y multinacionales.
El objetivo es directo: que un usuario que busca desde Alemania vea la versión en alemán, y que uno que busca desde México vea la versión en español de México, no la de España. Sin esta configuración, Google elige por su cuenta qué versión mostrar, y no siempre acierta. El resultado más común es que una URL en inglés aparezca para usuarios hispanohablantes, o que todas las versiones compitan entre sí en los resultados.
Conviene distinguir entre dos casos de uso:
- Mismo idioma, distintas regiones: inglés para Estados Unidos (en-us) e inglés para Reino Unido (en-gb).
- Distintos idiomas: español para España (es-es), francés para Francia (fr-fr), alemán para Alemania (de-de).
En el segundo caso, si el contenido es suficientemente diferente por idioma, Google puede inferir la variante sin hreflang. Pero en el primero, cuando las páginas son casi idénticas salvo pequeñas diferencias de vocabulario o precio, el atributo resulta necesario.
Cómo se implementa hreflang: las tres opciones
Hay tres formas de añadir las anotaciones y las tres son válidas, aunque no todas encajan igual en cada proyecto.
En el head HTML
La más habitual. Se añade una etiqueta link en el <head> de cada página con el atributo rel="alternate", hreflang y href. Cada página debe incluir todas las variantes, incluida ella misma.
Un ejemplo para un sitio con versión española, inglesa y una versión genérica:
<link rel="alternate" hreflang="es" href="https://ejemplo.com/es/" /><link rel="alternate" hreflang="en" href="https://ejemplo.com/en/" /><link rel="alternate" hreflang="x-default" href="https://ejemplo.com/" />
Este método funciona bien en sitios con pocas variantes, pero se vuelve tedioso cuando hay diez o más idiomas. Cada página acaba con un bloque de etiquetas considerable.
En el sitemap XML
Para sitios grandes, implementar hreflang en el sitemap es mucho más manejable. Se usa la extensión de sitemaps de Google y cada URL lleva su grupo de anotaciones dentro del elemento <url>. La ventaja: Google rastrea el sitemap con frecuencia, así que los cambios se propagan antes que esperando que recorra todas las páginas.
Si ya gestionas bien tus sitemaps XML para la indexación, añadir las anotaciones de hreflang en ese mismo archivo es la extensión natural del trabajo ya hecho.
En la cabecera HTTP
Solo aplica a recursos no HTML, como archivos PDF. Para páginas web convencionales no tiene sentido usar este método, así que en la práctica no se usa casi nunca.
Los errores más frecuentes y cómo evitarlos
La mayoría de los problemas con hreflang provienen de los mismos errores de siempre. Conocerlos de antemano ahorra horas de depuración.
La referencia no es recíproca
Este es el error más extendido. Si la página en español apunta a la versión en inglés, la versión en inglés también debe apuntar de vuelta a la española. Google requiere que las anotaciones sean simétricas: si A señala a B, B debe señalar a A. Si falta alguna dirección, Google puede ignorar toda la cadena.
Usar URLs que no son canónicas
Las URLs en hreflang deben ser exactamente las mismas que las declaradas como canónicas. Si una página tiene ?utm_source=newsletter en la URL o usa una variante con y sin barra final de forma inconsistente, las señales se contradicen y Google las descarta.
El atributo x-default mal entendido
x-default no es obligatorio, pero sí recomendable. Indica qué versión mostrar cuando ninguna otra coincide con el idioma o la región del usuario. Muchos lo asignan a la homepage genérica, pero también puede apuntar a una página de selección de idioma. Lo que no tiene sentido es aplicarlo a una versión específica de país, porque pierde su función.
Incluir páginas con errores 4xx o redireccionadas
Apuntar a una URL que devuelve 404 o que hace una redirección 301 invalida la anotación. Google no sigue redirecciones dentro de hreflang. Las URLs tienen que devolver 200 y ser estables.
Mezclar códigos de idioma incorrectos
Los códigos de idioma siguen el estándar ISO 639-1 (dos letras minúsculas: es, en, fr) y los de región el ISO 3166-1 Alpha-2 (dos letras mayúsculas: ES, MX, US). Escribir es-MX es correcto; esp-mx o spanish no lo son y Google los ignora.
La estructura de dominio importa antes que hreflang
Antes de ponerse a escribir etiquetas, la decisión sobre la estructura de URLs condiciona todo lo demás. Hay tres opciones principales y cada una tiene implicaciones distintas:
- Dominios de país (ccTLD): ejemplo.es, ejemplo.de, ejemplo.fr. La señal geográfica más fuerte para Google, pero el coste de gestión es alto y la autoridad de dominio se fragmenta.
- Subdominios: es.ejemplo.com, de.ejemplo.com. Más fácil de gestionar que los ccTLD, aunque Google los trata como sitios independientes en la práctica.
- Subdirectorios: ejemplo.com/es/, ejemplo.com/de/. La opción que concentra toda la autoridad en un solo dominio y la más recomendable para la mayoría de proyectos que empiezan su expansión internacional.
La elección no es reversible sin un proceso de migración costoso, así que conviene decidirla bien desde el principio. En proyectos nuevos, los subdirectorios suelen ganar por su simplicidad técnica y por acumular la autoridad en un único dominio raíz.
Cómo verificar que hreflang funciona
Después de la implementación, hay que comprobar que todo está en orden. Google Search Console muestra errores de hreflang en el informe de internacionalización, aunque tarda algunos días en procesarlos. Las alertas más comunes que aparecen allí son precisamente las referencias no recíprocas y las URLs con errores.
Para una verificación más inmediata, herramientas como Screaming Frog permiten rastrear el sitio y exportar todas las anotaciones hreflang para detectar inconsistencias antes de que Google las procese. Se puede cruzar la lista de URLs de origen con las de destino y verificar manualmente que cada par es recíproco.
Otra comprobación útil: hacer búsquedas desde distintos países usando una VPN y ver qué versión aparece en los resultados. No es infalible porque los resultados también dependen de la personalización, pero da una idea rápida de si las señales están llegando.
Si estás midiendo el rendimiento de tus acciones de SEO con un dashboard bien configurado en Looker Studio, tiene sentido crear un segmento por país para ver si el tráfico orgánico de cada mercado evoluciona según lo esperado después de implementar hreflang.
Hreflang y canibalización de contenido
Uno de los beneficios menos mencionados de hreflang es que ayuda a resolver ciertos problemas de canibalización entre páginas similares. Cuando dos versiones de un mismo contenido compiten en el mismo mercado, hreflang le dice a Google que son equivalentes para audiencias distintas, no competidoras. Esto no sustituye a una etiqueta canónica, pero complementa la señal.
El uso conjunto de rel="canonical" y hreflang es perfectamente válido y de hecho recomendable. Cada versión debe tener su propio canónico apuntando a sí misma, no a la versión en otro idioma. Un error típico: poner como canónica la versión en inglés desde todas las demás versiones, lo que básicamente le dice a Google que las otras no son las páginas relevantes.
Señales complementarias que refuerzan hreflang
Hreflang funciona mejor cuando va acompañado de otras señales consistentes. Google no confía solo en ese atributo: lo cruza con más información disponible.
- El contenido de la página debe estar efectivamente en el idioma indicado. Una página con hreflang en japonés pero con texto en inglés genera una contradicción que perjudica la señal.
- El servidor o CDN debería responder desde una ubicación próxima al mercado objetivo, aunque esto pesa menos desde que Google usa más señales de usuario que de servidor.
- Los backlinks desde dominios del país de destino refuerzan la relevancia geográfica de forma orgánica.
- El nombre de dominio o el subdirectorio comunican la región de forma inmediata, antes incluso de que Google procese el HTML.
Para quien trabaje también con Google Ads en mercados internacionales, conviene asegurarse de que las páginas de destino de cada campaña coincidan con la URL correcta según hreflang. Enviar tráfico de pago a la versión incorrecta genera inconsistencias que afectan tanto a la experiencia del usuario como al nivel de calidad del anuncio. Si quieres entender bien cómo funciona la subasta de Google Ads, verás que la relevancia de la landing page tiene más peso del que parece.
Hreflang en JavaScript y renderizado
Un problema que ha crecido con el auge de frameworks como React, Vue o Next.js: las etiquetas hreflang que se inyectan dinámicamente vía JavaScript pueden no ser procesadas correctamente por Google si el rastreador no ejecuta el JavaScript en ese momento. Google renderiza JavaScript, pero no siempre de forma inmediata.
La recomendación práctica es incluir hreflang en el HTML renderizado en el servidor (server-side rendering) o, mejor aún, gestionarlo desde el sitemap XML, que es independiente del renderizado de la página. Si tu sitio usa SSR de forma consistente y las etiquetas están presentes en el HTML inicial, no debería haber problema. Pero si dependes de un SPA que genera el head de forma dinámica, el sitemap es la opción más segura.
La credibilidad técnica del sitio también influye en con qué prioridad Google rastrea e indexa las versiones. Un dominio con buena autoridad y tiempo de respuesta rápido ve sus cambios de hreflang reflejados antes en los resultados que uno que Google visita con poca frecuencia.
El primer paso antes de tocar ninguna etiqueta
Antes de implementar hreflang, vale la pena auditar qué páginas van a necesitar anotaciones. No todas las URLs de un sitio multilingüe tienen necesariamente una versión equivalente en cada idioma, y apuntar en hreflang a páginas que no existen o que están incompletas genera más problemas que no tener la anotación. Mapea primero las equivalencias reales entre idiomas, confirma que las URLs de destino existen y devuelven 200, y solo entonces empieza a construir la estructura de etiquetas. Una hoja de cálculo con las columnas de URL de origen, idioma, URL de destino y código hreflang por cada par es suficiente para empezar y evita la mayoría de los errores antes de que lleguen a producción.
Preguntas frecuentes
¿Qué pasa si solo añado hreflang en algunas páginas y no en todas las versiones del sitio?
Si las anotaciones no son recíprocas, Google puede ignorar toda la cadena de señales. Por ejemplo, si la versión en español apunta a la versión en inglés pero esta no apunta de vuelta, la señal queda incompleta y sin efecto. Es imprescindible que cada página incluya referencias a todas las variantes y que cada variante haga lo mismo. Antes de publicar, conviene mapear todas las equivalencias en una hoja de cálculo y verificar que cada par es bidireccional.
¿Puedo usar hreflang en un sitio construido con React o Vue sin server-side rendering?
Usar hreflang en un SPA que genera las etiquetas de forma dinámica con JavaScript conlleva un riesgo real: Google puede rastrear la página antes de ejecutar el JavaScript y no procesar las anotaciones. La solución más segura en estos casos es gestionar hreflang desde el sitemap XML, que es completamente independiente del renderizado. Si el proyecto ya tiene previsto implementar SSR, las etiquetas en el head HTML son igualmente válidas siempre que estén presentes en el HTML inicial que recibe el rastreador.
¿Es obligatorio incluir el atributo x-default y a qué URL debería apuntar?
El atributo x-default no es obligatorio, pero sí recomendable porque indica a Google qué versión mostrar cuando ninguna otra versión coincide con el idioma o la región del usuario. Lo más habitual es apuntarlo a una homepage genérica o a una página de selección de idioma. No tiene sentido asignarlo a una versión específica de país, porque en ese caso perdería su función de comodín. Si tu sitio no tiene una página neutral o de selección de idioma, puedes prescindir de él, aunque su presencia mejora la experiencia para usuarios de regiones no cubiertas.
¿Debo usar subdirectorios, subdominios o dominios de país para un sitio que empieza su expansión internacional?
Para la mayoría de proyectos que inician su internacionalización, los subdirectorios son la opción más recomendable porque concentran toda la autoridad de dominio en una sola raíz y son técnicamente más sencillos de gestionar. Los dominios de país ofrecen la señal geográfica más fuerte, pero fragmentan la autoridad y tienen un coste de gestión elevado. Los subdominios se sitúan a medio camino, aunque Google tiende a tratarlos como sitios independientes. Lo más importante es que esta decisión se tome antes de cualquier implementación, porque cambiarla posteriormente implica una migración costosa.
¿Cómo puedo verificar rápidamente que las etiquetas hreflang están funcionando bien después de implementarlas?
La forma más inmediata es rastrear el sitio con Screaming Frog, que permite exportar todas las anotaciones hreflang y cruzar manualmente los pares de URLs para detectar referencias no recíprocas o URLs con errores antes de que Google las procese. Google Search Console también muestra errores de internacionalización en su informe específico, aunque tarda varios días en actualizarse. Como comprobación adicional, hacer búsquedas desde distintos países a través de una VPN permite ver qué versión aparece en los resultados y confirmar que las señales están llegando correctamente a Google.
