Usted lanzó una versión en alemán de su sitio. O en francés. Invirtió en traducciones, actualizó la navegación y quizás encargó una revisión del texto.
Seis meses después, el tráfico orgánico desde Alemania no se mueve. Los visitantes franceses siguen siendo un error de redondeo. Al revisar Google Search Console comprueba que sus páginas en alemán no están indexadas. O, peor, están indexadas pero Google muestra su contenido en inglés a los usuarios alemanes.
Este es el modo de fallo silencioso de la mayoría de los sitios multilingües. El panel de control lo muestra todo correcto. Nada funciona en realidad.
Por qué la mayoría de los sitios multilingües no rinden
Los problemas se agrupan en tres categorías: estructura de URL incorrecta, implementación defectuosa de hreflang y calidad de traducción detectada tanto por los motores de búsqueda como por los usuarios.
Fallo técnico 1: traducción automática sin edición
DeepL y Google Translate han avanzado mucho. Aun así, una traducción automática sin editar sigue sonando como tal. Los hablantes nativos lo notan en dos frases. Y los motores de búsqueda miden señales de interacción como la tasa de rebote, el tiempo en página y la profundidad de desplazamiento: un texto de baja calidad perjudica las tres.
Fallo técnico 2: hreflang defectuoso
Hreflang es el atributo HTML que indica a Google qué versión de una página mostrar a cada usuario. También es el elemento SEO con más errores de configuración en sitios multilingües. Etiquetas autorreferentes ausentes, URLs que no coinciden, conjuntos incompletos: cualquiera de estos problemas rompe el sistema completo.
Fallo técnico 3: cambio de idioma renderizado con JavaScript
Algunos sitios detectan el idioma del navegador en JavaScript y cambian el contenido en el lado del cliente. Googlebot con frecuencia solo ve el idioma predeterminado. El contenido en francés queda invisible para los rastreadores franceses de Google. El resultado es un sitio multilingüe que Google indexa como si solo existiera en inglés.
Estructura de URL: la base que no se puede cambiar más adelante
Antes de tocar una sola traducción, hay que decidir cómo se estructurarán las URLs multilingües. Esta decisión es difícil de revertir. Un error aquí exige a futuro una migración completa de redirecciones.
| Estructura | Ejemplo | Indicado para |
|---|---|---|
| Subdirectorio | example.com/de/ | La mayoría de empresas: mejor consolidación SEO, un solo dominio que gestionar |
| Subdominio | de.example.com | Organizaciones grandes con equipos separados por región |
| TLD de país | example.de | Empresas con identidad de marca local fuerte y presupuesto para varios dominios |
| Parámetro de consulta | example.com?lang=de | Evitar: Google lo desaconseja y penaliza el rastreo |
Para la mayoría de las empresas, la estructura de subdirectorio es la opción correcta. La autoridad de dominio se mantiene consolidada. Se gestiona un solo dominio. Hreflang es más sencillo de implementar. Los costes de alojamiento son predecibles.
Optar por TLDs de país (example.de, example.fr) solo tiene sentido cuando la confianza en el mercado local es un factor de conversión crítico, algo habitual en servicios financieros o sanidad, donde los usuarios buscan activamente señales de registro local.
Hreflang: el atributo que lo rompe todo cuando falla
Las etiquetas hreflang le indican a los motores de búsqueda: «esta página en alemán es equivalente a aquella página en inglés». Sin ellas, Google adivina. Y casi siempre adivina mal.
Los cuatro errores de hreflang más frecuentes
- Etiqueta autorreferente ausente: cada página debe referenciarse a sí misma en su propio conjunto hreflang. Omitirla puede llevar a Google a ignorar todo el conjunto.
- URLs que no coinciden: si el hreflang apunta a example.com/de/page/ pero la URL real es example.com/de/page (sin barra final), el enlace está roto.
- Conjuntos incompletos: si la página en inglés referencia una versión en alemán, esa página en alemán también debe referenciar la versión en inglés. Las etiquetas unidireccionales se tratan como errores.
- Códigos de idioma incorrectos: `de` significa alemán en todo el mundo; `de-DE` es alemán para Alemania; `de-AT` es alemán para Austria. Usar el código equivocado puede hacer que los austriacohablantes vean la página dirigida a Alemania.
Una implementación válida de hreflang para un sitio en tres idiomas se ve así: cada página en cada idioma tiene un conjunto completo de etiquetas que apuntan a las tres versiones, incluida ella misma. Eso equivale a tres etiquetas por página por idioma. En 50 páginas en tres idiomas son 450 declaraciones hreflang, y todas deben ser coherentes.
La gestión manual de esto a escala es la fuente de errores. La automatización a nivel de framework es la solución.
Calidad de la traducción: qué mueve la aguja de verdad
No todas las traducciones son iguales. El enfoque adecuado depende del tipo de página, el mercado y el presupuesto disponible.
| Enfoque | Calidad | Coste | Indicado para |
|---|---|---|---|
| Traducción automática pura | Funcional, detectable | Casi nulo | Documentación interna, páginas de archivo con poco tráfico |
| Máquina + edición humana | Buena para la mayoría de contextos | Bajo-medio | Entradas de blog, descripciones de producto, páginas secundarias |
| Traducción profesional | Alta y precisa | Medio-alto | Páginas legales, casos de estudio, páginas de servicio principales |
| Redacción nativa | Máxima calidad, resonancia cultural | Alto | Página de inicio, landing pages, páginas de alta conversión |
El error más frecuente de las empresas es aplicar traducción automática pura de forma uniforme en todo el sitio y preguntarse por qué su página de inicio en alemán no convierte. Una página de inicio es un documento de ventas. Requiere redacción nativa.
Una entrada de blog en posición 8 para una keyword de nicho puede funcionar con traducción automática más edición. La página de servicio principal no puede permitírselo.
Adaptación cultural: lo que las herramientas de traducción no pueden hacer
Una frase puede ser correcta en alemán y aun así no convertir. El registro cultural, el estilo argumentativo y las señales de confianza varían considerablemente entre los mercados europeos.
DACH (Alemania, Austria, Suiza)
Los mercados de habla alemana esperan un registro formal (Sie, no du, salvo que el público objetivo sea una startup con un perfil demográfico muy específico), profundidad técnica y respaldo concreto para cada afirmación. Frases vagas como «la mejor solución» resultan contraproducentes. La privacidad de datos (DSGVO) es a la vez un requisito legal y una señal de confianza: debe mostrarse de forma prominente.
Francia
El público francés espera formalidad y una demostración de pericia antes de otorgar confianza. Los casos de estudio y las credenciales son determinantes. El uso de vous es constante. El tono excesivamente informal se percibe como poco profesional.
España y América Latina
Los mercados hispanohablantes tienden a ser más cálidos y orientados a las relaciones. La confianza se construye tanto por el tono como por las credenciales. Dicho esto, España y América Latina son mercados distintos: el vocabulario, los modismos y las normas de formalidad difieren de forma significativa. Una sola traducción al español no servirá igual para ambos.
Países Bajos
El público neerlandés es notablemente directo y valora la transparencia en los precios. El lenguaje corporativo vacío genera rechazo. Si el texto en neerlandés suena a nota de prensa, tendrá un rendimiento inferior. Conviene ser específico sobre qué cuesta algo y qué se obtiene a cambio. Lo concreto supera a lo abstracto.
Polonia
Los compradores B2B polacos están orientados al valor. Los argumentos de retorno sobre la inversión funcionan bien. El mercado es sensible al precio en comparación con Europa occidental, aunque las señales de calidad importan: el comprador polaco se ha vuelto más exigente a medida que el mercado ha madurado. El contenido en polaco no debe parecer una traducción de último momento.
El problema de WordPress con el multilingüismo
La mayoría de las empresas que intentan implementar multilingüismo en WordPress recurren a WPML o Polylang. Ambos son plugins maduros. Ambos tienen problemas reales a escala.
Coste de rendimiento
WPML añade consultas adicionales a la base de datos en cada carga de página para determinar y servir la versión de idioma correcta. En un sitio con 10.000 entradas en 5 idiomas, esta carga se vuelve medible. Se suma a una arquitectura ya de por sí limitada en rendimiento.
Complejidad en la gestión de traducciones
Gestionar traducciones en WordPress implica mantener jerarquías de entradas paralelas sincronizadas. Al actualizar una página de servicios en inglés hay que marcar manualmente cada versión de idioma para retradución. Si se pasa por alto alguna, hay contenido desactualizado sirviendo tráfico en producción.
Errores de hreflang
WPML y Polylang generan hreflang automáticamente, pero su resultado es tan bueno como la cobertura de traducción disponible. Si falta una traducción al alemán, el conjunto hreflang de cada página en inglés que la referencia queda incompleto. El hreflang generado por plugins exige una cobertura de traducción perfecta.
Riesgo de dependencia del plugin
Toda la infraestructura multilingüe depende de un plugin de terceros que debe mantenerse compatible con el núcleo de WordPress, el tema activo y el resto de plugins instalados. Las actualizaciones de WPML han introducido regresiones en versiones anteriores. Un fallo puede afectar a todas las variantes de idioma simultáneamente, lo que amplifica el impacto de cualquier actualización defectuosa.
El enfoque de Next.js para el multilingüismo
Next.js gestiona la internacionalización a nivel de framework, no de plugin. La diferencia es arquitectónica.
Enrutamiento a nivel de framework
En Next.js, `/de/services` y `/en/services` son rutas de primera clase. El framework las conoce en tiempo de compilación. No hay cambio de idioma en el lado del cliente ni detección en tiempo de ejecución: Google rastrea cada URL como una página completamente independiente con su propio contenido.
Generación automática de hreflang
Con una configuración i18n correcta en Next.js, las etiquetas hreflang se generan a partir de la configuración de rutas. Al añadir un nuevo locale, cada página obtiene automáticamente las etiquetas correctas. Al eliminar un locale, las referencias huérfanas se limpian solas. Sin gestión manual, sin errores silenciosos.
Rendimiento consistente en todos los locales
Añadir versiones en alemán y francés a un sitio en Next.js no genera consultas adicionales a la base de datos, sobrecarga de plugins ni complejidad en PHP. Cada locale es un conjunto de archivos estáticos servidos desde un CDN edge. Un usuario en Múnich recibe habitualmente la página desde un nodo cercano en menos de 100 ms (según cobertura y enrutamiento de CDN), con independencia del número de variantes de idioma.
Contenido estructurado, sin riesgo de plugins
Las traducciones viven en archivos JSON o en un CMS headless. No hay ningún plugin que actualizar, que pueda romperse ni que cueste dinero. Añadir un idioma no requiere cambios en el esquema de la base de datos. El contenido se versiona junto al código.
Lista de verificación previa al lanzamiento para sitios multilingües
Antes de publicar cualquier nueva versión de idioma, conviene revisar esta lista.
- Pruebe con el Google del país objetivo: use una VPN o la herramienta de inspección de URLs de Google Search Console para verificar que se devuelve la versión de idioma correcta para búsquedas desde ese país
- Valide hreflang con una herramienta específica: Screaming Frog o Ahrefs Site Audit detectan etiquetas hreflang mal configuradas o ausentes en todo el conjunto de URLs
- Ejecute PageSpeed en cada locale de forma independiente: una página en alemán con una pila de fuentes más pesada o un conjunto de imágenes diferente puede puntuar de forma distinta al baseline en inglés
- Revisión por hablante nativo antes del lanzamiento: revise erratas, tono, registro y si el texto convertiría realmente a un cliente local
- Adaptación legal e Impressum: los mercados DACH requieren un Impressum en alemán y una política de privacidad conforme al DSGVO. Francia exige avisos legales específicos. Son requisitos legales, no opcionales
- Verifique la detección de idioma en acceso directo por URL: si un usuario navega directamente a /de/services, debe recibir alemán, no una redirección al inglés basada en la configuración de su navegador
Cómo se ve un sitio que realmente funciona
Un sitio multilingüe que funciona tiene posicionamientos orgánicos distintos en cada mercado objetivo. Google Search Console muestra impresiones y clics procedentes de los países correctos en las páginas de idioma correspondientes. Las tasas de rebote son comparables entre locales, sin diferencias significativas en las versiones traducidas. Y cuando un usuario alemán escribe su keyword objetivo en Google.de, encuentra la página en alemán, no la de inglés.
Ese resultado exige definir bien la estructura de URLs desde el inicio, implementar hreflang sin errores, ajustar la calidad de la traducción a la importancia de cada página y usar una pila tecnológica donde todo esto se mantenga de forma automática, no manual.
La mayoría de las empresas no acierta en todas estas dimensiones en el primer intento; la iteración es lo normal. El patrón habitual es: lanzar el sitio traducido, no ver resultados, asumir que el mercado no quiere el producto y abandonar la expansión internacional.
El mercado, en general, sí quiere el producto. El sitio simplemente no estaba construido para llegar a él.
Obtenga un informe gratuito sobre la salud de su sitio
Si su sitio multilingüe no está rindiendo, o planea crear uno y quiere definir la arquitectura correcta antes de construirlo, webvise puede auditar su configuración actual de forma gratuita.
El informe gratuito sobre la salud del sitio incluye implementación de hreflang, estructura de URLs, PageSpeed por locale y señales de calidad de la traducción. El resultado es un desglose específico y accionable de qué falla y qué corregir primero.
Solicite su informe gratuito en webvise.io/wp-health-report. Sin llamada de ventas.