i18n SEO: La guía completa de etiquetas hreflang, URLs de l…

i18n SEO: La guía completa de etiquetas hreflang, URLs de locale y posicionamiento en búsquedas multilingües

El SEO multilingüe no es simplemente "SEO normal pero en otro idioma". Es un problema diferente con modos de fallo distintos, y la mayoría de las guías de i18n nunca lo mencionan. Puedes tener contenido perfectamente traducido, una interfaz localizada impecable y aun así ver cómo tus páginas en francés se muestran a usuarios alemanes, porque omitiste unos cuantos detalles técnicos que importan a Google.

Esta guía cubre el stack completo de SEO internacional: estructura de URLs, implementación de hreflang, metadatos específicos por locale, sitemaps, datos estructurados y las decisiones de localización de contenido que realmente mueven las posiciones. Hay ejemplos de código para Next.js, SvelteKit y Vue, porque los detalles de implementación son importantes.

Estrategias de estructura de URLs

Antes de escribir una sola etiqueta hreflang, necesitas decidir cómo están estructuradas tus URLs. Esta decisión es permanente: cambiarla después requiere trabajo de migración y pérdida temporal de posicionamiento. Hazlo bien desde el principio.

Tienes tres opciones:

Estrategia	Ejemplo	Ventajas	Desventajas
ccTLD	`example.de`, `example.fr`	Señal geográfica más fuerte para Google; genera confianza en usuarios locales	Caro; requiere gestión de dominios separada; más difícil compartir autoridad de dominio
Subdominio	`de.example.com`, `fr.example.com`	Fácil de alojar por separado; separación clara	Google trata los subdominios de forma semi-independiente; el link equity compartido es inconsistente
Subdirectorio	`example.com/de/`, `example.com/fr/`	Comparte la autoridad del dominio; más fácil de implementar; mejor para la mayoría de equipos	Señal geográfica ligeramente más débil que ccTLD

La recomendación para la mayoría de equipos: subdirectorio.

A menos que tengas razones sólidas para usar ccTLDs (por ejemplo, eres una gran empresa entrando en mercados donde la confianza en el dominio local importa significativamente) o subdominios (por ejemplo, necesitas infraestructura de alojamiento separada por región), los subdirectorios son la elección pragmática. Heredan la autoridad de tu dominio raíz, son los más fáciles de implementar correctamente y Google los maneja bien combinados con una configuración hreflang adecuada.

Una cosa más: usa siempre códigos de locale en minúsculas separados por guiones en las URLs. /en-us/ está bien; /en_US/ no. La coherencia importa.

Implementación de hreflang

Hreflang es el mecanismo que le dice a Google qué versión de una página mostrar a qué usuario. Si lo haces mal, Google o lo ignora o muestra el locale incorrecto al usuario incorrecto, lo que hunde tanto las posiciones como las tasas de rebote.

La sintaxis básica

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

Cada página de locale debe referenciar todas las demás variantes de locale, incluyéndose a sí misma. Si tu página en inglés no tiene una etiqueta hreflang de autorreferencia, Google puede ignorar todo el conjunto.

La etiqueta x-default

x-default le dice a Google qué página mostrar cuando ningún otro locale coincide. Úsala para tu página de comodín, normalmente tu URL raíz o una página de selección de idioma. No es opcional. La ausencia de x-default es uno de los errores de hreflang más frecuentes.

Códigos de locale: idioma vs región

Google acepta tanto códigos de solo idioma (en, de, fr) como códigos de idioma-región (en-US, en-GB, de-AT). Usa el código más específico que realmente soporte:

Si tienes una versión en inglés para todos los hablantes de inglés: en
Si tienes versiones distintas para EE. UU. y Reino Unido: en-US y en-GB
Si tienes contenido en alemán dirigido específicamente a Austria: de-AT

Mezclar en y en-US en el mismo conjunto hreflang es un error frecuente que confunde la señal de Google. Elige una convención y mantenla en todo el sitio.

Tres formas de implementar hreflang

1. Etiquetas HTML <link> en <head> (recomendado para la mayoría de configuraciones)

La mejor opción para sitios renderizados en servidor o generados estáticamente. Rápido, explícito, fácil de validar.

2. Cabeceras HTTP

Mejor para contenido no HTML (PDFs, etc.) o cuando no puedes modificar el head HTML.

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

3. Anotaciones en el sitemap XML

