Cómo crear una web multiidioma: URL, hreflang y localización

Una web multiidioma es un sitio que publica su contenido en varios idiomas, cada uno con su propia dirección. Conviene despejar el término antes de seguir, porque en español arrastra dos sentidos: aquí, localización de páginas web significa adaptar un sitio a otro idioma y a otro mercado. No hablamos de geolocalización, ni de incrustar un mapa con tu dirección, ni de ocultar la ubicación del visitante.

Aclarado eso, la pregunta real rara vez es qué significa la palabra. Es cómo se construye un sitio así sin romper el posicionamiento del que ya existe. Esta guía recorre el camino: cuándo hace falta un segundo idioma, cómo separar las versiones en la URL, qué es el hreflang y por qué falla tanto, qué cambia además del texto y cómo se presupuesta.

Nada de teoría de manual. Varias de estas decisiones ya están tomadas en el sitio que estás leyendo.

Una web multiidioma sirve el mismo contenido en dos o más idiomas y deja que el buscador y el visitante elijan la versión correcta. No es una traducción pegada encima del sitio original: cada idioma vive en su propia URL, declara su código de idioma en el HTML y aparece por separado en el mapa del sitio. Esa separación es la que permite que un buscador indexe cada versión de forma independiente en lugar de tratarlas como una sola página.

Conviene distinguir idioma de región. El idioma se declara con un código de dos letras de la norma ISO 639-1 y la región, cuando hace falta, con un código de país de la ISO 3166-1 Alpha 2. Un sitio en español para España se anota es-ES y uno para México, es-MX. Si tu contenido sirve igual en los dos mercados, no separes por región: multiplicas URL sin ganar nada.

Dos siglas aparecen en cualquier presupuesto técnico. La internacionalización, i18n, es preparar el código para admitir varios idiomas: textos fuera del código, formatos variables, plantillas que aguantan cadenas más largas. La localización, l10n, es lo que se hace después con cada idioma concreto.

Un segundo idioma se justifica cuando ya hay demanda que atender, no cuando suena bien en una reunión. Las señales son medibles: consultas que llegan de un país donde no publicas, tráfico orgánico en un idioma que no cubres, un contrato que exige atención en la lengua local, o un ciclo de venta B2B donde el comité de compra incluye a alguien que no lee inglés.

El argumento comercial está medido. En 2020, CSA Research publicó el informe Can't Read, Won't Buy, una encuesta a 8.709 consumidores de 29 países: el 76 % prefiere comprar productos con la información en su propio idioma y el 40 % no compra nunca en webs escritas en otra lengua. Es un estudio B2C, así que trasládalo con cuidado a un embudo B2B, pero la dirección no admite mucha discusión.

¿Cuándo basta con uno? Cuando vendes en un solo mercado, cuando tu público ya lee inglés sin fricción, o cuando nadie del equipo va a mantener la segunda versión. Ese último caso es el más frecuente y el más caro: un idioma con la mitad de las páginas traducidas y los precios de hace dos años hace más daño que no tenerlo.

Hay tres formas de separar los idiomas en la dirección, y la elección condiciona el SEO durante años: subcarpeta (vezert.com/es/), subdominio (es.vezert.com) o dominio propio por país (vezert.es). Existe una cuarta, el parámetro en la URL, y la documentación de Google la marca como no recomendada. Descártala antes de empezar la discusión.

Según la guía de Google sobre sitios multirregionales, el dominio por país da una señal geográfica clara sea cual sea la ubicación del servidor, pero sale caro y solo apunta a un país. La subcarpeta es fácil de montar y barata de mantener porque todo vive en el mismo host, a cambio de un único servidor y de una separación menos limpia. El subdominio queda en medio.

El hreflang es una anotación que le dice al buscador qué otras versiones idiomáticas existen de una página y a quién sirve cada una. No mejora el posicionamiento por sí solo: hace que quien busca en francés reciba la versión francesa y no la inglesa. Según la documentación de Google sobre versiones localizadas, hay tres formas de declararlo: etiquetas en el HTML, cabeceras HTTP o entradas en el sitemap.

Las reglas son pocas y estrictas. Cada versión debe listarse a sí misma y a todas las demás. Si dos páginas no se apuntan mutuamente, las etiquetas se ignoran, así que los enlaces de vuelta no son opcionales. El valor reservado x-default cubre a quien no encaja en ninguna versión disponible.

La propia documentación enumera los tres fallos habituales: enlaces de vuelta ausentes, códigos de idioma incorrectos y códigos de región incorrectos. En la práctica se suman dos más. Uno, generar el hreflang comparando URL: en cuanto un idioma traduce su slug, la correspondencia se rompe. Dos, olvidar x-default.

Por eso aquí el hreflang no se apoya en la dirección. Cada artículo lleva un identificador estable compartido por las cinco versiones locales, y las etiquetas salen de él. Esta guía vive en /es/blog/web-multiidioma y su versión inglesa en /blog/multilingual-website: no se parecen en nada y aun así quedan enlazadas.

Traducir es cambiar las palabras. Localizar es cambiar todo lo que depende del mercado: formatos de fecha y de moneda, campos de formulario, ejemplos, imágenes con texto incrustado, páginas legales, el tratamiento de tú o de usted y el espacio que ocupa el texto en pantalla. Un botón que cabe en inglés se desborda en alemán, y ese detalle se descubre casi siempre en producción.

