- Por qué los subdirectorios son la opción más recomendada en la mayoría de casos
- Estructura de URLs con subdirectorios
- La raíz del dominio: qué hacer con /
- Detección de idioma y redirección: un equilibrio delicado
- Migración de un sitio monoidioma a multiidioma
- Para profundizar
El modelo de subdirectorios organiza las versiones idiomáticas o regionales del sitio como rutas dentro del mismo dominio:
https://www.ejemplo.com/es/ ← versión en español
https://www.ejemplo.com/en/ ← versión en inglés
https://www.ejemplo.com/de/ ← versión en alemán
https://www.ejemplo.com/fr/ ← versión en francés
O con especificidad regional:
https://www.ejemplo.com/es-es/ ← español para España
https://www.ejemplo.com/es-mx/ ← español para México
https://www.ejemplo.com/en-us/ ← inglés para Estados Unidos
Es la opción más habitual en sitios multiidioma de escala media, y la que mejor equilibra señal idiomática, autoridad de dominio compartida y simplicidad operativa.
Por qué los subdirectorios son la opción más recomendada en la mayoría de casos
Autoridad compartida. Todos los subdirectorios comparten la autoridad del dominio raíz. Los enlaces que recibe www.ejemplo.com/es/ contribuyen a la autoridad general del dominio, que beneficia también a www.ejemplo.com/de/ y www.ejemplo.com/fr/. Esto es especialmente valioso cuando el sitio está construyendo su presencia y los recursos son limitados.
Un solo dominio para gestionar. Un único dominio, un único certificado SSL, una única configuración de servidor principal. La complejidad operativa es significativamente menor que con ccTLD o subdominios múltiples.
Implementación más rápida. Añadir un nuevo idioma es añadir un subdirectorio. No hay que registrar dominios, configurar DNS adicionales ni gestionar certificados nuevos.
Coherencia técnica. Toda la infraestructura del sitio es única. Las actualizaciones de servidor, las configuraciones de seguridad y las optimizaciones de rendimiento se aplican una vez para todas las versiones idiomáticas.
Estructura de URLs con subdirectorios
La estructura completa de un sitio multiidioma con subdirectorios replica la jerarquía del sitio en cada versión idiomática:
/ ← raíz (redirige a versión por defecto o muestra selector)
/es/ ← portada en español
/es/fundamentos/ ← sección en español
/es/fundamentos/jerarquia/ ← artículo en español
/en/ ← portada en inglés
/en/fundamentals/ ← sección en inglés (slug traducido)
/en/fundamentals/hierarchy/ ← artículo en inglés (slug traducido)
/de/ ← portada en alemán
/de/grundlagen/ ← sección en alemán (slug traducido)
¿Deben traducirse los slugs? Esta es una decisión con implicaciones prácticas importantes:
Slugs traducidos (/es/fundamentos/, /en/fundamentals/, /de/grundlagen/): más naturales para el usuario, mejor señal idiomática, pero implican una tabla de correspondencias entre las URLs de cada idioma. Necesario para implementar hreflang correctamente.
Slugs en un idioma base (/es/fundamentals/, /de/fundamentals/): más simple de gestionar, las URLs son coherentes entre idiomas, pero menos natural para el usuario y señal idiomática más débil en la ruta.
La práctica habitual es traducir los slugs. El coste de gestión se mitiga con el CMS: herramientas como WPML o Polylang en WordPress gestionan la correspondencia entre URLs de idiomas distintos.
La raíz del dominio: qué hacer con /
Con el modelo de subdirectorios, la raíz del dominio (https://www.ejemplo.com/) debe tener un comportamiento definido. Las opciones son:
Redirección automática por idioma del navegador: El servidor detecta el idioma preferido del navegador (Accept-Language header) y redirige a la versión correspondiente. Es la opción más “inteligente” pero no siempre la más adecuada: el idioma del navegador no siempre coincide con el idioma deseado, y la redirección automática puede confundir a buscadores y usuarios que comparten un enlace.
Página de selección de idioma: La raíz muestra una página que permite al usuario elegir su idioma o región. Es explícita pero añade un paso de fricción. Habitual en sitios con mercados muy distintos donde la elección automática sería demasiado imprecisa.
Versión por defecto en la raíz: La versión en el idioma principal del sitio vive en la raíz y las demás versiones en subdirectorios. www.ejemplo.com/ es la versión en inglés; www.ejemplo.com/es/ es la versión en español. Es la opción más común para sitios con un idioma claramente dominante.
Cada opción tiene implicaciones en cómo se configura el x-default en hreflang.
Detección de idioma y redirección: un equilibrio delicado
Una pregunta frecuente: ¿debe el sitio redirigir automáticamente al usuario a la versión en su idioma?
La respuesta es: con cuidado.
La detección automática puede ser incorrecta. Un usuario hispanohablante con un navegador configurado en inglés por razones laborales no quiere ser redirigido a la versión en inglés. Un usuario en México con navegador en español no necesariamente quiere la versión para España.
Las redirecciones automáticas dificultan el intercambio de enlaces. Si alguien en España comparte un enlace a www.ejemplo.com/en/article/ con alguien en Alemania, la redirección automática puede llevar al receptor a una versión distinta de la que el remitente quería compartir.
La práctica recomendada: Detectar el idioma y mostrar un banner o sugerencia no intrusiva (”¿Prefieres ver este sitio en español?”) en lugar de redirigir automáticamente. El usuario decide.
Si se implementa redirección automática, debe respetarse siempre la elección explícita del usuario: si alguien navega a /en/ estando en España, no debe volver a redirigirse a /es/.
Migración de un sitio monoidioma a multiidioma
Añadir soporte multiidioma a un sitio que ya tiene contenido publicado en un solo idioma es una de las migraciones más delicadas. Los pasos críticos:
1. Decidir la estructura antes de migrar. Cambiar de / a /es/ para el contenido existente requiere redirecciones masivas. Hacerlo bien, hacerlo una sola vez.
2. Redirigir el contenido existente. Si el contenido en español estaba en /articulo/ y pasa a /es/articulo/, todas esas URLs necesitan redirecciones 301.
3. Actualizar el sitemap. El sitemap debe incluir las nuevas URLs con el prefijo idiomático y excluir las antiguas (que ya redirigen).
4. Implementar hreflang desde el primer día. No añadir hreflang “cuando haya tiempo”: debe implementarse en el mismo momento en que se publican las versiones idiomáticas.
5. Comunicar el cambio. Si el sitio tiene tráfico establecido, comunicar el cambio de URLs en los canales relevantes.