La primavera pasada un cliente me entregó un brief que me habría hecho gruñir en 2022. Cinco idiomas. Once mercados. Un desarrollador. "Ya tenemos WPML configurado", dijo, con el tipo de confianza que te dice que nunca había mirado realmente sus puntuaciones de Lighthouse.
Eliminé la instalación de WordPress el segundo día. Reconstruí todo en Astro. Ocho semanas después, tres de esos locales estaban en la primera página de Google. El cuarto llegó dentro del mes. Esa experiencia básicamente terminó mi relación con WordPress para trabajo multilingüe.
Bien. Aquí está exactamente lo que hago ahora.
Por qué WordPress Multilingüe sigue fallando en rendimiento
Mira, no disfruto criticando WordPress. Seahawk ha construido cientos de sitios WP y probablemente construiremos cientos más. Pero la brecha de rendimiento en proyectos multilingües es genuinamente difícil de defender.
WPML y Polylang funcionan generando posts traducidos en la capa de base de datos y enrutando a través de PHP. Cada solicitud golpea el servidor. Incluso con caché de página completa (WP Rocket, W3TC, lo que prefieras), todavía estás lidiando con la sobrecarga de inicialización de PHP, fallos de caché en páginas de locale con bajo tráfico, y gestión de hreflang que se convierte en una pesadilla en el momento en que tienes más de dos idiomas.
Medí el sitio WP de cinco idiomas de un cliente en 1.3 segundos de Time to First Byte en la locale italiana. El mismo contenido, reconstruido en Astro como HTML completamente estático: 94ms. Eso no es una mejora marginal. Eso es una categoría diferente de producto.
Core Web Vitals son un factor de ranking confirmado, y los archivos estáticos servidos desde un nodo edge de CDN simplemente ganan esa batalla cada vez.
Enrutamiento i18n Integrado en Astro (Y Por Qué Cambió Todo)
Astro lanzó enrutamiento i18n adecuado en v3 y lo refinó significativamente en v4. Para cuando estemos operando en 2026, la API es estable y genuinamente agradable de usar.
Aquí está la configuración básica que uso. Tu astro.config.mjs obtiene un bloque i18n:
`` i18n: { defaultLocale: 'en', locales: ['en', 'de', 'fr', 'it', 'es'], routing: { prefixDefaultLocale: false } } ``
Esa única configuración le dice a Astro que sirva inglés en /, alemán en /de/, francés en /fr/, y así sucesivamente. Sin plugin. Sin paquete extra. Está integrado.
El prefixDefaultLocale: false es deliberado. La audiencia principal de la mayoría de mis clientes habla inglés, así que no quiero que /en/ contamine la estructura canónica. Google puede entender la relación a través de hreflang.
La Estructura de Archivos Que Realmente Escala
Aquí es donde la mayoría de los tutoriales se equivocan. Te muestran un pages/[locale]/index.astro plano y dicen que listo. Bien para un sitio de presentación. Se desmorona en el momento en que tienes 40 rutas.
Lo que yo hago en su lugar:
`` src/ pages/ index.astro (English) about.astro (English) [locale]/ index.astro about.astro i18n/ en.json de.json fr.json it.json es.json ``
El directorio i18n/ contiene tus cadenas de traducción como archivos JSON planos. en.json es la fuente de verdad. Escribo todas las otras locales contra ella. ¿Falta una clave en de.json? La página en alemán vuelve al inglés para esa cadena en lugar de lanzar un error, porque agrego una pequeña función utilitaria t() que maneja el fallback con elegancia.
La Capa de Traducción: Mantenla Simple
He probado Paraglide JS, i18next y otros cuantos. Para construcciones estáticas de Astro mi recomendación honesta es: no sobre-ingenierices esto.
Un archivo utilitario simple que importe JSON de locales y retorne una función getter es suficiente para el 90% de los proyectos. Paraglide JS de Inlang vale la pena considerar si necesitas traducciones type-safe y tu equipo es lo suficientemente grande como para preocuparse por errores en tiempo de compilación en claves faltantes. Para trabajo en solitario o agencias pequeñas, es overhead que no necesitas.
Lo que sí me importa: mantener los archivos de traducción planos en lugar de profundamente anidados. "hero.cta.button.label" como clave suena organizado hasta que la buscas a las 11 de la noche. "heroCTALabel" es feo pero encontrable.
Manejando Plurales y Cadenas Dinámicas
La pluralización en alemán te pondrá a prueba. Lo mismo ocurre con árabe si vas por ahí (una vez ayudé a un cliente a expandirse a los EAU y pasé una tarde completa solo en formato de números).
Para plurales uso un pequeño helper en línea:
`` export function plural(count, one, other) { return count === 1 ? one : other; } ``
¿Crudo? Sí. Pero cubre el 95% de los casos para idiomas europeos. Si te vas a Arabic, Russian, o Polish, necesitas reglas CLDR de plurales adecuadas. El proyecto Unicode CLDR las documenta exhaustivamente. Construye tu helper de plurales contra esas especificaciones o te equivocarás.
hreflang: La Parte Que Todos Interpretan Mal
Correcto. Aquí es donde el SEO multilingüe realmente prospera o se desmorona.
hreflang le dice a Google cuál versión de una página servir a cuál locale. Si te equivocas, terminas canibalizando tus propios rankings o sirves la versión en alemán a hablantes de francés. He visto ambas cosas suceder en sitios que heredé.
Las reglas:
- Cada página debe incluir etiquetas hreflang para cada locale, incluida ella misma.
- Las etiquetas deben ser bidireccionales. Si
/de/aboutreferencia /fr/about, entonces/fr/aboutdebe referenciar/de/aboutde vuelta. - Incluye una etiqueta
x-defaultque apunte a tu locale predeterminado. - Usa URLs absolutas. Siempre.
En Astro genero estas dentro de un componente BaseLayout.astro que cada página importa. Paso la ruta actual, recorro el array de locales, y genero automáticamente las etiquetas <link rel="alternate">. Sin mantenimiento manual.
Perder la etiqueta x-default es el error más común que veo. La documentación de hreflang de Google es genuinamente clara al respecto. Léela una sola vez correctamente.
Sitemaps específicos por idioma
Un sitemap con todos los idiomas mezclados funciona. Pero sitemaps separados por idioma (enviados individualmente en Google Search Console) te dan datos de indexación más limpios y hacen mucho más fácil detectar errores de rastreo en un idioma específico.
Mi compilación de Astro genera cinco archivos: sitemap-en.xml, sitemap-de.xml, y así sucesivamente. @astrojs/sitemap soporta esto con la opción i18n lista para usar. Úsalo.
Estrategia de contenido para sitios estáticos multilingües
Esto es lo que la mayoría de desarrolladores omiten completamente: la traducción misma.
Puedes tener una configuración de Astro técnicamente perfecta con hreflang impecable y un sitemap que haría llorar de alegría a un empleado de Google. Si tu copia en alemán pasó por DeepL y nunca fue revisada por un humano, el sitio no tendrá buen ranking en Alemania.
No estoy siendo remilgado con esto. Uso DeepL constantemente. Es un borrador inicial excelente. Pero para cualquier página en la que realmente quieras rankear, un hablante nativo necesita leerla. No necesariamente reescribirla. Solo leerla, arreglar las partes raras, y confirmar que la redacción suena como algo que un alemán realmente diría.
Seahawk tuvo un proyecto fintech el año pasado donde el cliente quería siete idiomas y una línea de tiempo de cuatro semanas. Usamos DeepL como base, luego contratamos siete freelancers a través de Gengo para pasadas de revisión a aproximadamente £0.04 por palabra. El presupuesto total de traducción fue menor a £800. Ese sitio ahora ocupa el top cinco en cuatro de esos mercados. La economía funciona.
Metadatos Específicos por Locale
Los title tags y meta descriptions también necesitan localizarse. No solo traducirse. "Best accounting software" no se mapea directamente en búsquedas al equivalente en alemán porque los volúmenes de palabras clave difieren.
Guardo los metadatos específicos por locale en los archivos de traducción JSON bajo un namespace meta dedicado. La plantilla de página extrae de t('meta.title') y vuelve a un valor por defecto solo si la clave falta. Esto significa que un SEO puede editar un archivo JSON por locale sin nunca tocar el código.
Deployment: Dónde Alojar un Sitio Estático de 5 Idiomas
Vercel y Netlify manejan bien las compilaciones estáticas de Astro. Pero para multilingüe específicamente, quieres edge caching por locale y la capacidad de establecer headers específicos por locale.
He estandarizado en Cloudflare Pages. El nivel gratuito maneja la mayoría de presupuestos de clientes. Las solicitudes se sirven desde el nodo edge más cercano globalmente, lo cual importa enormemente cuando tu audiencia italiana está siendo servida desde un centro de datos en Virginia. La red de Cloudflare tiene nodos en Milán, Fráncfort, Ámsterdam. La diferencia en TTFB para visitantes europeos es medible.
Una cosa a configurar explícitamente: headers Cache-Control. Los archivos estáticos deben tener TTLs de caché largos (max-age=31536000, immutable para assets hasheados). Las páginas HTML deben tener TTLs más cortos o una política stale-while-revalidate, particularmente si estás haciendo compilaciones incrementales después de actualizaciones de contenido.
Debugging de Compilaciones i18n Antes de que Vayan en Vivo
Algunas cosas que verifico en cada compilación de Astro multilingüe antes de hacer push a producción:
- Ejecuta
astro buildlocalmente e inspecciona el output deldist/. Cada carpeta de locale debe contener todas las páginas. Si falta una ruta, el paso de build es el lugar para detectarlo. - Usa Screaming Frog para rastrear el deployment de preview. Filtra por hreflang. Cualquier página huérfana (páginas no referenciadas por ninguna etiqueta hreflang) se muestra inmediatamente.
- Verifica el canonical
x-defaulten DevTools del navegador al menos en la página de inicio y una página interna. - Visita manualmente una URL de locale en un navegador configurado en el idioma de ese locale. Parece obvio. Aun así detecta problemas.
El problema de build-time más común que encuentro es olvidar agregar un nuevo locale al array de locales en astro.config.mjs después de agregar el archivo JSON. El build no genera error. Simplemente ignora silenciosamente el nuevo locale. Molesto.
FAQ
¿El i18n de Astro funciona con renderizado del lado del servidor (SSR) o solo con output estático?
Ambos. El enrutamiento i18n de Astro funciona también en modo SSR. Las funciones auxiliares getRelativeLocaleUrl() y getAbsoluteLocaleUrl() funcionan de forma idéntica independientemente del modo de output. Dicho esto, si vas completamente estático, los beneficios de rendimiento son significativamente mayores porque estás sirviendo HTML pre-construido sin costo de runtime.
¿Cómo manejo la detección de locale y redirecciones para visitantes nuevos?
Para sitios estáticos hago esto en la capa de CDN/edge, no dentro de Astro. Cloudflare Workers puede leer el header Accept-Language y redirigir a la ruta de locale apropiada. No hagas esto dentro de tu app de Astro porque agrega un round trip y hace que el output estático sea no-determinístico.
¿Cuál es la mejor manera de gestionar archivos de traducción a medida que el sitio crece?
Mantenlos en control de versiones junto al código, no en un CMS separado ni en un sistema de gestión de traducciones de terceros, hasta que el proyecto realmente lo justifique. En el momento en que tengas más de tres idiomas y un equipo editorial activo, evalúa Tolgee o Localazy. Ambos se integran con archivos JSON planos y tienen sincronización con GitHub. Por debajo de ese umbral, un documento Notion compartido y actualizaciones JSON manuales funcionan perfectamente.
¿Puedo usar Astro Content Collections con i18n?
Sí, y es mi enfoque preferido para sitios con muchos blogs. Estructura tu colección de contenido con el idioma como segmento de ruta: src/content/blog/en/, src/content/blog/de/. Luego filtra por idioma en tu función getStaticPaths(). Cada idioma obtiene su propio HTML estático en tiempo de compilación. Limpio, rápido, y el equipo editorial puede gestionar archivos markdown sin tocar ningún componente.
¿Tener múltiples páginas de idiomas afecta el SEO por contenido duplicado?
No, siempre que tu implementación de hreflang sea correcta. Google trata las variantes de idioma correctamente anotadas como páginas relacionadas pero distintas, no como duplicados. El riesgo viene de implementar hreflang incorrectamente, particularmente omitir anotaciones recíprocas o manejar incorrectamente x-default. Domina esos dos puntos y el contenido duplicado no es una preocupación.
---
El cambio de sitios multilingües renderizados dinámicamente en PHP a sitios estáticos precompilados no se trata realmente de Astro en específico. Se trata de aceptar que la mayoría del contenido traducido no cambia de hora en hora. Compílalo una vez, cachéalo en todas partes, deja que la CDN haga el trabajo pesado. Astro simplemente hace que ese flujo de trabajo sea genuinamente agradable en lugar de una batalla contra el framework.
Cinco idiomas, un desarrollador, ocho semanas. Las herramientas están ahí. Úsalas.