Cómo crear un sitio web multilingüe que realmente funcione

Lanzaste una versión en alemán de tu sitio. O en francés. Invertiste en traducciones, actualizaste la navegación y quizás hasta conseguiste que alguien revisara los textos.

Seis meses después, el tráfico orgánico desde Alemania no se mueve. Abres Google Search Console y descubres que tus páginas en alemán no están indexadas. O peor aún: están indexadas, pero Google muestra tu contenido en inglés a los usuarios alemanes.

Este es el modo de fallo silencioso de la mayoría de los sitios multilingües. Todo parece correcto desde el panel de control. En realidad, nada funciona.

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 de hreflang rota, y calidad de traducción que tanto los motores de búsqueda como los usuarios pueden detectar.

Fallo técnico 1: traducción automática sin edición

DeepL y Google Translate han mejorado mucho. Pero una traducción automática sin revisar sigue leyéndose como una traducción automática sin revisar. Los hablantes nativos lo notan en las dos primeras frases. Más importante aún: los motores de búsqueda miden señales de engagement - tasa de rebote, tiempo en página, profundidad de scroll - y los textos de baja calidad los deterioran todos.

Fallo técnico 2: hreflang roto

El hreflang es el atributo HTML que le dice a Google qué versión de una página mostrar a cada usuario. También es el elemento SEO más frecuentemente mal configurado en sitios multilingües. Etiquetas auto-referenciales ausentes, URLs que no coinciden, conjuntos incompletos: cualquiera de estos errores rompe todo el sistema.

Fallo técnico 3: cambio de idioma renderizado con JavaScript

Algunos sitios detectan el idioma del navegador en JavaScript e intercambian el contenido en el lado del cliente. Googlebot a menudo solo ve el idioma predeterminado. Tu contenido en español es invisible para los rastreadores españoles de Google. Has construido un sitio multilingüe que Google indexa como solo en inglés.

Estructura de URL: el cimiento que no podrás cambiar después

Antes de tocar una sola traducción, debes decidir cómo se estructurarán tus URLs multilingües. Esta decisión es difícil de revertir. Corregirla después requiere una migración completa de redirecciones.

Para la mayoría de las empresas, la estructura de subdirectorio es la elección correcta. La autoridad de dominio se mantiene consolidada. Gestionas un solo dominio. El hreflang es más sencillo de implementar. Los costes de hosting se mantienen predecibles.

Los TLD de país (ejemplo.es, ejemplo.de) solo tienen sentido cuando la confianza en el mercado local es un factor crítico de conversión - habitual en servicios financieros o salud, donde los usuarios buscan activamente señales de registro local.

Hreflang: el atributo que lo rompe todo cuando está mal

Las etiquetas hreflang le dicen a los motores de búsqueda: «esta página en español es el equivalente de esa página en inglés». Sin ellas, Google adivina. Y normalmente adivina mal.

Los cuatro errores de hreflang más comunes

• Etiqueta auto-referencial ausente - cada página debe referenciarse a sí misma en su propio conjunto hreflang. Omitirla puede llevar a que Google ignore todo el conjunto.
• URLs que no coinciden - si tu hreflang apunta a ejemplo.com/es/pagina/ pero la URL real es ejemplo.com/es/pagina (sin barra final), está roto.
• Conjuntos incompletos - si tu página en inglés referencia una versión en español, esa página en español también debe referenciar la versión en inglés. Las etiquetas unidireccionales se tratan como errores.
• Códigos de idioma incorrectos - `es` significa español globalmente. `es-ES` significa español para España específicamente. `es-MX` significa español para México. Usar el código equivocado puede mostrar tu página dirigida a España a usuarios mexicanos.

Una implementación hreflang válida para un sitio en tres idiomas tiene este aspecto: cada página en cada idioma tiene un conjunto completo de etiquetas apuntando a las tres versiones, incluida ella misma. Son tres etiquetas por página por idioma - para 50 páginas en tres idiomas, son 450 declaraciones hreflang. Todas deben ser coherentes.

La gestión manual a escala es la manera en que se producen los errores. La automatización a nivel de framework es la manera de evitarlos.

Calidad de traducción: lo que realmente mueve el marcador

No todas las traducciones son iguales. El enfoque correcto depende del tipo de página, el mercado y tu presupuesto.

El error que cometen la mayoría de las empresas: aplican traducción automática sin editar uniformemente en todo el sitio y después se preguntan por qué su página de inicio en español no convierte. Una página de inicio es un documento de ventas. Necesita redacción nativa.

Un post de blog en posición 8 para una keyword de nicho puede funcionar con máquina más edición. Tu página de servicio principal no puede.

Adaptación cultural: lo que las herramientas de traducción no pueden hacer

La misma frase puede ser correcta en español y aun así no convertir. El registro cultural, el estilo de argumentación y las señales de confianza varían significativamente entre los mercados europeos.

España y América Latina

Los mercados hispanohablantes tienden a ser más cálidos y orientados a la relación. 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 significativamente. Una sola traducción al español no servirá igual de bien a ambos.

DACH (Alemania, Austria, Suiza)

Los mercados de habla alemana esperan registro formal y profundidad técnica. Las afirmaciones vagas como «la mejor solución» son activamente contraproducentes - respalda todo con datos concretos. La protección de datos (DSGVO) es una señal de confianza: muéstrala de forma prominente.

Francia

El público francés espera formalidad y una demostración de experiencia antes de otorgar su confianza. Los casos de estudio y las credenciales cuentan. Evita el copy demasiado informal - parece poco profesional.

Países Bajos

