Web turística en 5 idiomas sin plugins: lo aprendido

Mi web funciona en cinco idiomas —español, inglés, francés, catalán e italiano— sin WordPress, sin plugins de traducción y sin cuota mensual: HTML estático, una URL por idioma y un puñado de reglas aprendidas por el camino, algunas por las malas. Este artículo no es teoría: es la lista de decisiones que volvería a tomar y los errores que te puedes ahorrar si vas a internacionalizar la web de un hotel, una agencia o cualquier negocio turístico.

Por qué el multiidioma "de plugin" se queda corto

La vía habitual —instalar un plugin de traducción en WordPress— resuelve el texto y suele ignorar lo que de verdad posiciona. Las carencias típicas: URLs sin traducir o generadas automáticamente, etiquetas hreflang incompletas o ausentes, sitemap sin las versiones de idioma, y traducción automática publicada sin revisión. El resultado se ve cada semana en webs turísticas: la versión francesa existe, pero Google enseña la española a los franceses, o peor, trata ambas como contenido duplicado.

El multiidioma no es un problema de traducción. Es un problema de arquitectura con una capa de traducción encima.

Las cuatro decisiones que importan (por orden)

1. Una URL propia por idioma, decidida antes de publicar. Cada idioma vive en su subdirectorio (/en/, /fr/, /ca/, /it/) con el idioma principal en la raíz. Nada de selectores que cambian el texto sin cambiar la URL: si dos idiomas comparten URL, para un buscador solo existe uno. Y la decisión es de las que no se revisan: cambiar la estructura de URLs después obliga a redirecciones permanentes, y no todos los alojamientos las permiten — el mío, por ejemplo, no, así que cada slug se decidió sabiendo que era para siempre.

2. Slugs traducidos, no solo textos traducidos. La página de servicios en inglés no debería vivir en /en/servicios/ sino en su forma inglesa. El slug es parte del contenido: los usuarios (y las máquinas) leen la URL. Esto obliga a mantener un mapa de equivalencias entre idiomas — un pequeño coste de orden que se paga una vez.

3. hreflang recíproco y con x-default. Es la parte que más webs hacen mal, y la más mecánica: cada página lista todas sus versiones de idioma, incluida ella misma, más una versión por defecto (x-default) para usuarios que no encajan en ninguna. La regla de oro es la reciprocidad: si la página española dice que existe una versión italiana, la italiana debe decir que existe la española. Un hreflang a medias confunde más que ninguno. Y el sitemap debe contar la misma historia: cada URL con su grupo completo de alternativas.

4. Traducción con revisión humana, priorizando las páginas de dinero. La traducción automática moderna es una primera pasada excelente y barata. Publicarla sin revisar en las páginas donde se juega dinero —tarifas, políticas de cancelación, condiciones— es otra cosa: un matiz mal traducido es una reclamación esperando fecha. Mi orden de revisión: primero condiciones y reserva, después las páginas de venta, al final el contenido editorial.

Lo que me ahorró el enfoque sin plugins

Al servir HTML estático generado por un script propio, las cuatro reglas anteriores no dependen de que un plugin las respete: están en el código que genera cada página, siempre igual, en los cinco idiomas a la vez. Añadir el quinto idioma (italiano) consistió en traducir contenidos y regenerar; el hreflang, el sitemap y las URLs salieron solos. El coste de mantenimiento mensual es cero; el dominio y el servidor se pagan aparte, una vez al año. Y mantener cinco idiomas cuesta exactamente lo mismo que mantener uno. Hay además un efecto colateral que no estaba en el plan: servir HTML estático es justo lo que mejor leen los rastreadores de IA, que no ejecutan JavaScript — lo repaso punto por punto en la checklist de 7 puntos.

No defiendo que todo el mundo abandone WordPress — sería mal consejo. Defiendo el criterio: sea cual sea tu herramienta, exige que cumpla las cuatro decisiones de arriba, y compruébalo tú (las etiquetas hreflang se ven en el código fuente de cualquier página; mirar es gratis).

El error de concepto

Queda el error estratégico, que no es técnico: añadir idiomas que no se pueden mantener. Cada idioma es una promesa — de que las tarifas estarán al día, de que la política de cancelación dirá lo mismo que en español, de que alguien podrá atender la consulta que llegue en ese idioma. Una versión alemana abandonada con precios de hace dos temporadas es peor que no tenerla: genera reservas equivocadas y reclamaciones con razón.

La pregunta correcta antes de añadir un idioma no es "¿me trae tráfico?" sino "¿puedo sostener la promesa?". En mi caso, cinco idiomas son sostenibles porque el sistema regenera todo de golpe y el contenido cambia poco. Para un hotel con tarifas y ofertas semanales, dos idiomas bien mantenidos valen más que cinco a medias. En multiidioma, como en casi todo lo digital, la ambición se mide en años de mantenimiento, no en banderas en el menú.