Web multiidioma: cómo hacerla bien para SEO y conversión

Querés vender en otros países o atender a clientes que hablan inglés, y la pregunta es la misma de siempre: ¿cómo armo el sitio sin romper el SEO que ya tengo? Una web multiidioma se hace bien con tres cosas: una estructura de URLs clara (lo más común y robusto son subcarpetas tipo /es/ y /en/), etiquetas hreflang que le digan a Google qué versión mostrar a cada usuario, y traducción humana nativa en las páginas que venden. La traducción automática masiva y la redirección forzada por IP son los dos errores que más tráfico hacen perder. Acá está cómo armarla paso a paso, qué cuesta de verdad y cuándo no vale la pena.

Lo primero: elegir la estructura de URLs

Antes de traducir una sola palabra, definí cómo van a vivir los idiomas en tu dominio. Esta decisión es difícil de revertir, así que conviene entenderla.

Estructura	Ejemplo	Cuándo conviene	Contras
Subcarpetas	tudominio.com/en/	La mayoría de las PyMEs y startups	Un solo hosting; todo junto
Subdominios	en.tudominio.com	Equipos o servidores separados por idioma	Google los trata casi como sitios distintos
Dominios por país	tudominio.es / tudominio.mx	Empresas grandes con presencia local fuerte	Hay que construir autoridad SEO de cada dominio desde cero
Parámetros URL	tudominio.com?lang=en	Casi nunca	Pésimo para SEO, Google los ignora o duplica

Para el 90% de los casos LATAM, subcarpetas. Toda la autoridad que ya construiste se queda en un solo dominio, el certificado SSL es uno solo y la configuración es directa. Los dominios separados (.es, .mx) solo tienen sentido cuando una marca grande quiere dominar resultados locales y tiene presupuesto para hacer SEO de cada dominio por separado, que es básicamente empezar de cero tres veces.

Evitá los parámetros (?lang=en) a toda costa: ensucian las URLs, confunden a Google y son la receta para que tus dos idiomas compitan entre sí como contenido duplicado.

Hreflang: la pieza que casi todos rompen

Hreflang es una etiqueta que le indica a Google qué versión de una página corresponde a cada idioma y región. Sin ella, pasan dos cosas malas: Google le muestra la versión en inglés a alguien que buscó en español, y tus dos versiones pueden canibalizarse como duplicado.

La implementación correcta tiene tres reglas que se rompen seguido:

1. Bidireccionalidad. Si la página ES apunta a la EN, la EN tiene que apuntar de vuelta a la ES. Si falta un lado, Google ignora todo el conjunto.
2. URLs absolutas. Siempre https://tudominio.com/en/..., nunca rutas relativas.
3. Etiqueta x-default. Apunta a la versión "por defecto" para idiomas que no cubriste. Es lo que evita que un usuario en francés caiga en una página que no entiende.

Un ejemplo mínimo para una página bilingüe español/inglés:

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

El error clásico que vemos en auditorías: el sitio tiene hreflang solo en la home y se olvida del resto. Hreflang es por página. Cada par de URLs equivalentes necesita su propio bloque, y por eso conviene generarlo automáticamente desde el sistema de contenido en vez de a mano. Si tu sitio se construye con un framework moderno como Next.js o se gestiona desde un software a medida, esto se resuelve una sola vez en el código y deja de ser una fuente de errores.

Traducción: dónde se gana o se pierde la conversión

El SEO te trae el tráfico; la traducción decide si convierte. Y acá hay una jerarquía de calidad muy concreta:

• Traducción automática cruda (Google Translate embebido): destruye conversión. Frases raras, género equivocado, modismos que no existen. Además, a escala, Google puede leerla como contenido autogenerado de bajo valor.
• Traducción automática + revisión humana (post-edición): aceptable para volumen, como un blog grande. Una IA hace el primer borrador y un nativo lo corrige.
• Traducción nativa profesional: obligatoria para home, páginas de servicio, precios y formularios. Es donde se decide la venta.

