Arquitectura multilingüe en 2026: cómo Astro 5 y Next.js 15 resuelven (o no) la internacionalización web

En Mintec llevamos operando un sitio bilingüe español/inglés desde antes de que "i18n" fuera una conversación habitual con los clientes. Hemos migrado de WordPress monolingüe a Astro con Content Layer, hemos construido portales multilingües con Next.js para clientes en LatAm y Europa, y hemos visto de primera mano dónde cada framework brilla y dónde tropieza cuando el idioma deja de ser uno y pasa a ser dos, tres o cinco.

Aquí no vas a encontrar una lista genérica de "cómo configurar i18n en tu framework favorito". Esto es lo que aprendimos en proyectos reales, con fechas, decisiones concretas y un framework para que no tengas que aprenderlo en el mismo proyecto de un cliente.

El problema no es "tener i18n" — es qué tipo de multilingüismo necesitas

Existe una confusión persistente en el mercado: "mi sitio necesita estar en varios idiomas" suena a un solo problema, pero en realidad son tres problemas distintos, y elegir el framework equivocado para el problema equivocado es el error más común que vemos en auditorías de proyectos que nos llegan.

1. Sitios con contenido traducido estáticamente. Cada idioma es una copia del sitio con contenido diferente. El blog, las landing pages, la documentación. Las traducciones existen como archivos independientes. Este es el modelo de Mintec, de la mayoría de sitios corporativos bilingües, y de las plataformas de documentación técnica.

2. Sitios con contenido dinámico traducido. El mismo producto, artículo o página existe en múltiples idiomas, pero el contenido se gestiona desde un CMS headless con campos por idioma. El frontend elige qué versión mostrar según el locale del usuario.

3. Sitios con personalización por región. No solo cambia el idioma — cambia el precio, la moneda, las variantes de producto, los testimonios, los casos de éxito. Esto es típico de e-commerce y SaaS con operación en múltiples países.

Cada tipo exige una arquitectura diferente. Y los frameworks no lo resuelven igual.

Cómo cada framework aborda el routing multilingüe

La decisión más fundamental en un sitio multilingüe es cómo estructuras las URLs. Google recomienda tres estrategias: subdirectorios (/es/, /en/), subdominios (es.ejemplo.com), y dominios por país (ejemplo.es). Los frameworks modernos te permiten implementar cualquiera de las tres, pero no con el mismo esfuerzo.

Astro 5: i18n routing nativo

Astro incorporó soporte nativo de i18n routing en su versión 5.0, estabilizado en marzo de 2026. La configuración es declarativa:

# astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  i18n: {
    defaultLocale: "es",
    locales: ["es", "en"],
    routing: {
      prefixDefaultLocale: false,
      strategy: "pathname"
    }
  }
});

Con esto, Astro genera automáticamente las rutas /blog/articulo (es, default sin prefijo) y /en/blog/article (en, con prefijo). A nivel de Content Layer, organizas las colecciones por idioma con src/content/blog/es/ y src/content/blog/en/. Cada colección tiene su propio esquema, sus propios archivos Markdown, y su propio tipado TypeScript.

Lo que nos gusta: el contenido en Astro es archivos. No hay base de datos, no hay llamadas API para obtener la traducción, no hay caché que invalidar. Cada build produce páginas estáticas en cada idioma. El rendimiento es idéntico al de un sitio monolingüe — porque estructuralmente lo es.

Lo que no nos gusta: la gestión de traducciones compartidas (nav, footer, componentes reutilizables) requiere un sistema manual de archivos JSON o YAML. No hay un "key-value store" nativo para textos cortos. Para el pie de página de cinco líneas de Mintec es manejable, pero para un sitio con 80 componentes traducibles, duele.

Next.js 15 + next-intl: el estándar de facto

Next.js tiene soporte de i18n routing desde v10, pero en el App Router la experiencia completa requiere next-intl, la biblioteca más adoptada del ecosistema.

// middleware.ts
import createMiddleware from 'next-intl/middleware';

export default createMiddleware({
  locales: ['es', 'en'],
  defaultLocale: 'es',
  localePrefix: 'as-needed'
});

export const config = {
  matcher: ['/((?!api|_next|_vercel|.*\\..*).*)']
};

next-intl proporciona tipo seguro para las traducciones, detección automática de idioma vía middleware, gestión de rutas localizadas (pathnames diferentes por idioma), y componentes como <NextIntlClientProvider> para i18n en Server Components.

Lo que nos gusta: el sistema de traducciones es robusto y escalable. Los archivos messages/es.json y messages/en.json funcionan como fuente única de verdad para todo el texto de la interfaz, incluyendo componentes dinámicos. El locale detection via middleware es más sofisticado que Astro — considera Accept-Language header, cookies, y rutas.

Lo que no nos gusta: estás atado al runtime de React en todas las páginas. Incluso una página de documentación puramente estática necesita hidratar el runtime de next-intl para mostrar el locale switcher o las traducciones de componentes. Esto suma JavaScript al cliente que en Astro sería cero.

Comparativa de rendimiento: el costo oculto del i18n dinámico

