SEO internacional: la arquitectura de hreflang que realmente funciona

La mayoría de los sitios web multilingües no fracasan por la calidad de sus traducciones. Fracasan por deficiencias en su arquitectura técnica, un problema que pasa inadvertido internamente porque cada empleado ve la web correctamente en su propio navegador.

El error estructural más frecuente es el siguiente:

El sitio web «admite» seis idiomas sustituyendo los textos mediante JavaScript bajo una única URL.

Existe una sola página y una única URL. Google la rastrea e indexa una sola vez, en un único idioma. El contenido en alemán o español solo existe en el navegador del usuario tras ejecutarse un script en cliente. Nunca ha sido indexado por los motores de búsqueda porque no existe una URL en alemán que rastrear. Un comprador en Alemania que busque en su idioma nativo jamás encontrará esa página.

Si el selector de idioma modifica el contenido visual sin alterar la URL en la barra de direcciones, usted no tiene un sitio web multilingüe: tiene un sitio monolingüe con una función de traducción en el navegador.

Las tres arquitecturas reconocidas por Google

Google admite exactamente tres estructuras para segmentar contenido por idioma y región geográfica. Elija una y aplíquela de forma homogénea en todo el proyecto:

Los subdirectorios son la opción más eficiente para la inmensa mayoría de negocios. Heredan directamente la autoridad del dominio principal, no requieren costes adicionales de infraestructura y simplifican el mantenimiento. Un nuevo ccTLD (.es, .de, .fr) parte de cero autoridad y exige construir un perfil de enlaces independiente desde el inicio, una inversión a largo plazo justificada únicamente cuando la confianza del consumidor local exige estrictamente un dominio de nivel superior nacional.

Los parámetros en URL (example.com/?lang=es) no figuran en esta tabla. Google desaconseja expresamente su uso para la orientación por idioma: provocan problemas de indexación, generan contenido duplicado y fragilizan la red de anotaciones hreflang.

Localizar también las rutas (slugs) en la URL

Si ha optado por URLs dedicadas por idioma, aplique la localización a toda la estructura:

/en/services/web-design/
/de/leistungen/webdesign/
/es/servicios/diseno-web/
/fr/services/conception-web/

Evite mantener slugs en inglés bajo prefijos de idioma:

/en/services/web-design/
/de/services/web-design/
/es/services/web-design/

La segunda opción funciona técnicamente, pero desaprovecha la URL, una de las pocas señales que los motores de búsqueda evalúan antes de renderizar la página. Un usuario hispanohablante que revisa los resultados de búsqueda percibe mayor relevancia al ver una URL y un título completamente en español, lo que eleva directamente el CTR.

La objeción habitual es la complejidad de mantenimiento. Ese inconveniente solo existe si las páginas se crean manualmente; en cualquier gestor de contenidos o arquitectura moderna basada en datos, definir un campo slug por idioma requiere apenas una línea de configuración.

hreflang: las cuatro reglas que garantizan su funcionamiento

El etiquetado hreflang es conceptualmente sencillo pero estricto en su validación. Cuatro reglas técnicas concentran la práctica totalidad de los errores en producción:

1. Reciprocidad estricta

Si la versión en español apunta a la versión en alemán, la página en alemán debe devolver el enlace recíproco a la española. Si falta este retorno, Google descarta la anotación por completo para ese par de idiomas.

Este fallo surge con frecuencia cuando una página existe solo en ciertos idiomas y la lógica de generación de etiquetas no es simétrica.

2. Toda página debe autorreferenciarse

El bloque de etiquetas hreflang de cada página debe incluir obligatoriamente una entrada que apunte a sí misma. Un conjunto que enumera las versiones alternativas pero omite la URL actual es sintácticamente inválido.

3. Utilizar siempre URLs absolutas

<!-- Correcto -->
<link rel="alternate" hreflang="es" href="https://example.com/es/servicios/" />

<!-- Incorrecto (invalida la directiva) -->
<link rel="alternate" hreflang="es" href="/es/servicios/" />

Las URLs relativas no están admitidas en hreflang y causan fallos silenciosos en el rastreo.

4. Códigos de idioma y región según el estándar ISO

• Solo idioma: es, de, fr — para todos los hablantes de ese idioma globalmente.
• Idioma y región combinados: es-ES, es-MX, en-GB, pt-BR — formato ISO 639-1 para idioma e ISO 3166-1 Alpha-2 para país.
• La región aislada es inválida. hreflang="mx" no significa México (mx no es un código de idioma).
• Variantes de escritura cuando corresponda: zh-Hans, zh-Hant.

Y un valor especial: x-default, para usuarios cuyo idioma no coincide con ninguna de las versiones disponibles. Debe apuntar a la versión en el idioma principal del sitio o a un selector de idioma.

