Sitios Web Multilingües: Lo Que la Mayoría de Empresas Hace Mal Antes de Empezar
Cuando una empresa decide volverse multilingüe, generalmente hace una de dos cosas: mete su contenido existente en Google Translate y publica, o contrata una agencia de traducción, recibe una carpeta de documentos Word y los pega en el CMS uno por uno.
Ambos enfoques ponen el sitio en línea. Ninguno produce un sitio web multilingüe que realmente funcione.
Lo que producen es una capa de traducción sobre una arquitectura que nunca fue diseñada para múltiples idiomas, y esa brecha emerge casi de inmediato, en estructuras de URL rotas, en SEO que se canibalizaba a sí mismo, en selectores de idioma que llevan a los usuarios a la página de inicio en lugar de la página equivalente, y en equipos de contenido que evitan publicar cualquier cosa porque significa tocar doce archivos en lugar de dos.
Hemos reconstruido sitios web multilingües construidos así. El diagnóstico es casi siempre el mismo: la empresa trató la localización como un problema de contenido cuando en realidad fue siempre una decisión de arquitectura.
El malentendido que más cuesta
La mayoría de tomadores de decisiones enmarca volverse multilingüe así: "Tenemos un sitio web. Lo necesitamos en español e inglés. ¿Cuánto tarda la traducción?"
Esta es la pregunta equivocada, y hacerla primero moldea cada decisión que sigue, generalmente hacia el camino de menor resistencia inicial y mayor costo a largo plazo.
La pregunta correcta es: "¿Cómo queremos estructurar las URLs, las relaciones de contenido y el enrutamiento para que cada versión de idioma sea un ciudadano de primera clase del sitio, no un añadido tardío?"
La diferencia importa enormemente en la práctica. Un sitio donde cada versión de idioma tiene su propia estructura de URL limpia (/es/servicios/ no /?lang=es) puede ser indexado por Google como un resultado distinto y relevante para búsquedas en español. Un sitio donde el idioma es un parámetro de consulta o una cookie es, desde la perspectiva de Google, una página con contenido inconsistente. No está construyendo dos audiencias; está confundiendo a una.
Las anotaciones hreflang son el mecanismo que lo une todo a nivel de SEO, le dicen a los motores de búsqueda que /en/services/ y /es/servicios/ son el mismo contenido en diferentes idiomas, y que la versión en español debe posicionarse para usuarios de habla hispana en Colombia o España, no la versión en inglés. Implementarlas incorrectamente (códigos de locale equivocados, etiquetas de auto-referencia faltantes, pares asimétricos) borra efectivamente el valor SEO de la inversión en traducción. Lo vemos en aproximadamente el 60% de los sitios multilingües que llegan a nosotros para auditorías.
Tres patrones de arquitectura, y cuál elegir
Hay tres enfoques estándar para la estructura de URLs multilingüe, y tienen implicaciones significativamente distintas:
Subcarpetas (pixelamos.co/es/, pixelamos.co/en/) mantienen todo bajo un dominio. La autoridad del dominio se consolida. Es la más fácil de configurar correctamente, la más fácil de mantener, y el enfoque que Google recomienda explícitamente para la mayoría de casos. Es lo que usamos en la mayoría de proyectos.
Subdominios (es.pixelamos.co, en.pixelamos.co) ofrecen más aislamiento, útil cuando los equipos regionales que gestionan cada versión son independientes y necesitan entornos de hosting o CMS separados. La desventaja es que Google trata los subdominios más como sitios separados, por lo que la autoridad no fluye entre ellos tan limpiamente. Para la mayoría de empresas, esto es más complejidad de la que vale.
Dominios separados (pixelamos.com.co, pixelamos.co) tienen sentido cuando los mercados objetivo son marcas genuinamente distintas, diferentes productos, diferente posicionamiento, audiencias diferentes que nunca deberían ver el contenido de las otras. Es la más cara de mantener y solo debe elegirse cuando la separación de marca es intencional y permanente.
La decisión debe tomarse antes de que se escriba una sola línea de código. Migrar entre estas estructuras después de que el sitio esté en vivo es disruptivo, requiere planificación de redirecciones y perturba temporalmente los rankings de SEO. Hemos visto empresas gastar más arreglando la migración de lo que habrían gastado construyéndolo bien desde el principio.
Lo que "traducción" realmente significa (y dónde termina)
Cuando definimos el alcance de un proyecto multilingüe, distinguimos entre tres actividades distintas que la gente habitualmente colapsa en una sola palabra:
Traducción es convertir texto de un idioma a otro. Es la parte que es realmente lo mínimo necesario, necesaria pero insuficiente. La traducción automática (DeepL, herramientas basadas en GPT) ha mejorado lo suficiente como para manejar descripciones de productos rutinarias, avisos legales y contenido de ayuda de forma competente. Usarla como un primer pase y luego tener un revisor humano que la limpie es un flujo de trabajo defendible para contenido de alto volumen y bajo riesgo.
Localización es adaptar el contenido al contexto cultural del mercado objetivo. Un comprador B2B colombiano no solo quiere texto en español, quiere copy que refleje cómo se habla de negocios en su mercado. Los precios deben estar en COP cuando corresponda. Las referencias deben ser locales. Las señales de urgencia, los niveles de formalidad e incluso qué puntos de dolor se destacan varían significativamente entre mercados. Un sitio que ha sido traducido pero no localizado tiende a sentirse ligeramente extraño incluso para la audiencia a la que se dirige, y esa fricción cuesta conversiones.
Transcreación es lo que se hace cuando la localización no es suficiente, cuando el concepto mismo no se mapea entre culturas y necesita replantearse, no parafrasearse. Los eslóganes de marketing, las consignas de campaña y el contenido emocionalmente cargado a menudo requieren transcreación. Es la más cara por palabra y la más valiosa para el copy crítico de marca.
Saber qué enfoque aplica a qué parte del sitio es una decisión estratégica, no de traducción. Ayudamos a los clientes a mapear esto antes de que se escriba cualquier contenido, porque hacerlo bien en la etapa de planificación es dramáticamente más barato que corregirlo después de la publicación.
La pregunta del CMS que determina todo lo que viene después
La elección del sistema de gestión de contenido para un sitio multilingüe no es una preferencia técnica, es una decisión con consecuencias acumulativas para el equipo de contenido que vivirá con ella durante años.
Algunas plataformas de CMS manejan el contenido multilingüe como una característica arquitectónica central. Otras lo tratan como un plugin, un complemento o una solución provisional. La diferencia se manifiesta de maneras concretas y cotidianas:
- ¿Puede un editor crear una nueva publicación de blog y que el sistema cree automáticamente un borrador correspondiente en cada idioma, vinculado al original?
- Cuando se actualiza una página en un idioma, ¿el sistema marca las otras versiones de idioma como potencialmente desactualizadas?
- ¿Puede rastrearse el estado de traducción a nivel de campo, para que una página parcialmente traducida no se publique accidentalmente?
- ¿La generación de URL respeta el slug de cada idioma por separado, o simplemente traduce el slug en inglés con un parámetro de consulta?
Un CMS que no maneja estos flujos de trabajo nativamente significa un equipo de contenido construyendo soluciones manuales, hojas de cálculo rastreando el estado de traducción, estructuras de URL copiadas y pegadas, procesos de revisión ad-hoc. Esa sobrecarga se acumula cada vez que se publica contenido.
Las plataformas que hemos encontrado más capaces para proyectos multilingües serios son aquellas construidas con las relaciones de contenido como concepto de primera clase. La herramienta específica importa menos que si fue diseñada para este caso de uso o adaptada para soportarlo.
Rendimiento: la parte que los equipos multilingües olvidan hasta que es demasiado tarde
Agregar múltiples versiones de idioma a un sitio aumenta confiablemente su complejidad de maneras que degradan el rendimiento si no se gestionan explícitamente.
Los culpables más comunes:
La lógica de detección de idioma en el servidor puede agregar latencia significativa si involucra una consulta a la base de datos o un conjunto complejo de reglas de redirección. El enfoque correcto es resolver la preferencia de idioma en el edge del CDN basándose en los encabezados Accept-Language y la estructura de URL, no en el código de la aplicación en cada solicitud.
La carga de fuentes para escrituras no latinas frecuentemente se pasa por alto hasta que el sitio está en QA con el contenido traducido real. Si su diseño usa una tipografía personalizada que no incluye los conjuntos de caracteres necesarios para sus idiomas objetivo, o caerá de forma inconsistente en fuentes del sistema o cargará un archivo de fuente inflado que cubre todos los caracteres posibles. Planifique esto en la fase de diseño.
Las marcas de contenido duplicado por la indexación no intencional de versiones de staging, errores de configuración del sitemap o etiquetas canonical faltantes pueden socavar el beneficio de SEO de toda la inversión multilingüe. Un sitemap multilingüe debe listar explícitamente cada URL de idioma y su relación hreflang. Auditamos esto antes de que cualquier sitio multilingüe salga en vivo.
Cómo se ve "volverse multilingüe" en la práctica
Para concretar esto: cuando un cliente llega a nosotros queriendo expandirse de un sitio de un solo idioma a dos o más idiomas, el trabajo típicamente se divide así.
La primera conversación es sobre mercados, no sobre idiomas. ¿Qué países o regiones está apuntando, y cómo luce realmente un comprador calificado en esos mercados? La respuesta determina si la profundidad de localización es crítica (sí, si es un sitio B2B orientado a ventas; menos, si es un catálogo de productos con tablas de precios).
La segunda conversación es sobre arquitectura, la estructura de URL, la estrategia de enrutamiento y la elección del CMS. Esta es la conversación más larga y la que más clientes quieren saltarse para llegar al "trabajo real." No los dejamos saltársela, porque cada decisión subsiguiente depende de ella.
La tercera etapa es la estrategia de contenido: qué páginas están en alcance para el lanzamiento, cuál es la profundidad de localización para cada una, y quién es responsable del mantenimiento continuo. Un sitio multilingüe no es un proyecto que se termina, es un compromiso editorial continuo. Si no hay un plan para quién actualiza la versión en español cuando cambia el copy de la página de inicio en inglés, el sitio quedará desincronizado en meses.
Luego desarrollo, QA en cada locale, configuración de SEO, pruebas de rendimiento y lanzamiento.
La mayoría de proyectos multilingües serios toman más tiempo del que los clientes esperan, no porque el desarrollo sea especialmente complejo, sino porque las fases de contenido y estrategia están rutinariamente subestimadas. Las empresas que hacen esto bien tratan la conversación de arquitectura como el núcleo del proyecto, no como el preámbulo.
El caso para hacerlo bien desde el principio
Volverse multilingüe es una inversión que se acumula, pero solo si los cimientos son sólidos.
Un sitio multilingüe bien estructurado construye autoridad en cada mercado objetivo de forma independiente. En 12 a 24 meses, una sección en español correctamente configurada con hreflang se posiciona para búsquedas en español, gana enlaces en español y convierte visitantes de habla hispana sin diluir el rendimiento en inglés. Las dos versiones se refuerzan mutuamente en lugar de canibalizarse.
Un sitio multilingüe mal estructurado hace lo contrario: introduce confusión de indexación, fragmenta la autoridad entre URLs duplicadas y crea una carga de mantenimiento de contenido que eventualmente lleva a los equipos a darle menor prioridad a una versión de idioma hasta que queda efectivamente abandonada.
Hemos visto ambos resultados. La diferencia entre ellos no es la calidad de la traducción, es si la decisión de arquitectura se tomó deliberadamente desde el principio.
En Pixelamos, hemos manejado proyectos multilingües para clientes que operan en toda América Latina e internacionalmente, incluyendo navegar los matices específicos del español colombiano para audiencias regionales. Si está planeando expandir su sitio a nuevos mercados y quiere estructurarlo de manera que acumule valor con el tiempo en lugar de crear deuda técnica, hablemos de su proyecto.