Construimos una prueba de concepto: el mismo sitio bilingüe (6 páginas, blog con 20 entradas, nav traducido, footer, locale switcher) con ambos frameworks. Los resultados confirman lo que sospechábamos:

Los datos están alineados con benchmarks independientes como el Framework Performance Benchmark 2026 de siliconbased.dev, que sitúa a Astro como líder en Core Web Vitals precisamente por su "zero JS by default".

La conclusión no es "Astro es mejor". Es que Astro y Next.js están optimizados para tipos de multilingüismo diferentes, y el framework que elijas determina tu techo de rendimiento.

Nuestro framework de decisión para sitios multilingües

Después de una docena de proyectos, esto es lo que usamos internamente en Mintec para decidir:

Elige Astro 5 cuando:

• El contenido es principalmente archivos (Markdown, MDX, JSON)
• Trabajas con 2-5 idiomas y las traducciones son gestionadas por un equipo editorial
• El rendimiento Core Web Vitals es un requisito contractual o una ventaja competitiva
• El site no necesita autenticación ni contenido personalizado por usuario
• Quieres desplegar en Cloudflare Pages sin coste mensual

Elige Next.js 15 cuando:

• El contenido viene de un CMS headless con campos multilingües (Storyblok, Sanity, Strapi)
• Necesitas 5+ idiomas con gestión de traducciones centralizada
• Hay componentes dinámicos que cambian según el locale (precios, disponibilidad)
• El sitio requiere autenticación, dashboards, o secciones personalizadas
• Tu equipo ya está invertido en el ecosistema React y no quiere mantener dos paradigmas

Para proyectos mixtos (contenido mayormente estático con secciones dinámicas), Astro 5 con Server Islands para las partes interactivas es nuestra recomendación por defecto. La combinación de estático + islas dinámicas cubre el 80% de los casos sin pagar el coste de un framework completo.

Lo que aprendimos migrando el sitio de Mintec

Cuando migramos mintec.co de WordPress a Astro en 2025, la decisión de i18n fue la más debatida internamente. Nuestro sitio tenía (~y tiene) dos versiones: español e inglés. El contenido solapa aproximadamente un 60% — hay artículos que existen solo en un idioma, otros traducidos, y páginas institucionales que deben ser idénticas en ambos.

Probamos Next.js con next-intl durante dos semanas. Funcionaba, pero cada página servida incluía el runtime de React y next-intl aunque fuera puro texto. Para un blog, eso era JavaScript que no necesitábamos. Migramos a Astro con Content Layer y el resultado fue inmediato: mismas páginas, cero JavaScript, Lighthouse 99-100 consistente, y un workflow de contenido donde los archivos Markdown en carpetas /es/ y /en/ son lo suficientemente simples para que los editores los manejen sin ayuda técnica.

La contrapartida: el nav y el footer los gestionamos con archivos JSON de traducción compartidos, y cada vez que añadimos un enlace nuevo tenemos que acordarnos de actualizar ambos archivos. Para un sitio como el nuestro, es aceptable. Para un sitio con 40 páginas y 8 idiomas, recomendaríamos un CMS headless con i18n nativo y Next.js.

Consideraciones de SEO internacional

Más allá del framework, hay prácticas de SEO internacional que aplican independientemente de la tecnología:

Hreflang. Astro lo genera automáticamente si configuras el i18n correctamente. En Next.js necesitas una librería como next-sitemap o generarlo manualmente en el layout.tsx.

Canónicas. Cada versión lingüística debe tener su propia URL canónica. Ambos frameworks lo soportan, pero en Astro es más difícil cometer errores porque las rutas son estáticas y predecibles.

Carga diferida de idiomas. Un error común es servir JavaScript de todos los idiomas a todos los usuarios. Astro evita esto por diseño (cada página es un archivo HTML independiente). Next.js requiere lazy loading explícito de los mensajes por locale.

Tiempo de carga en mercados emergentes. Si tu audiencia principal está en LatAm, donde los dispositivos móviles de gama media dominan, el peso del JavaScript importa el doble. Astro tiene una ventaja estructural aquí que ningún polyfill puede cerrar.

Veredicto (con fechas)

En julio de 2026, la decisión de arquitectura multilingüe se reduce a esto: Astro 5 para sitios donde el contenido es el producto, Next.js 15 para sitios donde la aplicación es el producto. La zona gris del medio — sitios de contenido con secciones dinámicas — se inclina hacia Astro con Server Islands para la mayoría de los casos, especialmente cuando el rendimiento y el coste de hosting son factores determinantes.

Hemos visto equipos elegir Next.js para un blog corporativo bilingüe pagando $240 al año en Vercel y cargando 142 KB de JavaScript por página que nadie pidió. También hemos visto equipos elegir Astro para un portal de clientes con autenticación y arrepentirse tres meses después. El framework no es bueno o malo — es adecuado o inadecuado para el tipo de multilingüismo que realmente necesitas.

Si estás evaluando tu arquitectura multilingüe, empieza por responder tres preguntas: ¿cuántos idiomas?, ¿quién gestiona las traducciones?, ¿cuánto JavaScript está dispuesto a servir tu audiencia? Las respuestas te llevarán al framework correcto más rápido que cualquier benchmark.