Un detalle que cuesta caro ignorar: traducir no es solo cambiar el idioma, es localizar. Moneda (USD vs ARS vs COP), formato de fecha, teléfonos, ejemplos culturales y hasta los testimonios. Una página de precios en inglés con montos en pesos argentinos genera desconfianza inmediata.

¿No estás seguro de qué arquitectura de idiomas te conviene ni de cuánto traducir? Agendá una reunión de presentación y te decimos en 30 minutos qué estructura encaja con tu caso y tu presupuesto, sin venderte de más.

Cómo armarla paso a paso

Una secuencia que funciona, en orden de prioridad:

1. Definí mercados reales. ¿Quién va a comprar en el otro idioma y por qué? Si no hay demanda comprobada, parás acá.
2. Elegí estructura de URLs. Subcarpetas salvo que tengas un motivo fuerte para otra cosa.
3. Decidí qué se traduce. Empezá por las páginas que generan ingresos, no por todo.
4. Montá la arquitectura técnica: rutas por idioma, selector de idioma visible, hreflang automático, sitemap con todas las versiones.
5. Traducí y localizá lo prioritario con nativos.
6. Configurá analítica por idioma para ver qué versión convierte y dónde.
7. Mantené. Cada cambio de precio o página nueva se hace en los dos idiomas.

El paso 4 es el que más se subestima. Un selector de idioma escondido en el footer pierde la mitad de su valor; tiene que estar arriba y visible. Y si tu web tiene catálogo, carrito o pagos, el multiidioma toca también el ecommerce: precios, impuestos y métodos de pago cambian por país.

Conversión: más allá de traducir las palabras

Tres palancas concretas que mueven la aguja en webs multiidioma:

• Selector de idioma visible, nunca redirección forzada. Mostrá un aviso ("¿Preferís ver esto en inglés?") y dejá elegir. La redirección automática por IP es la causa número uno de páginas en inglés indexadas que nadie pidió.
• Misma calidad de diseño en todos los idiomas. Pasa seguido que la versión en inglés queda con menos secciones, sin testimonios y con un formulario más pobre. El visitante lo nota.
• Soporte y respuesta en el idioma del visitante. Si un cliente escribe en inglés y le contestan en español, la conversión se cae. Acá un chatbot con IA multiidioma resuelve la primera respuesta sin sumar headcount.

Cuándo una web multiidioma NO tiene sentido

No siempre conviene. Casos donde es mejor frenar:

• Tu mercado es 100% local. Una panadería en Córdoba que solo vende en su barrio no necesita inglés. El esfuerzo no se paga nunca.
• No tenés capacidad de atender en el otro idioma. Atraer leads en inglés que después nadie puede responder es peor que no tenerlos.
• Esperás que la traducción automática "arregle" la falta de contenido. Si tu contenido en español ya es flojo, traducirlo solo multiplica el problema.
• Lo hacés "por las dudas". Sin demanda comprobada, terminás manteniendo el doble de páginas sin un solo cliente extra. En ese caso, mejor validar primero con un MVP en un idioma y expandir cuando los números lo justifiquen.

La regla simple: si no podés nombrar quién va a comprar en el segundo idioma y por qué, no es momento.

Cierre

Una web multiidioma bien hecha no es traducir un sitio: es una arquitectura de URLs limpia, hreflang correcto en cada página, traducción nativa donde se juega la venta y la disciplina de mantener todo sincronizado. Hecha así, duplica tu alcance sin canibalizar tu SEO. Hecha mal, te deja páginas duplicadas, leads que no podés atender y un mantenimiento que pesa el doble.

En Deepyze construimos webs multiidioma con la arquitectura técnica resuelta de raíz (hreflang automático, rutas por idioma, analítica separada) para que vos te concentres en vender en cada mercado. Comenzá tu proyecto y armamos juntos la estructura que escala a los idiomas y países que tu negocio realmente necesita.