Mejor para sitios grandes donde añadir hreflang al HTML de cada página es poco práctico.

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

No mezcles métodos en el mismo sitio. Elige uno y úsalo de forma coherente.

Errores frecuentes de hreflang que hunden el posicionamiento

Etiquetas no recíprocas: La página A referencia a la página B, pero la página B no referencia a la página A. Google ignora todo el conjunto.
Códigos de locale incorrectos: en-uk en lugar de en-GB, o zh en lugar de zh-Hans. Usa códigos BCP 47.
Autorreferencia ausente: Cada página debe incluirse a sí misma en su propio conjunto hreflang.
URLs rotas: Cualquier URL hreflang que devuelva un código distinto de 200 invalida la etiqueta.
Mezcla de métodos de implementación: Etiquetas HTML en algunas páginas, sitemap en otras, cabeceras HTTP en unas pocas más. Google se confunde.

Metadatos específicos por locale

El contenido de página traducido no es suficiente. Cada locale necesita sus propios metadatos completamente traducidos: etiquetas de título, meta descripciones, etiquetas Open Graph y URLs canónicas.

El conjunto requerido por locale

<!-- Título y descripción específicos del locale -->
<title>Vollständiger Leitfaden zur i18n-SEO | Better i18n</title>
<meta name="description" content="Alles, was Sie über mehrsprachige SEO wissen müssen..." />

<!-- URL canónica para este locale -->
<link rel="canonical" href="https://example.com/de/blog/i18n-seo-guide/" />

<!-- Open Graph con locale -->
<meta property="og:locale" content="de_DE" />
<meta property="og:locale:alternate" content="en_US" />
<meta property="og:title" content="Vollständiger Leitfaden zur i18n-SEO" />
<meta property="og:url" content="https://example.com/de/blog/i18n-seo-guide/" />

<!-- Conjunto hreflang -->
<link rel="alternate" hreflang="en" href="https://example.com/en/blog/i18n-seo-guide/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/blog/i18n-seo-guide/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/blog/i18n-seo-guide/" />

Fíjate que Open Graph usa códigos de locale separados por guión bajo (de_DE, en_US) mientras que hreflang usa códigos BCP 47 separados por guión (de-DE, en-US). Esta inconsistencia es un punto de fricción conocido y una fuente frecuente de errores.

Implementación en Next.js

generateMetadata() de Next.js 13+ hace que los metadatos conscientes del locale sean sencillos:

// app/[locale]/blog/[slug]/page.tsx
import { Metadata } from 'next'

const locales = ['en', 'de', 'fr', 'es']

export async function generateMetadata({
  params,
}: {
  params: { locale: string; slug: string }
}): Promise<Metadata> {
  const { locale, slug } = params
  const post = await getPost(slug, locale)

  const alternates = locales.reduce(
    (acc, l) => ({
      ...acc,
      [l]: `https://example.com/${l}/blog/${slug}/`,
    }),
    {} as Record<string, string>
  )

  return {
    title: post.title,
    description: post.excerpt,
    alternates: {
      canonical: `https://example.com/${locale}/blog/${slug}/`,
      languages: {
        ...alternates,
        'x-default': `https://example.com/en/blog/${slug}/`,
      },
    },
    openGraph: {
      title: post.title,
      description: post.excerpt,
      url: `https://example.com/${locale}/blog/${slug}/`,
      locale: locale.replace('-', '_'),
      alternateLocale: locales
        .filter((l) => l !== locale)
        .map((l) => l.replace('-', '_')),
    },
  }
}

Next.js renderiza automáticamente el objeto alternates.languages como etiquetas <link rel="alternate" hreflang>. Para un tratamiento completo de los patrones i18n de Next.js con App Router y Server Components, consulta Next.js App Router i18n: Server Components and RSC Patterns for 2026.

Implementación en SvelteKit

<!-- src/routes/[locale]/blog/[slug]/+page.svelte -->
<script lang="ts">
  export let data: PageData

  const { post, locale, slug, locales } = data
  const baseUrl = 'https://example.com'
</script>