Ejemplo de implementación completa y correcta en cada una de las páginas del grupo:

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

El error crítico con las etiquetas canonical

Este error arruina silenciosamente la indexación de webs internacionales:

Cada versión de idioma debe declararse a sí misma como su propia URL canónica.

<!-- En /es/servicios/ — Correcto -->
<link rel="canonical" href="https://example.com/es/servicios/" />

<!-- En /es/servicios/ — Invalida la indexación de la página en español -->
<link rel="canonical" href="https://example.com/en/services/" />

La segunda opción indica a Google que la página en español es un duplicado de la inglesa y que no debe indexarse por separado. Al coexistir con etiquetas hreflang que afirman lo contrario, se emiten directivas contradictorias en las que la etiqueta canonical siempre se impone.

El origen de este error suele ser la creencia de que las traducciones son contenido duplicado. No lo son: son páginas independientes orientadas a consultas e intenciones de búsqueda distintas.

Gestión técnica de traducciones parciales

En proyectos en crecimiento, no todos los contenidos se traducen simultáneamente. Se lanzan tres idiomas prioritarios y se van incorporando nuevos mercados progresivamente.

Existe un protocolo técnico riguroso para gestionar este desfase:

Nunca publique páginas no traducidas rellenando el contenido en inglés bajo una URL /es/ para forzar su indexación. Creará contenido duplicado y de baja calidad en un mercado estratégico, compitiendo contra su propia versión en inglés.

Protocolo recomendado:

• Sirva la página con el texto de respaldo en inglés para que los enlaces internos funcionen sin devolver errores 404.
• Inserte <meta name="robots" content="noindex, follow"> mientras el contenido no alcance el umbral de traducción requerido.
• Excluya la página del sitemap XML de ese idioma.
• Omita la URL del bloque de etiquetas hreflang de las demás versiones idiomáticas.
• Retire automáticamente las restricciones en el momento en que se publique la traducción completa.

En nuestra propia plataforma automatizamos este proceso: cualquier página con una cobertura de traducción inferior al 85% se compila y permanece navegable, pero se marca de forma estricta con noindex y queda fuera del sitemap hasta que se completa su localización.

Sitemaps XML desglosados por idioma

Cuando un sitio web supera varios cientos de URLs, un sitemap único resulta difícil de gestionar y diagnosticar. Separe los sitemaps por idioma mediante un archivo índice:

<!-- /sitemap.xml -->
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>https://example.com/sitemaps/sitemap-en.xml</loc></sitemap>
  <sitemap><loc>https://example.com/sitemaps/sitemap-es.xml</loc></sitemap>
  <sitemap><loc>https://example.com/sitemaps/sitemap-de.xml</loc></sitemap>
</sitemapindex>

Esta segmentación permite supervisar en Google Search Console el porcentaje exacto de indexación por mercado (por ejemplo, detectar de un vistazo si el mercado alemán está indexado al 95% mientras el francés permanece al 40%).

Redirección de usuarios según su idioma

Redirección en la raíz según la cabecera Accept-Language. Un usuario que accede a / puede ser redirigido mediante un código HTTP 302 a /es/ si su navegador solicita español. Los bots de rastreo no envían cabeceras de preferencia de idioma y acceden a la versión predeterminada sin bloqueo.

Dos condiciones críticas: utilice siempre redirecciones temporales (302) y nunca permanentes (301), y ofrezca siempre un selector manual visible para que el usuario pueda cambiar de idioma libremente.

Nunca aplique redirecciones basadas exclusivamente en la geolocalización por IP. Un hispanohablante que viaje a Japón no desea ser forzado a navegar en japonés, y los rastreadores de Google que operan desde EE. UU. solo verían la versión en inglés, impidiendo el descubrimiento de las demás versiones.

Diagnóstico de un sitio web multilingüe

Si gestiona un sitio multilingüe existente, audite estos seis puntos en orden:

1. ¿Dispone cada idioma de su propia URL independiente?
2. ¿Se sirve el contenido en el HTML inicial desde el servidor? Verifíquelo con curl.
3. ¿Apuntan las etiquetas canonical a su propia versión de idioma?
4. ¿Son las etiquetas hreflang perfectamente recíprocas?
5. ¿Existe alguna directiva noindex accidental en versiones traducidas?
6. ¿Están registrados y verificados los sitemaps de cada idioma en Search Console?

Nuestra herramienta gratuita de auditoría SEO analiza automáticamente las etiquetas hreflang, canonicals y directivas de indexación de cualquier página.

Abrir herramienta Verificador hreflang Valide su arquitectura hreflang — descargamos cada URL alternativa para confirmar la reciprocidad de enlaces. →