El público neerlandés es notablemente directo y transparente en precios. No les gustan las frases corporativas vacías. Sé específico sobre lo que cuesta algo y lo que obtienes. Lo concreto supera a lo abstracto.

Polonia

Los compradores B2B polacos están orientados al valor. Los argumentos de ROI funcionan bien. El mercado es más sensible al precio que Europa occidental, pero las señales de calidad importan. Evita que tu contenido en polaco parezca una traducción de última hora.

El problema de WordPress con el multilingüe

La mayoría de las empresas que intentan hacer multilingüe en WordPress recurren a WPML o Polylang. Ambos son plugins maduros. Ambos tienen problemas reales a escala.

Sobrecarga de rendimiento

WPML añade consultas a la base de datos adicionales 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 sobrecarga se vuelve medible. Estás agravando una arquitectura ya limitada en rendimiento.

Complejidad en la gestión de traducciones

Gestionar traducciones en WordPress significa mantener sincronizadas jerarquías de entradas paralelas. Actualiza tu página de servicio en inglés y necesitas marcar manualmente y retraducir cada versión de idioma. Olvida una y estarás sirviendo contenido obsoleto a visitantes reales.

Errores de hreflang

WPML y Polylang generan hreflang automáticamente - pero su resultado es tan bueno como tu cobertura de traducción. Si falta una traducción al español, el conjunto hreflang de cada página en inglés que la referencia está incompleto. El hreflang generado por plugin requiere una cobertura de traducción perfecta.

Riesgo de dependencia del plugin

Toda tu infraestructura multilingüe depende de un plugin de terceros que debe mantenerse compatible con WordPress core, tu tema y tus otros plugins. Las actualizaciones de WPML han roto sitios. Cuando falla, todas las versiones de idioma caen simultáneamente.

El enfoque Next.js para el multilingüe

Next.js gestiona la internacionalización a nivel de framework, no a nivel de plugin. La diferencia es arquitectónica.

Enrutamiento a nivel de framework

En Next.js, `/es/servicios` 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 de Next.js correcta, las etiquetas hreflang se generan desde tu configuración de rutas. Añade un nuevo locale y cada página obtiene automáticamente las etiquetas correctas. Elimina un locale y las referencias huérfanas se limpian. Sin gestión manual, sin errores silenciosos.

Rendimiento constante en todos los locales

Añadir versiones en español y francés a un sitio Next.js no añade consultas a la base de datos, sobrecarga de plugins ni complejidad PHP. Cada locale es un conjunto de archivos estáticos servidos desde un edge CDN. Un usuario en Madrid obtiene su página desde un nodo edge en Madrid en menos de 50 ms - independientemente de cuántos idiomas soporte el sitio.

Contenido estructurado - sin riesgo de plugins

El contenido de las traducciones vive en archivos JSON o un CMS headless. No hay plugin que actualizar, que pueda romperse ni que pagar. No hay cambios de esquema de base de datos al añadir un idioma. El contenido está versionado junto con el código.

Lista de verificación pre-lanzamiento para sitios multilingües

Antes de publicar cualquier nueva versión de idioma, repasa esta lista.

• Probar en el Google del país objetivo - usa 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
• Validar hreflang con una herramienta dedicada - Screaming Frog o la auditoría de sitio de Ahrefs detectará etiquetas hreflang mal configuradas o ausentes en todo tu conjunto de URLs
• Medir PageSpeed en cada locale de forma independiente - una página en español con una tipografía más pesada o un conjunto de imágenes diferente puede puntuar distinto que tu baseline en inglés
• Revisión por un hablante nativo antes del lanzamiento - no solo para errores tipográficos, sino para tono, registro y si el copy realmente convertiría a un cliente local
• Localizar páginas legales - España y América Latina tienen requisitos legales específicos. Los mercados DACH necesitan un Impressum en alemán y una política de privacidad conforme al RGPD. Son requisitos legales, no extras opcionales
• Comprobar la detección de idioma en acceso directo por URL - si un usuario navega directamente a /es/servicios, debe recibir español, no una redirección a inglés según la configuración de su navegador

Qué significa realmente "funciona"

Un sitio multilingüe que funciona tiene rankings orgánicos diferentes en cada mercado objetivo. Google Search Console muestra impresiones y clics llegando desde los países correctos en las páginas de idioma correctas. Las tasas de rebote son comparables entre locales - no significativamente más altas en las versiones traducidas. Y cuando un usuario en España escribe tu keyword objetivo en Google.es, encuentra tu página en español, no tu página en inglés.

Ese resultado requiere elegir bien la estructura de URL desde el principio, implementar hreflang sin errores, adecuar la calidad de traducción a la importancia de la página, y usar una stack técnica donde todo esto se mantenga automáticamente en lugar de manualmente.

La mayoría de las empresas no logran nada de esto en su primer intento. El patrón habitual: lanzar el sitio traducido, no ver resultados, asumir que el mercado no quiere el producto, abandonar la expansión internacional.

El mercado normalmente sí quiere el producto. El sitio simplemente no estaba construido para alcanzarlo.

Obtén un informe gratuito de salud de tu sitio web

Si tu sitio multilingüe no está rindiendo - o estás planificando uno y quieres que la arquitectura sea correcta antes de construirlo - auditamos tu configuración actual de forma gratuita.

Nuestro informe gratuito de salud web cubre implementación hreflang, estructura de URL, PageSpeed por locale y señales de calidad de traducción. Obtienes un desglose específico y accionable de qué está roto y qué corregir primero.

Obtén tu informe gratuito en webvise.io/wp-health-report. Sin llamada de ventas requerida.