Hreflang Guía 2026: 5 Errores que Hunden el SEO

Why Hreflang Matters for International Websites

Hreflang is an HTML attribute that tells search engines which language and regional version of a page to show to users in different locations. Without it, Google may show your English page to French users, your German page to Austrian users looking for Swiss-German content, or, in the worst case, flag your localized pages as duplicate content and deindex them entirely.

For businesses operating across multiple European markets, correct hreflang implementation is not optional. It directly impacts which version of your pages appears in local search results, which in turn affects click-through rates, user experience, and ultimately conversion. A 2025 Ahrefs study found that websites with correct hreflang implementation saw 47% higher organic traffic from non-primary markets compared to sites with incorrect or missing hreflang tags.

The Three Implementation Methods

There are three ways to implement hreflang: HTML link elements in the page head, HTTP headers, and XML sitemaps. Each has advantages depending on your technical setup.

HTML link elements are the most common method. You add a set of link tags in the head of every page, one for each language/region variant including a self-referencing tag. This is straightforward for small sites but becomes unwieldy when you have dozens of language variants.

HTTP headers are used for non-HTML resources (PDFs, for example) and can be useful when you cannot modify the HTML head. They work identically to the HTML method but are specified in the server response headers.

XML sitemaps are the best approach for large sites with many language variants. You specify hreflang annotations in your sitemap using the xhtml:link element within each URL entry. This keeps the hreflang logic centralized, makes it easier to audit, and does not add weight to your HTML pages. For sites with 5+ language variants, we strongly recommend the sitemap approach.

Here is how the three methods compare at a glance:

Mistake 1: Missing Return Links

The most common hreflang error is missing return links. Hreflang annotations must be bidirectional: if Page A declares Page B as its French variant, Page B must also declare Page A as its English variant. If either direction is missing, Google ignores both annotations.

This sounds simple but becomes complex at scale. If you have 10 language variants, every page needs 10 hreflang tags (including self-referencing), and all 10 pages must have matching annotations. That is 100 annotations that must be perfectly synchronized across 10 separate pages. One missing or mismatched annotation can break the entire chain.

The solution is to generate hreflang annotations programmatically from a single source of truth, typically a database or CMS that knows which pages are translations of each other. Never manually maintain hreflang tags across localized pages.

Mistakes 2-3: Wrong Language Codes and Missing x-default

Mistake 2: Wrong language and region codes. Hreflang uses ISO 639-1 language codes and optionally ISO 3166-1 Alpha 2 region codes. Common errors include using "uk" for Ukrainian (it should be "uk" for the language, not "ua" for the country), confusing "zh-Hans" (simplified Chinese) with "zh-CN" (Chinese for China), and using three-letter language codes (which are not supported).

For European implementations, pay attention to regional variants: "pt" (Portuguese) is different from "pt-BR" (Brazilian Portuguese). "en-GB" and "en-US" are distinct variants. If you serve different content to Austrian ("de-AT") and German ("de-DE") users, you need separate hreflang annotations for each.

Mistake 3: Missing x-default tag. The x-default hreflang value tells search engines which page to show when no other hreflang variant matches the user's language or region. Without it, Google makes its own choice, which may not be what you want. Always include an x-default that points to your language selector page or your English-language version as a fallback.

Mistakes 4-5: Canonical Conflicts and Non-200 Pages

Mistake 4: Canonical and hreflang conflicts. If a page has a canonical tag pointing to a different URL than what the hreflang annotation specifies, Google will follow the canonical and ignore the hreflang. Every page referenced in your hreflang annotations must have a self-referencing canonical tag. If your French page at /fr/product/ has a canonical pointing to /en/product/, your hreflang annotation for the French page will be silently ignored.

Mistake 5: Hreflang pointing to non-200 pages. Every URL in your hreflang annotations must return a 200 HTTP status code. If any URL returns a 301 redirect, a 404, or a 500 error, Google will ignore the hreflang annotation for that entire page set. This commonly happens during site migrations or URL structure changes when old URLs are redirected but hreflang annotations are not updated simultaneously.

To catch these issues, implement automated monitoring. Google Search Console reports hreflang errors, but with a delay. Tools like Screaming Frog, Sitebulb, or Ahrefs can crawl your site and validate hreflang annotations in real-time, catching errors before they impact your rankings.

Un Ejemplo Concreto: una URL, tres Idiomas

La teoría se asimila mejor con un caso concreto. Imagina que gestionas un e-commerce con páginas de producto en inglés (internacional), italiano y español. La estructura de URLs es la siguiente:

• https://example.com/products/widget/ (en, x-default)
• https://example.com/it/products/widget/ (it)
• https://example.com/es/products/widget/ (es)

Cada uno de esos tres URLs debe llevar un conjunto completo y recíproco de anotaciones hreflang. Esto es lo que necesita contener el head de la página inglesa:

<link rel="alternate" hreflang="en"
      href="https://example.com/products/widget/" />
<link rel="alternate" hreflang="it"
      href="https://example.com/it/products/widget/" />
<link rel="alternate" hreflang="es"
      href="https://example.com/es/products/widget/" />
<link rel="alternate" hreflang="x-default"
      href="https://example.com/products/widget/" />

La página italiana (/it/products/widget/) debe contener exactamente los mismos cuatro tags, con los mismos cuatro URLs, sin cambios. Lo mismo ocurre con la página española. Las tres páginas llevan el conjunto completo; lo único que cambia entre ellas es su propio canonical, que cada página apunta a sí misma. Si se omite aunque sea un solo tag en una sola página, Google descarta en silencio todo el clúster de anotaciones para ese producto.

