SEO multilingüe: hreflang, estructura y localización
Cómo planificar idiomas, URL, hreflang y contenido traducido para que cada audiencia llegue a una versión distinta, útil e indexable.
Un sitio multilingüe no es solo un conjunto de páginas traducidas. Desde el punto de vista del SEO, es un reto de arquitectura distinto: Google debe entender qué versión está pensada para cada audiencia, dónde está la URL canónica y cómo se reparte la autoridad de enlace entre las versiones de idioma. Una estructura mal elegida se convierte en deuda técnica durante años.
Tres estrategias de estructura de URL
Google admite oficialmente tres enfoques de estructura de URL para sitios multilingües y multirregionales. Cada uno tiene sus ventajas, sus limitaciones y sus requisitos de infraestructura.
Subdirectorios
example.com/ru/, example.com/en/, example.com/de/: todo en un mismo dominio. Toda la autoridad de enlace se concentra en un único dominio. Mantenimiento sencillo: un sitio, un servidor, una infraestructura. El inconveniente: Google no trata un subdirectorio como un sitio local, porque el dominio no está ligado a un país. Es la mejor opción para la mayoría de negocios con audiencia internacional.
Subdominios
ru.example.com, en.example.com, de.example.com: sitios técnicamente separados que comparten dominio raíz. Google trata un subdominio como un sitio aparte, lo que complica la transferencia de autoridad de enlace. El geotargeting se configura en Search Console. Antes lo usaban mucho las grandes empresas; hoy se considera una opción anticuada para la mayoría de escenarios multilingües.
Dominios separados / ccTLD
example.ru, example.de, example.fr: dominios individuales, cada uno vinculado a un país concreto. La señal de geotargeting más fuerte para Google. Los usuarios de Alemania confían más en .de que en .com. El inconveniente: cada dominio necesita su propia captación de backlinks, alojamiento, mantenimiento de SSL y trabajo de contenido. Costes operativos altos a gran escala.
¿Hace falta geotargeting?
Si tu negocio opera en ciudades o regiones concretas (servicios en Londres, Berlín, Varsovia), el geotargeting es una parte obligatoria de la arquitectura. Para ciudades y regiones se usan subdirectorios con slugs semánticos: /london/, /berlin/, /warsaw/. No es lo mismo que multilingüe: el geotargeting puede aplicarse dentro de un solo idioma.
En los parámetros clave: los subdirectorios ganan en concentración de autoridad de enlace y en sencillez de mantenimiento. Los ccTLD ganan en fuerza de la señal geográfica. Los subdominios no ganan en ninguna de las dos categorías y van perdiendo terreno poco a poco.
Geotargeting: ciudades, regiones y países
El SEO regional es una disciplina propia dentro de la arquitectura multilingüe. Cuando un usuario busca «reforma de pisos en Múnich», Google quiere mostrar un sitio que indique relevancia para esa ciudad concreta. Varios mecanismos actúan a la vez.
- Geotargeting por URL
- Subdirectorios con códigos de región o ciudad en la URL: /london/, /berlin/, /warsaw/. O dominios ccTLD por país: .de para Alemania, .fr para Francia, .pl para Polonia. El rastreador lee la señal de la URL antes de analizar el contenido de la página.
- Geotargeting por Search Console
- En subdominios y TLD genéricos (.com, .org) puedes indicar un país objetivo en la configuración de la propiedad de Google Search Console. Funciona como señal adicional, pero es más débil que un ccTLD. No se puede aplicar a subdirectorios, solo al dominio o subdominio en su conjunto.
- Geotargeting por contenido y NAP
- Menciones de ciudad, región y dirección, junto con teléfonos locales, en el contenido (NAP: Name, Address, Phone, es decir, nombre, dirección y teléfono). Son importantes para el SEO local. Google cruza las señales del contenido con los datos de Google Maps y de Google Business Profile.
Para negocios con oficinas en varias ciudades, la estructura óptima es un dominio principal con subdirectorios: site.com/london/, site.com/berlin/. Páginas separadas por ciudad, con contenido único y no solo con el nombre de la ciudad cambiado. El contenido duplicado con el nombre de la ciudad sustituido es uno de los filtros más habituales del SEO local.
Elección de plataforma: WordPress, MODX, Next.js y CMS headless
La elección del CMS afecta de forma decisiva a las capacidades multilingües y multirregionales. Cada plataforma resuelve el problema a su manera, con compromisos distintos en flexibilidad, coste de desarrollo y escalabilidad.
WordPress + WPML o Polylang
La solución más extendida. WPML es un plugin comercial potente (unos 99 $ al año) que admite cualquier número de idiomas, sincroniza traducciones y tiene un generador de hreflang. Polylang es una alternativa gratuita con funciones limitadas en su versión básica. Limitación: WordPress no se diseñó para ser multilingüe desde el principio, así que cualquier solución es una capa adicional que complica la base de datos y ralentiza el sitio con el tiempo.
MODX + Babel
MODX admite multilingüe mediante el componente Babel (configuración de contextos). Cada idioma o región es un contexto aparte, con su propio árbol de recursos, ajustes y dominio. Es más flexible que WordPress+WPML, pero requiere un desarrollador de MODX con experiencia. La documentación es escasa y el ecosistema, pequeño. Encaja cuando el equipo ya tiene experiencia con MODX.
Next.js + next-intl
La solución nativa para aplicaciones modernas. next-intl ofrece enrutamiento por locale, gestión de traducciones con archivos JSON y soporte completo de SSR/SSG. La ventaja clave: desde un único monorepo puedes servir varios dominios con locales distintos mediante el middleware de Next.js. Sin sobrecarga de plugins ni conflictos de versiones: la lógica de internacionalización va integrada en la arquitectura.
CMS headless (Contentful, Sanity, Strapi)
El enfoque headless separa el backend de contenido (CMS) del frontend (Next.js, Nuxt, SvelteKit). Una sola fuente de contenido, varios frontends o dominios construidos sobre ella. Contentful y Sanity admiten localización a nivel de campo. Los editores tienen una interfaz cómoda y los desarrolladores, un stack totalmente libre. Inconveniente: añade otro servicio a la infraestructura, con sus costes asociados.
Para un sitio corporativo bilingüe sencillo, WordPress+WPML es una opción razonable. Para una red regional compleja con decenas de dominios, solo Next.js. MODX encaja cuando el equipo ya trabaja con esa plataforma y tiene la experiencia necesaria.
Next.js y configuración multidominio: un monorepo, varios ccTLD
Es la arquitectura más potente y también la más compleja de implementar. El concepto: un solo código, un solo repositorio, un solo pipeline de despliegue, pero varios dominios ccTLD independientes para distintos países. Solo está disponible con Next.js (y con Nuxt 3, en un paradigma parecido): WordPress y MODX no pueden hacerlo sin una reestructuración profunda de la infraestructura.
En la práctica, en next.config.ts defines los dominios y sus locales correspondientes. El middleware intercepta la petición, comprueba el hostname (seohead.ru → ru, seohead.com → en, seohead.de → de) y asigna el locale correcto a la petición. Todos los componentes, traducciones y metadatos SEO reciben la localización adecuada sin duplicar código.
Gestión de contenido unificada
Un único conjunto de archivos JSON o un único CMS headless gestiona el contenido de todos los dominios. Actualizar un artículo, añadir un producto nuevo o cambiar la navegación se aplica a todos los sitios con un solo despliegue.
Despliegue unificado
Un pipeline de CI/CD construye una única imagen que sirve a todos los dominios. Nginx o un CDN envían el tráfico de distintos dominios a un único contenedor. Los costes de infraestructura son más bajos que los de mantener sitios independientes.
Reutilización de componentes
Header, footer, metaetiquetas SEO y datos estructurados: se escriben una vez y funcionan en todos los dominios con la localización correcta. Actualizar un componente se aplica a todos a la vez, sin riesgo de divergencias.
Complejidad de implementación
La arquitectura requiere un desarrollador de Next.js con experiencia. Hay que configurar bien el middleware, el hreflang de cada dominio, un sitemap separado por dominio, robots.txt por dominio y metadatos SEO separados. Los errores provocan canibalización de palabras clave y pérdida de señales de geotargeting.
Para quién tiene sentido: negocios que operan en 3 o más países con ccTLD propios, un equipo de desarrollo (no un único freelance) y un stack Next.js existente o planificado. Para un negocio pequeño con uno o dos idiomas, es excesivo.
Localización y traducción: cómo hacerlo bien
Localizar no es traducir. Traducir es transmitir el significado en otro idioma. Localizar es adaptar el contenido al contexto cultural, a las expectativas de la audiencia y a las normas locales. Para el SEO la diferencia es decisiva: la traducción automática genera contenido duplicado de baja calidad que Google detecta cada vez mejor.
- Traducción automática (DeepL, Google Translate)
- Rápida y barata, pero requiere una revisión obligatoria por parte de una persona nativa. La traducción automática sin posedición no es localización: es un factor de riesgo de penalización por contenido pobre. Úsala como borrador, no como resultado final.
- Traducción profesional con localización
- Un traductor nativo adapta no solo el texto, sino también los ejemplos, los casos prácticos, las unidades de medida, los formatos de fecha y moneda y las referencias culturales. Es caro, pero es el enfoque correcto para las páginas clave: inicio, servicios y sobre nosotros.
- Herramientas CAT y memoria de traducción (TM)
- Para grandes volúmenes de contenido: Phrase (antes Memsource), Lokalise, Crowdin. Guardan las traducciones acordadas de los términos y ahorran hasta un 40 % del tiempo al actualizar contenido. Se integran con la base de código mediante pipelines de CI/CD.
Las palabras clave en los idiomas objetivo hay que investigarlas por separado: una traducción literal de una frase clave a menudo no coincide con lo que buscan de verdad los nativos. Usa Ahrefs o Semrush configurados en el país objetivo, no una herramienta de traducción.
Configuración para SEO: hreflang, sitemap, canonical
La configuración técnica de SEO de un sitio multilingüe consta de varios elementos obligatorios. Si omites cualquiera de ellos, se producen confusiones de indexación y pérdida de tráfico.
hreflang
El atributo hreflang le dice a Google: «Esta es la misma página, pero para otra audiencia lingüística o regional». Se implementa mediante <link rel="alternate" hreflang="en"> en el <head> o a través de un sitemap XML. Es obligatorio en todas las versiones de idioma, incluida x-default (la versión de reserva). Los errores en hreflang son una de las causas más habituales de que se posicione una versión de idioma incorrecta.
Sitemap XML
En un sitio multilingüe, el sitemap debe incluir todas las versiones de idioma de cada página, con sus anotaciones hreflang. En configuraciones multidominio, un sitemap separado por dominio. Google no transfiere automáticamente el conocimiento sobre las páginas entre dominios, aunque los sirva el mismo código.
Etiquetas canonical
Cada versión de idioma es autocanónica: su etiqueta canonical apunta a sí misma, no a la versión de idioma principal. No uses las etiquetas canonical para «fusionar» versiones de idioma: eso le dice a Google que ignore las traducciones. hreflang y canonical son herramientas distintas, con funciones distintas.
Metadatos en el idioma correcto
Title, description, og:title, og:description: todo debe estar en el idioma de la versión de la página. Mezclar idiomas en los metadatos reduce el CTR y confunde al algoritmo. Para cada página de cada locale, metadatos únicos y optimizados.
Qué elegir: subdirectorios o multidominios
Consejo general: empieza por analizar a los competidores en cada región objetivo. Si los cinco primeros de tu nicho en Alemania son ccTLD alemanes (.de), el subdirectorio example.com/de/ funcionará, pero con una desventaja estructural. Si los competidores usan subdirectorios, no tiene sentido invertir recursos en ccTLD.
- Elige subdirectorios cuando
- El negocio es pequeño o mediano y no tiene equipos separados por país. El presupuesto es limitado. Importa la rapidez de lanzamiento. Los competidores de las regiones objetivo también usan subdirectorios. Escala bien: añadir un idioma nuevo significa añadir una carpeta y sus traducciones.
- Elige ccTLD cuando
- Hay una presencia seria en países concretos y un mercado muy competitivo. Los competidores usan ccTLD. Hay equipos o presupuesto separados para mantener cada dominio por su cuenta. La confianza local máxima es importante (finanzas, e-commerce, servicios jurídicos).
- Evita los subdominios
- Los subdominios son lo peor de las tres opciones: la autoridad de enlace no se transfiere igual que desde los subdirectorios, la señal geográfica es más débil que la de un ccTLD y el mantenimiento es más complejo que el de los subdirectorios. Úsalos solo cuando lo exija la arquitectura técnica (por ejemplo, un SaaS con dominios personalizados de clientes).
En la práctica, la mayoría de negocios empiezan con subdirectorios y migran a ccTLD a medida que crecen. Con redirecciones 301 bien configuradas y hreflang, la migración es segura y no se pierden posiciones. Ninguna opción es definitiva: la arquitectura se puede cambiar con un plan técnico de migración adecuado.
Preguntas frecuentes
¿Hace falta hreflang si solo tengo un idioma pero varias regiones?
¿Puede WordPress gestionar varios dominios ccTLD?
¿Cómo configuro un sitio multilingüe en MODX?
¿El idioma del sitio afecta al posicionamiento en un país concreto?
¿Qué complejidad tiene migrar de subdirectorios a ccTLD?
Check it with SpiderHead
Free and local: run the audit on your own machine.