<svelte:head>
  <title>{post.title}</title>
  <meta name="description" content={post.excerpt} />
  <link rel="canonical" href="{baseUrl}/{locale}/blog/{slug}/" />

  {#each locales as l}
    <link
      rel="alternate"
      hreflang={l}
      href="{baseUrl}/{l}/blog/{slug}/"
    />
  {/each}
  <link
    rel="alternate"
    hreflang="x-default"
    href="{baseUrl}/en/blog/{slug}/"
  />

  <meta property="og:locale" content={locale.replace('-', '_')} />
  <meta property="og:url" content="{baseUrl}/{locale}/blog/{slug}/" />
</svelte:head>

Para una guía completa sobre cómo construir apps SvelteKit multilingües con traducciones con seguridad de tipos, consulta SvelteKit i18n: Building Type-Safe Multilingual Apps with Svelte 5.

Vue (con @vueuse/head)

// composables/useSeoMeta.ts
import { useHead } from '@vueuse/head'

export function useLocalizedMeta(
  post: Post,
  locale: string,
  slug: string,
  locales: string[]
) {
  const baseUrl = 'https://example.com'

  useHead({
    title: post.title,
    meta: [
      { name: 'description', content: post.excerpt },
      { property: 'og:title', content: post.title },
      { property: 'og:locale', content: locale.replace('-', '_') },
      { property: 'og:url', content: `${baseUrl}/${locale}/blog/${slug}/` },
    ],
    link: [
      { rel: 'canonical', href: `${baseUrl}/${locale}/blog/${slug}/` },
      ...locales.map((l) => ({
        rel: 'alternate' as const,
        hreflang: l,
        href: `${baseUrl}/${l}/blog/${slug}/`,
      })),
      {
        rel: 'alternate',
        hreflang: 'x-default',
        href: `${baseUrl}/en/blog/${slug}/`,
      },
    ],
  })
}

Sitemaps para sitios multilingües

Un sitemap bien estructurado es especialmente importante para sitios multilingües porque le da a Google un mapa explícito de cada variante de locale.

Sitemap XML con anotaciones hreflang

<?xml version="1.0" encoding="UTF-8"?>
<urlset
  xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
  xmlns:xhtml="http://www.w3.org/1999/xhtml"
>
  <url>
    <loc>https://example.com/en/blog/i18n-seo-guide/</loc>
    <lastmod>2026-03-01</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/blog/i18n-seo-guide/"/>
  </url>

  <url>
    <loc>https://example.com/de/blog/i18n-seo-guide/</loc>
    <lastmod>2026-03-01</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
    <xhtml:link rel="alternate" hreflang="en" href="https://example.com/en/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="fr" href="https://example.com/fr/blog/i18n-seo-guide/"/>
    <xhtml:link rel="alternate" hreflang="x-default" href="https://example.com/en/blog/i18n-seo-guide/"/>
  </url>
</urlset>

Cada variante de locale de una página debe aparecer como su propia entrada <url>, y cada entrada debe incluir anotaciones hreflang para todas las variantes. Esto es redundante por diseño.

Índice de sitemap para sitios grandes

Si tienes muchos locales y muchas páginas, un sitemap plano se volverá poco manejable. Usa un índice de sitemap con sitemaps de locale separados:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-en.xml</loc>
    <lastmod>2026-03-01</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-de.xml</loc>
    <lastmod>2026-03-01</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-fr.xml</loc>
    <lastmod>2026-03-01</lastmod>
  </sitemap>
</sitemapindex>

Envía la URL del índice de sitemap a Google Search Console, no los sitemaps individuales. GSC rastreará todos los elementos hijos automáticamente.

Localización de contenido vs. traducción literal

Aquí es donde el SEO multilingüe diverge más claramente del UX multilingüe. Para la usabilidad, una traducción competente puede ser suficiente. Para el SEO, normalmente no lo es.

Por qué la traducción automática rinde menos

El contenido traducido automáticamente tiende a fallar por algunas razones:

Desajuste de palabras clave: Los usuarios en diferentes mercados buscan de forma diferente. La frase alemana para "software de gestión de proyectos" podría ser literalmente "Projektmanagementsoftware", pero los usuarios germanófonos podrían buscar en realidad "Aufgabenverwaltung" o "Team-Kollaborationstool". Una traducción literal de tus palabras clave en inglés no captura estos patrones de búsqueda reales.
Señales de contenido pobre: Los sistemas de calidad de Google pueden detectar cuando el contenido es escaso o poco natural. Las páginas traducidas automáticamente suelen carecer de la profundidad y especificidad que tienen las páginas en idioma nativo.
Falta de contexto local: Una página sobre "software de facturación" para el mercado de EE. UU. podría enfatizar el cumplimiento del IRS. La misma página para Alemania necesita enfatizar la integración con DATEV y el cumplimiento de GoBD. Ese contexto no proviene de la traducción.

Qué hacer en su lugar

Investigación de palabras clave por locale: Usa Google Keyword Planner o Ahrefs con el locale y el idioma objetivo configurados explícitamente. No asumas que tus palabras clave en inglés se traducen.
La intención de búsqueda varía por mercado: La misma consulta de producto puede tener intención comercial en un mercado e intención informacional en otro. Adapta tu contenido en consecuencia.
Localiza, no solo traduzcas: Fechas, monedas, unidades, referencias culturales, requisitos legales y competidores locales deben adaptarse, no solo convertirse.

Para un tratamiento en profundidad de la investigación de palabras clave en diferentes idiomas y la estrategia completa de SEO multilingüe, consulta Multilingual SEO: The Complete Guide to Ranking in Every Language.

Aquí es también donde una plataforma como Better i18n ayuda, no solo para la gestión de traducciones, sino para mantener glosarios que aseguren que tu terminología localizada sea coherente e intencionada en todos los mercados.

Lista de verificación de implementación técnica

Antes de lanzar el soporte multilingüe, verifica:

Estructura de URLs:

Formato de prefijo de locale consistente en todas las páginas (/en/, /de/, etc.)
Códigos de locale en minúsculas separados por guiones
Todas las URLs de locale devuelven 200 (sin redirecciones)

Hreflang:

Cada página de locale incluye etiquetas hreflang para todos los demás locales
Cada página incluye una etiqueta hreflang de autorreferencia
x-default está configurado en todas las páginas
Todas las URLs hreflang son absolutas (no relativas)
Hreflang se implementa con un solo método (etiquetas HTML O sitemap O cabeceras HTTP)
Todas las etiquetas hreflang son recíprocas

Metadatos:

Etiquetas de título traducidas por locale
Meta descripciones traducidas por locale
Las URLs canónicas apuntan a la URL de locale correcta
Open Graph og:locale configurado por locale
Open Graph og:locale:alternate lista los demás locales

Sitemap:

Todas las variantes de locale incluidas en el sitemap
Las anotaciones hreflang en el sitemap coinciden con las etiquetas del head HTML
Sitemap enviado a Google Search Console

Google Search Console para i18n

Google Search Console es tu principal herramienta de diagnóstico para el SEO internacional. Úsala activamente.

Informe de segmentación internacional

En GSC, navega a Herramientas y informes heredados > Segmentación internacional. Aquí puedes:

Establecer un objetivo geográfico para todo el sitio (útil para ccTLDs y subdominios)
Ver la pestaña hreflang para detectar errores en tu implementación

El informe de hreflang muestra los errores de implementación más comunes: etiquetas de retorno faltantes, códigos de locale inválidos y URLs que devuelven respuestas distintas de 200.

Informe de cobertura por locale

Usa el tipo de propiedad de prefijo de URL en GSC para configurar propiedades separadas por locale (por ejemplo, https://example.com/de/). Esto te permite monitorear la cobertura de rastreo, el estado de indexación y el rendimiento en búsqueda para cada locale de forma independiente.

Filtrado del informe de rendimiento

En el informe de rendimiento, filtra por país para ver cómo se posiciona cada locale en su mercado objetivo. Compáralo con tu configuración de locale para verificar que las páginas correctas están posicionando en los países correctos.

Errores comunes

1. Contenido duplicado entre locales

Servir el mismo contenido en múltiples URLs, por ejemplo que example.com/en/ y example.com/ devuelvan contenido en inglés idéntico, sin configuración de canónico o hreflang adecuada, genera señales de contenido duplicado que diluyen la autoridad de posicionamiento. Establece siempre canónicos explícitos y asegúrate de que tu URL raíz redirija o tenga una relación clara con un locale específico.

2. Códigos de locale incorrectos

Los errores más frecuentes:

en-uk en lugar de en-GB (los códigos de región son en mayúsculas)
zh en lugar de zh-Hans o zh-Hant para chino simplificado/tradicional
pt en lugar de pt-BR o pt-PT cuando sirves variantes distintas del portugués
Uso inconsistente de etiquetas de idioma IETF (mezclando en-US y en_US)

Consulta el Registro de subetiquetas de idioma de IANA o BCP 47 en caso de duda.

3. Mezcla de métodos hreflang

Si algunas páginas usan etiquetas HTML <link> y otras usan anotaciones del sitemap, Google puede aplicar un tratamiento inconsistente. Elige un método para todo tu sitio.

4. Páginas de locale huérfanas

Una página de locale que no está enlazada desde ninguna otra página y no está en tu sitemap es efectivamente invisible. Asegúrate de que cada locale de cada página sea descubrible mediante enlaces internos y cobertura del sitemap.

5. No traducir los metadatos

Traducir el contenido del cuerpo pero dejar las etiquetas de título y las meta descripciones en inglés es un atajo habitual. Resulta en fragmentos de búsqueda en inglés apareciendo en SERPs que no son en inglés, lo que reduce las tasas de clics incluso cuando el posicionamiento es bueno.

Datos estructurados para sitios multilingües

Los datos estructurados (JSON-LD) deben localizarse junto con tu contenido HTML.

Esquema de organización con variantes de idioma

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Corp",
  "url": "https://example.com/de/",
  "inLanguage": "de-DE",
  "sameAs": [
    "https://example.com/en/",
    "https://example.com/fr/"
  ]
}

Esquema de artículo localizado

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Vollständiger Leitfaden zur i18n-SEO",
  "inLanguage": "de-DE",
  "url": "https://example.com/de/blog/i18n-seo-guide/",
  "datePublished": "2026-03-01",
  "author": {
    "@type": "Organization",
    "name": "Acme Corp"
  }
}

