Sitio web multilingüe: hreflang, slugs locales, traducción
Cómo hreflang, las URL traducidas y un proceso continuo de traducción hacen que un sitio multilingüe transmita confianza en ambos mercados.
Equipo de rabbitclipPublicación: 6 min. de lectura
En breve
Hreflang es una etiqueta HTML que indica a los buscadores para qué idioma y región está escrita una página; mal configurada, Google puede confundir distintas versiones de idioma de un mismo contenido con duplicados y mostrar una página en el idioma equivocado a un usuario del país equivocado. Construir un sitio multilingüe no es solo traducir el texto; significa planificar juntos la estructura de URL, las etiquetas hreflang y el proceso de traducción continuo.
Para una agencia que trabaja entre Estambul y Londres, esto no es un asunto abstracto; el sitio de un fabricante con versión inglesa y turca puede, sin hreflang, mostrar una página en turco a un comprador en Londres y una página en inglés a un cliente en Estambul.
Este artículo explica qué hace hreflang, cómo debería construirse la estructura de URL, y cómo se gestiona el proceso de traducción.
Qué hace realmente hreflang
Hreflang es una etiqueta en el código fuente de una página que indica para qué idioma, y opcionalmente qué región, está escrita esa página, y que apunta en ambos sentidos hacia las demás versiones de idioma del mismo contenido.
Cuando Google ve que la versión en turco apunta a la versión en inglés y esta apunta de vuelta a la turca, entiende que ambas son versiones de idioma distintas del mismo contenido, no contenido duplicado.
Si esa etiqueta falta, o funciona solo en un sentido (la página en turco apunta a la inglesa pero no al revés), Google se confunde; la página en el idioma equivocado puede acabar mostrada al visitante equivocado, o las dos páginas tratadas como copias entre sí.
Cómo debería construirse la estructura de URL
Existen tres estructuras habituales para un sitio multilingüe: dominios separados (sitio.com.tr, sitio.co.uk), subdominios (tr.sitio.com, en.sitio.com), o subcarpetas (sitio.com/tr/, sitio.com/en/). Según la propia guía de Google, las tres funcionan técnicamente; la elección depende de la preferencia de marca y marketing de la empresa.
Una estructura de subcarpetas suele ser la opción con menos mantenimiento, porque todas las versiones de idioma comparten la autoridad de un único dominio. Los dominios separados encajan cuando se busca una impresión de marca distinta por mercado, pero cada dominio tiene que ganar su propia autoridad SEO por separado.
Si el sitio en inglés de una cadena de spas vive en un dominio separado mientras el sitio en turco vive en una subcarpeta, esa estructura inconsistente crea confusión para los buscadores; la estructura debería fijarse en un solo modelo al inicio del proyecto.
Al tomar esta decisión también conviene pensar si más adelante podría añadirse un tercer idioma; una estructura pensada solo para dos idiomas puede necesitar rehacerse por completo el día que se suma un tercero.
Qué significa un slug local, y por qué importa
Un slug local significa que las palabras en la URL de una página también se traducen a ese idioma; la versión en inglés de una página de 'servicios', por ejemplo, debería estar en '/services', no en el turco '/hizmetlerimiz'.
Dejar la URL sin traducir debilita tanto la experiencia de usuario como el SEO; un visitante británico que ve una palabra en turco en la barra de direcciones tiene la impresión de que el sitio nunca se pensó para él.
Configurar slugs locales añade un paso más al proceso de traducción: no solo el texto de la página, también la URL, el título de página y la meta descripción necesitan pensarse por separado en cada idioma.
Cómo se construye el proceso de actualización de traducciones
El problema más habitual en un sitio multilingüe es que el idioma de origen (aquí normalmente el turco) se actualiza mientras el otro idioma (el inglés) se queda atrás. Si el precio de un producto o una descripción de servicio cambia en la parte en turco y se queda obsoleta en la parte en inglés, un cliente británico lee información desactualizada.
La solución aquí es de proceso, no técnica: una lista de comprobación que avisa del otro idioma cada vez que cambia el contenido, o el módulo de contenido multilingüe de un CMS headless, funcionan ambos.
- Cada actualización de contenido activa una comprobación del otro idioma, como proceso continuo
- La traducción sigue el contexto en lugar de ir palabra por palabra; una traducción literal puede sonar rara
- Las particularidades locales (un método de pago, una referencia legal) se adaptan al mercado de destino en lugar de traducirse literalmente
Qué empresa necesita realmente un sitio multilingüe
Un sitio multilingüe se justifica para una empresa que vende a clientes en más de un país, recibe consultas del extranjero, o trabaja con socios en el exterior. Para una empresa que solo atiende su mercado local, un segundo idioma suele ser mantenimiento innecesario.
La pregunta que lo decide: ¿hay demanda real desde el extranjero, o el segundo idioma solo está ahí para 'parecer más profesional'? En el primer caso, la inversión se paga sola; en el segundo, el mantenimiento continuo se convierte en una carga para la empresa.
Por qué la calidad de la traducción no es solo cuestión de gramática
Una buena traducción va más allá de la corrección gramatical; necesita acercarse a cómo habla realmente el lector de destino en su día a día. Una frase que suena natural en turco puede resultar rígida o extraña traducida palabra por palabra al inglés; eso es un problema del enfoque de traducción, no un error del traductor.
La expresión turca para un pedido al por mayor de un fabricante de ropa laboral se traduce directamente como 'wholesale order', pero añadir junto a ella un término más buscado en el mercado británico, 'bulk order' o 'trade account', encaja mejor con el comportamiento de búsqueda real.
Por eso el proceso de traducción necesita a alguien que conozca el mercado de destino, no solo a un traductor; los dos papeles no tienen que recaer en la misma persona, pero uno debería revisar el trabajo del otro.
Una vez que ajustes pequeños como este se piensan una sola vez y se anotan en una guía de estilo al inicio del proceso, no hace falta volver a discutirlos en cada página nueva después.
Un sitio multilingüe, construido con hreflang correcto, URL traducidas y un proceso regular de actualización de traducciones, transmite confianza en ambos mercados; construido a medias, confunde tanto al buscador como al visitante. En una primera llamada con rabbitclip se revisa juntos la estructura multilingüe actual, cuando existe alguna. Una vez que la estructura está bien planteada, añadir contenido nuevo solo exige esfuerzo de traducción, no una reconstrucción técnica.
Preguntas frecuentes
¿Qué pasa si falta hreflang?
Google puede mostrar la página en el idioma equivocado al visitante equivocado, o tratar las dos versiones de idioma como contenido duplicado.
¿Son mejores las subcarpetas que los dominios separados?
Ambos funcionan técnicamente; las subcarpetas suelen necesitar menos mantenimiento, y los dominios separados encajan cuando se busca una imagen de marca distinta por mercado.
¿Deben traducirse las URL en cada idioma?
Sí, los slugs traducidos refuerzan tanto la confianza del visitante como el SEO.
¿Con qué frecuencia deben actualizarse las traducciones?
Idealmente, cada vez que cambia el contenido en el idioma de origen; es un proceso continuo, no una tarea puntual.
¿Bastan herramientas de traducción automática como Google Translate?
No, la traducción automática puede dar un punto de partida rápido pero se pierde el contexto y el comportamiento de búsqueda local; como mínimo, una persona debe revisarla.