Algunos aspectos a tener en cuenta en este ejemplo. El x-default y la página inglesa comparten el mismo URL, que es el patrón más común para sitios sin una página dedicada a la selección de idioma. Si tienes una página selectora en /products/, apunta el x-default ahí. Los códigos de idioma son valores ISO 639-1 puros (en, it, es), sin calificadores de región. Añadir un calificador de región (en-GB, es-MX) solo está justificado cuando sirves contenido genuinamente diferente a usuarios en distintos países que hablan el mismo idioma.

Cómo Validar tu Implementación Hreflang

Poner los tags en la página es solo la mitad del trabajo. Hay que confirmar que Google los lee correctamente y que no se han introducido errores silenciosos. Hay tres formas prácticas de hacerlo.

Informe International Targeting de Search Console. En Search Console, ve a Herramientas y reportes heredados, luego International Targeting. La pestaña Idioma muestra los valores hreflang detectados en tu sitio y marca los códigos de idioma que Search Console no puede interpretar. El informe tiene un retraso de varios días, así que trátalo como una auditoría periódica, no como verificación post-despliegue. Nota importante: la ausencia de errores no confirma que Google esté actuando sobre los tags, solo que puede leerlos.

Un crawler dedicado para hreflang. Herramientas como Screaming Frog (Configuración > Spider > Crawl linked XML sitemaps and hreflang), Sitebulb y JetOctopus pueden seguir las relaciones hreflang en todo el conjunto de variantes locale en una sola pasada. Muestran enlaces recíprocos rotos, URLs no coincidentes entre páginas vinculadas y tags apuntando a redirecciones o 404, todo en una sola exportación. Para cualquier sitio con más de dos o tres variantes locale, un rastreo es la única forma realista de detectar errores sistemáticos.

Una verificación curl rápida para una URL específica. Cuando se quiere verificar una sola página inmediatamente después del despliegue, se pueden inspeccionar los response headers y el head HTML sin un rastreo completo:

curl -s "https://example.com/products/widget/" | grep -i hreflang

El comando imprime todos los elementos link hreflang del código fuente de la página. Verifica que el recuento coincida con el número de variantes locale esperadas (incluido el x-default) y que cada URL sea absoluta y no relativa. Las URLs relativas en las anotaciones hreflang no están soportadas y provocan que el tag sea ignorado en silencio.

Preguntas Frecuentes sobre Hreflang

¿Cómo se implementan las etiquetas hreflang correctamente?

Declara hreflang en un solo lugar por página (elementos link en el head, cabeceras HTTP o entradas en el sitemap XML) y mantén ese método consistente. Cada variante referencia a todas las demás, incluyéndose a sí misma, y cada referencia debe ser recíproca. Mezclar métodos en una URL y omitir la auto-referencia son las dos roturas más frecuentes.

¿Dónde van las etiquetas hreflang: head HTML, cabecera HTTP o sitemap?

El head HTML es la opción correcta para la mayoría de sitios con menos de una docena de variantes locale. Las cabeceras HTTP son adecuadas para recursos no HTML como PDFs o cuando no se puede modificar el head. El método sitemap gana a escala, donde se tienen cientos de páginas por locale y se quiere mantener el peso de página ligero. No declares nunca hreflang en más de un lugar para la misma URL.

¿Qué significa x-default?

x-default es el valor de reserva de hreflang. Le dice a los motores de búsqueda qué página servir cuando ningún idioma o región coincide con el usuario, y normalmente apunta a un selector de idioma o a la versión inglesa principal. Si se omite, Google hace una estimación, lo que a menudo resulta en que el locale equivocado aparece en regiones no mapeadas.

¿Por qué mi hreflang no funciona?

Cinco sospechosos habituales: un enlace no recíproco, un código ISO incorrecto (en-UK en vez de en-GB), una auto-referencia ausente, dos métodos de declaración en una URL, o hreflang apuntando a una URL que devuelve 404 o redirige. Revisa el informe International Targeting en Search Console y usa un crawler como Screaming Frog antes de concluir que Google está ignorando los tags.

¿Hreflang ayuda con el contenido duplicado entre sitios de distintos países?

Sí, pero de forma específica. Hreflang no suprime las señales de contenido duplicado como lo hace un canonical. Le dice a Google que dos páginas similares están destinadas a audiencias diferentes y deben tratarse como resultados separados y orientados, no como copias en competencia. Si el contenido es sustancialmente idéntico entre variantes locale con solo pequeñas diferencias como divisa o formatos de fecha, las anotaciones igualmente ayudan, pero una localización real siempre producirá señales más fuertes.

¿Cuántas etiquetas hreflang puede tener una página?

No existe un límite máximo documentado por Google. Los sitios con 50 o más variantes locale activas suelen usar sitemaps XML en lugar de elementos link en el head, porque colocar tantos link tags en el head de cada página añade un peso medible a las respuestas HTML. Si el recuento de tags con el método head se acerca a 20 o más, considera migrar al método sitemap, que escala a cientos de variantes locale sin ninguna sobrecarga por página.

¿Necesito hreflang si mis páginas están en el mismo idioma pero apuntan a países distintos?

Sí. Si sirves contenido significativamente diferente a, por ejemplo, usuarios británicos y australianos de habla inglesa (precios distintos, disponibilidad de producto, condiciones legales), hreflang con calificadores de región (en-GB y en-AU) le dice a Google que muestre cada variante a la audiencia correcta. Sin él, Google elegirá la versión que considere más autorizada y la servirá globalmente. Las páginas que solo difieren en la ortografía probablemente no justifican el trabajo adicional; las que tienen precios, opciones de envío o advertencias legales distintas, sí.