Lo de las palabras clave merece párrafo propio, porque es donde más dinero se pierde. Traducir la palabra clave inglesa produce una expresión correcta que nadie busca. Hay que investigar la demanda idioma por idioma: un tema con volumen alto en inglés puede quedarse en un puñado de búsquedas al mes en español.

En nuestro caso eso se ve en los slugs. El artículo sobre presupuesto vive en /es/blog/presupuesto-pagina-web y su hermano francés en /fr/blog/prix-site-internet. No son traducciones el uno del otro, son las expresiones que la gente escribe en cada idioma.

Una URL localizada traduce también el camino, no solo el contenido: /es/precios en lugar de /es/pricing. Google acepta el uso de palabras localizadas en la dirección y recuerda cuidar la codificación UTF-8. La ganancia es doble: el visitante entiende dónde está antes de hacer clic, y la dirección coincide con las palabras que la gente escribe en el buscador.

El coste aparece después. Cada cambio de slug obliga a dejar una redirección permanente desde la dirección antigua, y se acumulan. En este sitio ya pasan de 320, generadas al renombrar slugs mientras las cinco versiones se afinaban. Viven en un único archivo, pero no son gratis: cada una es una decisión que alguien tendrá que entender dentro de dos años.

¿Merece la pena? Si el sitio es pequeño y estable, sí, sin discusión. Si publicas decenas de páginas al mes, calcula el mantenimiento antes de comprometerte. Una estructura pensada desde el principio ahorra casi todo ese trabajo, y se decide durante la planificación de la estructura web, antes de la primera maqueta.

La pregunta llega en todos los proyectos: ¿penaliza Google publicar el mismo contenido en cinco idiomas? No. Un texto traducido no es contenido duplicado, porque está escrito en otra lengua y sirve a otro público. El problema real aparece dentro de un mismo idioma, cuando existen dos versiones parecidas para dos países, por ejemplo español de España y español de México.

Para ese caso concreto, la documentación de Google recomienda elegir una versión preferida, marcarla con rel="canonical" y acompañarla del hreflang correspondiente. Con eso el buscador entiende cuál indexar y a quién servir cada una.

La canibalización de verdad suele ser interna: dos páginas del mismo idioma compitiendo por la misma consulta. Se resuelve con arquitectura, no con hreflang, y lo tratamos a fondo en el artículo sobre cómo la arquitectura web impacta en la visibilidad SEO.

Un aviso que rara vez se da: la demanda no se reparte igual entre idiomas. Copiar el plan de contenidos inglés a los otros cuatro produce páginas correctas que nadie busca. Vale más publicar seis artículos con demanda medida que treinta traducidos a ciegas.

El presupuesto arranca en el tipo de proyecto. En nuestra página de precios, una landing page parte de €1.500, un sitio corporativo de €5.000 y un portal web de €9.000, con plazos de 2 a 5 días, de 2 a 4 semanas y de 6 a 12 semanas. Esa cifra cubre un idioma, y es el punto de partida de cualquier conversación seria.

Lo que añade cada idioma no es solo la traducción. Hay que multiplicar las páginas por los idiomas, adaptar plantillas que se desbordan, revisar formularios y páginas legales, montar el hreflang y probar cada versión. Nadie puede darte un multiplicador honesto sin ver antes el número de páginas.

El mantenimiento sí es previsible. Nuestros planes van de €500 al mes en Essentials a €2.500 en Growth y €5.000 en Scale, y con varios idiomas el trabajo recurrente crece casi en línea recta: cada cambio de precio, cada página nueva y cada aviso legal se replica tantas veces como versiones tengas. Es la partida que más se subestima. Si necesitas el desglose entre diseño, desarrollo y contenido, está en la guía sobre el presupuesto de una página web.

Los proyectos multiidioma rara vez fracasan por la traducción. Fracasan por decisiones técnicas tomadas deprisa al principio y por la falta de un responsable para cada idioma cuando el sitio ya está vivo. Estos nueve errores se repiten en casi todas las auditorías, y ocho de ellos cuestan más de arreglar después que de evitar antes.

1. Redirigir automáticamente por el idioma del navegador. Google lo desaconseja de forma expresa, porque puede impedir que los rastreadores lleguen a todas las variantes. Ofrece un selector, no una imposición.

2. Usar banderas como selector de idioma. Una bandera representa un país, no una lengua. Es el mismo error de fondo que confundir localización con geolocalización.

3. Publicar traducción automática sin revisión. Sirve para un borrador interno. No para una página que tiene que vender.

4. Traducir solo la portada. El visitante entra por un artículo o por una página de servicio, casi nunca por la raíz.

5. Olvidar formularios, correos automáticos y páginas de error. Son las partes que nadie revisa y las que más desconfianza generan.

6. Montar el hreflang sin enlaces de vuelta. Sin reciprocidad, las etiquetas se ignoran y el trabajo se pierde entero.

7. Dejar el texto dentro de las imágenes. Cada archivo con texto incrustado hay que rehacerlo idioma por idioma.

8. Traducir las palabras clave en lugar de investigarlas. Produce páginas impecables que nadie busca.

9. No asignar un responsable por idioma. Sin dueño, la versión se congela en la fecha del lanzamiento.

Si solo te llevas una idea: decide la estructura de URL y el mecanismo de hreflang antes de encargar la primera traducción. Lo demás se corrige sobre la marcha, eso no.