Traducir un sitio web: qué se traduce y qué se rompe

Por el equipo creativo de Virtalio, una agencia creativa con más de 15 años diseñando sitios, campañas y piezas para pymes, marcas y agencias. Última revisión: noviembre de 2026.

Traducir un sitio web empieza por la estructura, no por el texto. Antes de la primera palabra se decide dónde vive la versión nueva —una carpeta /en/, un subdominio o un dominio propio—, qué cadenas existen fuera del cuerpo de la página (botones, mensajes de error, metadatos, correos) y cómo se declara cada versión para que Google las lea como variantes y no como contenido repetido. Lo que se olvida casi siempre es lo último: el par de etiquetas hreflang que tiene que apuntar en las dos direcciones.

Cuando revisamos sitios que ya tienen dos idiomas, el problema rara vez es la traducción en sí. Es que la versión nueva se armó sobre la española sin tocar la maqueta, sin inventariar los textos y sin cerrar la reciprocidad de las etiquetas. El resultado se ve bien en la página de inicio y se cae en el formulario de contacto.

Primero la URL, después el texto

La versión en otro idioma necesita una dirección y hay tres formas de dársela. La elección no es estética: define cuánta autoridad hereda la versión nueva y cuánto trabajo de mantenimiento exige.

• Subcarpeta (virtalio.com/en/). Es la opción por defecto para una pyme o una agencia que suma un idioma comercial. Comparte dominio y buena parte de la autoridad, se implementa en el mismo proyecto y se mantiene con un solo despliegue. Su desventaja es que el servidor y la analítica tienen que distinguir el idioma a mano.
• Subdominio (en.virtalio.com). Sirve cuando la versión nueva la opera otro equipo o vive en otra infraestructura. Google lo trata como un sitio distinto, así que la autoridad se construye desde cero.
• Dominio por país (virtalio.mx, virtalio.co). Tiene sentido cuando hay operación local, moneda propia y obligaciones legales distintas. Es el más caro de sostener: cada dominio acumula su historial y sus enlaces por separado.

Después viene la decisión de las rutas. Se pueden traducir los slugs (/en/services/landing-page) o conservarlos (/en/servicios/landing-web). Las dos funcionan. Lo que no funciona es cambiarlas seis meses después sin redirecciones: cada cambio de ruta deja enlaces rotos en campañas, correos y perfiles que nadie vuelve a tocar. Si la arquitectura del sitio todavía no está cerrada, el segundo idioma se resuelve al mismo tiempo que la estructura de una página web, no en una fase posterior.

Un detalle que cuesta tráfico: la versión en inglés no debe declarar como canónica a la española. Si todas las versiones apuntan a una sola canónica, Google indexa una y descarta el resto. Cada idioma lleva su propia canónica y se relaciona con las demás por hreflang.

El inventario de cadenas: lo que no está en el cuerpo

El texto visible de los párrafos suele ser el 60% del trabajo. El resto vive en lugares que no se ven al recorrer la página y que aparecen justo cuando el visitante intenta hacer algo.

• Menú, pie de página y migas de pan.
• Botones y enlaces de acción: «Enviar», «Agendar», «Descargar».
• Etiquetas, textos de ayuda y placeholders de los formularios.
• Mensajes de error y de confirmación, incluidos los del servidor.
• Asuntos y cuerpos de los correos transaccionales.
• Metatítulo y metadescripción de cada página.
• Texto alternativo de las imágenes.
• Datos estructurados y nombres de servicios en el marcado.
• Documentos descargables: propuestas, catálogos, fichas en PDF.
• Página 404, aviso de privacidad y términos.

La forma de no perder nada es exportar las cadenas a una hoja con cuatro columnas: clave, texto original, dónde aparece y límite de caracteres. La cuarta columna es la que evita el desastre. Un botón que en español ocupa 18 caracteres y en la traducción ocupa 30 rompe la barra de navegación en móvil, y quien traduce no tiene forma de saberlo si solo recibe el archivo de textos.

Junto con cada bloque conviene enviar una captura de dónde se ve. Sin contexto, «Guardar» se traduce como keep en lugar de save, y «Cerrar sesión» aparece como close session en una interfaz que en el resto dice log out. No es un error de idioma: es un error de encargo.

Lo que se localiza, no se traduce

Hay contenido que no se resuelve con un diccionario porque depende de la jurisdicción y de las costumbres de compra. Si se traduce literal, la página queda correcta y equivocada al mismo tiempo.

• Precios y moneda. Formato de miles y decimales, impuesto incluido o no, y si el cobro se hace en la moneda local.
• Teléfono y WhatsApp. Lada del país, horario de atención y formato de marcación.
• Dirección y horarios. Orden de los datos, días festivos locales, zona horaria.
• Medios de pago. Los que existen en ese mercado, no los que funcionan en el propio.
• Páginas legales. Aviso de privacidad, términos y política de cookies cambian por país. Una traducción automática de un aviso de privacidad es un pasivo, no un ahorro: necesita revisión de alguien con criterio legal en esa jurisdicción.
• Prueba social. Testimonios y casos con nombre y permiso vigentes. Un testimonio de un cliente mexicano traducido al inglés es válido si el cliente autorizó ese uso, no solo la publicación original.
• Referencias culturales. Chistes, modismos, unidades y ejemplos de temporada que no significan lo mismo en otra región.

hreflang: la mitad que casi nadie termina

hreflang es la anotación que le dice a Google que dos direcciones son variantes de la misma página en otro idioma. Tiene tres reglas y las tres se incumplen con frecuencia.

Uno: cada página se incluye a sí misma. La versión en español declara la española y la inglesa; la inglesa declara la inglesa y la española. Si una lista solo menciona a la otra, la anotación queda incompleta.