Esquema FAQ multilingüe

Si tienes contenido FAQ localizado, el esquema FAQ de cada locale debe usar las preguntas y respuestas de ese locale, no la versión en inglés:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "inLanguage": "de-DE",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Was ist hreflang?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Hreflang ist ein HTML-Attribut, das Google mitteilt, welche Sprachversion einer Seite für welche Nutzer gedacht ist."
      }
    }
  ]
}

La propiedad inLanguage es el añadido clave. Sin ella, Google puede aplicar tus datos estructurados al contexto de locale incorrecto.

Conclusión

El SEO multilingüe es genuinamente complejo; no hay forma de simplificarlo sin ocultar las partes que importan. La especificación de hreflang es extensa e implacable. Las decisiones de estructura de URLs son difíciles de revertir. La localización de contenido requiere experiencia específica de cada mercado que la traducción por sí sola no puede proporcionar.

La buena noticia: la mayoría de tus competidores lo están haciendo mal. La implementación correcta de hreflang, los metadatos específicos por locale y el contenido realmente localizado (no solo traducido) son ventajas competitivas en mercados internacionales.

Para resumir la lista de verificación completa:

Elige la estructura de URLs desde el principio — subdirectorio para la mayoría de equipos
Implementa hreflang con un solo método — las etiquetas HTML son las más fáciles para la mayoría de configuraciones
Incluye los cuatro elementos: etiqueta de autorreferencia, todas las variantes de locale, x-default, etiquetas recíprocas
Traduce todos los metadatos — títulos, descripciones, Open Graph, datos estructurados
Crea un sitemap adecuado — con anotaciones hreflang para cada locale de cada página
Haz investigación de palabras clave por locale — no asumas que los términos de búsqueda se traducen directamente
Monitorea en GSC — el informe de hreflang detecta errores de implementación antes de que te cuesten posiciones

Para equipos de desarrollo que gestionan múltiples locales a escala, la capa de gestión de traducciones importa tanto como la implementación técnica. Consulta Better i18n para desarrolladores y cómo se integra con Next.js, incluyendo la entrega CDN de actualizaciones de traducción sin redeploy y la traducción con IA con aplicación de glosarios que mantiene tu terminología localizada consistente en todos los mercados.

Si estás empezando con i18n, el artículo introductorio what is i18n es una buena base antes de adentrarte en la capa SEO.

Better i18n es una plataforma de localización orientada al desarrollador creada para equipos frontend modernos. SDKs con seguridad de tipos, flujos de trabajo basados en Git, entrega CDN y traducción con IA con aplicación de glosarios, sin archivos de locale en tu repositorio.

Lleva tu app al mundo con better-i18n

better-i18n combina traducciones potenciadas por IA, flujos de trabajo nativos de Git y entrega CDN global en una plataforma única orientada al desarrollador. Deja de gestionar hojas de cálculo y empieza a publicar en todos los idiomas.

Empieza gratis → · Explora las funciones · Lee la documentación

i18n SEO: La guía completa de etiquetas hreflang, URLs de locale y posicionamiento en búsquedas multilingües