Dos: los enlaces tienen que ser recíprocos. La documentación de Google lo llama el error más común: si /en/ apunta a /es/ pero /es/ no apunta de vuelta, Google ignora la relación. Es el fallo que más vemos en auditorías, porque se implementa en una plantilla y se corrige en la otra.

Tres: la declaración de idioma va en el HTML de cada versión. El atributo lang del elemento html dice en qué idioma está la página, y el W3C es explícito: no se usa meta con http-equiv="Content-Language" para eso. Si el mercado incluye árabe o hebreo, la página necesita además dir="rtl".

Dos precisiones que ahorran discusiones internas. Google no utiliza hreflang ni el atributo lang para detectar el idioma: usa algoritmos propios sobre el contenido. Y las versiones localizadas solo se consideran duplicadas cuando el contenido principal sigue sin traducir. Es decir, traducir el menú y el pie de una página cuyo cuerpo está en español no crea una versión en inglés: crea una página en español con navegación en inglés.

Cuando existe una versión que debe mostrarse a quien no coincide con ningún idioma declarado, se marca con x-default. Y todas las versiones entran al sitemap; dejar fuera la inglesa es la forma más rápida de que tarde semanas en indexarse.

Dónde se rompe la maqueta

Los textos cambian de largo y la maqueta se diseñó con el largo del español. Una versión traducida se prueba igual que se prueba una landing page que tiene que convertir: por el recorrido del visitante, no por la vista previa del diseñador. Los puntos de ruptura son predecibles:

• Botones y pestañas en una fila de tres o cuatro columnas.
• Encabezados de tabla y celdas con ancho fijo.
• Etiquetas cortas como «Nuevo», «Envío gratis» o «Últimas piezas» dentro de una tarjeta.
• Titulares con tamaño de letra fijo y altura de bloque cerrada.
• Menús con seis o más elementos, que pasan de una línea a dos y empujan el contenido.
• Texto dentro de imágenes: no se traduce, no se adapta y no lo lee un lector de pantalla.

La prueba es concreta: recorrer la versión nueva a 320 píxeles de ancho y al 200% de zoom, con datos reales en los formularios. Ahí aparecen el botón cortado, el mensaje de error que empuja el campo y el selector de fecha que no acepta el formato local. Si el formulario valida un código postal de cinco dígitos, no va a funcionar en un país donde tiene seis.

La revisión antes de publicar

1. Recorrido completo del embudo en la versión nueva, en móvil: inicio, servicio, precio, contacto, gracias.
2. Enlaces internos apuntando a la versión correcta. Es habitual que el logo de /en/ devuelva a la home en español.
3. hreflang recíproco verificado en el HTML servido, no en el borrador de la plantilla.
4. Metadatos traducidos uno por uno; copiar la metadescripción en español es el atajo que arruina el clic.
5. Formularios probados de punta a punta: envío, correo de confirmación y mensajes de error en el idioma de la página.
6. Analítica etiquetada por idioma para poder comparar el comportamiento de cada mercado.
7. Páginas legales revisadas localmente.
8. Redirecciones del sitio anterior, si la versión nueva cambió de rutas.

Cuándo conviene traducir y cuándo no

Traducir tiene sentido cuando hay demanda medida en ese idioma: consultas en Search Console, conversaciones de venta que llegan en inglés o portugués, o un mercado al que la empresa ya le vende por otro canal. Sin esa señal, una versión traducida es un gasto que nadie mantiene y que envejece en silencio mientras la española sigue cambiando.

También conviene empezar por el embudo y no por el blog. Las cinco o diez páginas que sostienen una venta —inicio, servicio principal, precios, contacto y legales— justifican traducción fina y revisión nativa. Cuarenta artículos traducidos con máquina y sin revisión suman páginas que nadie lee y que compiten entre sí.

Si el sitio está por rehacerse, el momento correcto para sumar el segundo idioma es antes de la primera línea de código, cuando la estructura de URLs todavía se puede decidir sin redirecciones. Después cuesta el doble y se hace a medias.

Si la decisión está sobre la mesa, conviene planear las dos versiones con el equipo que diseña y publica el sitio: estructura, textos, formularios y analítica se resuelven en la misma conversación. El orden para reemplazar la versión publicada sin perder lo que ya posicionaba está en cómo subir una página web a internet.

Preguntas frecuentes

¿Basta con un traductor automático?

Para páginas de bajo tráfico y contenido informativo puede servir como primer borrador, siempre con revisión nativa de botones, metadatos y textos legales. Para las páginas del embudo, no: la versión nueva es la primera impresión en ese mercado y los errores de registro se notan antes que los de gramática.

¿Subcarpeta, subdominio o dominio por país?

Para una pyme que suma un idioma comercial, la subcarpeta es la opción más simple y la que menos autoridad pierde. El subdominio y el dominio por país se justifican cuando hay equipo, operación o requisitos legales locales.

¿Necesito hreflang si solo tengo dos idiomas?

Sí. Es la forma de declarar que dos direcciones son la misma página en idiomas distintos, y evita que la versión nueva compita contra la original. Con dos idiomas son cuatro etiquetas: cada página se declara a sí misma y a la otra.

¿Traduzco las URLs?

Se puede traducir el slug o conservarlo, pero conviene elegir una regla y sostenerla. Si el mercado busca en su idioma, la ruta traducida ayuda a que la página se entienda; si se cambia después, cada ruta movida necesita su redirección.

Fuentes

Google Search Central. Tell Google about localized versions of your page. Métodos de hreflang, códigos de idioma y región, y errores comunes de reciprocidad.

W3C, Internationalization. Declaring language in HTML. Uso del atributo lang, atributo dir para texto bidireccional y por qué no se declara el idioma con meta Content-Language.