Cómo creé un sitio web multilingüe con Next.js en 3 días

Una aplicación móvil sin sitio web es como un restaurante sin letrero. Puedes tener la mejor cocina del mundo, pero nadie te encontrará. Cuando me di cuenta de que TAMSIV necesitaba un sitio web de presentación —landing page, precios, preguntas frecuentes, páginas legales— me fijé un objetivo ambicioso: 3 días, ni uno más.

72 horas después, tamsiv.com estaba en línea. Multilingüe (6 idiomas), responsive, con un héroe animado, páginas optimizadas para SEO y una puntuación Lighthouse de 94/100/100. Aquí está el relato completo de este sprint, las elecciones técnicas, las trampas y lo que haría diferente.

Puntos clave a recordar:
- Next.js 16 con App Router es ideal para un sitio web de presentación multilingüe y de alto rendimiento
- La internacionalización con next-intl debe configurarse desde el principio, no añadirse después
- Siempre ejecuta npm run build localmente antes de desplegar en Vercel
- El diseño responsive requiere más iteraciones de lo esperado — reserva el 30% del tiempo total
- Una puntuación Lighthouse de 90+ es alcanzable en 3 días con las decisiones de arquitectura correctas

¿Por qué Next.js en lugar de Gatsby, Astro o un simple HTML?

La elección del framework no es trivial. Consideré varias opciones:

• HTML/CSS estático: Lo más simple, pero inmanejable para 6 idiomas y más de 20 páginas. Cada modificación debe replicarse 6 veces.
• Gatsby: Bueno para sitios estáticos, pero el tiempo de construcción y el ecosistema de plugins envejecido me desanimaron.
• Astro: Excelente para contenido estático, pero sabía que necesitaría componentes interactivos (autenticación, panel de control) más adelante.
• Next.js 16: App Router, React Server Components, renderizado híbrido (estático + dinámico), i18n nativo. Y sobre todo, conozco React — es el mismo ecosistema que el frontend móvil de TAMSIV.

La elección de Next.js también se impuso por una razón práctica: sabía que el sitio evolucionaría más allá de un simple sitio de presentación. El sistema de autenticación con código QR, la aplicación de panel de control, el panel de administración — todo esto requiere un framework capaz de gestionar páginas dinámicas protegidas.

¿Cómo organizar un sprint de 3 días de manera eficiente?

Tres días es poco tiempo. Sin planificación, pasas el primer día configurando tu entorno y llegas al tercero sin contenido. Así es como dividí el sprint:

Día 1: Fundamentos técnicos (10 horas)

El primer día se dedica por completo a la infraestructura técnica. Nada visible para el usuario, pero todo lo demás depende de ello:

• Configuración de Next.js 16 con TypeScript, App Router, Tailwind CSS 4
• Internacionalización con next-intl — 6 idiomas (FR, EN, DE, ES, IT, PT) configurados desde el principio
• Enrutamiento localizado: /fr/fonctionnalites, /en/features, /de/funktionen... cada página tiene una URL traducida
• Diseño base: Encabezado, pie de página, navegación responsive, tema oscuro (#101922)
• Configuración de Vercel: Repositorio Git conectado, despliegues de vista previa automáticos

El enrutamiento localizado me costó 2 horas de configuración solo a mí. Con next-intl, cada ruta debe declararse con sus traducciones de slugs. Es verboso pero da URLs limpias y amigables para SEO en cada idioma.

Día 2: Contenido y diseño (12 horas)

El día más intenso. Aquí es donde el sitio toma forma:

• Héroe animado: Fondo de partículas sobre un fondo oscuro #101922, con un CTA principal. Utilicé una escena 3D de Spline para el visual principal.
• Páginas de contenido: Casos de uso (4 escenarios), características (cuadrícula responsive), precios (3 planes con comparación de características), preguntas frecuentes (acordeón)
• Redacción: Cada página primero en francés, luego traducida. El tono: directo, informal (tú), centrado en los beneficios para el usuario
• Responsive: Aquí es donde pasé la mayor parte del tiempo. Las cuadrículas de características (3 columnas → 2 → 1) requirieron 3 iteraciones. El héroe animado en móvil requirió un fallback estático para el rendimiento.

Día 3: SEO, rendimiento y despliegue (8 horas)

El último día se dedica a todo lo que hace que el sitio sea "profesional":

• SEO técnico: generateMetadata() por página con Open Graph, idiomas alternativos, sitemap XML dinámico
• Análisis: GA4 con Modo de Consentimiento RGPD (sin seguimiento sin consentimiento)
• Páginas legales: Aviso legal, política de privacidad, términos de uso, cookies
• Rendimiento: Optimización de imágenes, lazy loading, precarga de fuentes críticas
• Despliegue en Vercel: Y ahí... la batalla.

¿Por qué falló el primer despliegue de Vercel?

El momento de la verdad. git push, el build de Vercel comienza... y falla. Error de TypeScript. Luego otro. Luego un tercero.

Lo que pasó: en desarrollo local, Next.js es tolerante con ciertos errores de tipo. El build de producción (next build) es estricto. Tipos implícitos any, importaciones faltantes, props opcionales no manejadas — todo eso pasa en desarrollo y falla en producción.

La lección, aprendida a la fuerza: siempre ejecuta npm run build localmente antes de hacer push. Tarda 30 segundos y evita 3 horas de depuración en los logs de Vercel (que son menos legibles que la salida local).

Los errores más comunes que corregí:

• Tipos implícitos: function Component({ data }) → function Component({ data }: { data: DataType })
• Importaciones no utilizadas: El build las trata como errores, no como advertencias
• Variables de entorno: Prefijo NEXT_PUBLIC_ obligatorio para las variables accesibles en el lado del cliente
• Metadatos alternativos: Las URL de cada idioma deben ser absolutas, no relativas

¿Cómo configurar la internacionalización con next-intl desde el principio?

La i18n fue el tema que más tiempo me llevó el día 1. Con next-intl, la configuración inicial requiere rigor:

1. Archivos de mensajes: Un archivo JSON por idioma (messages/fr.json, messages/en.json...). Estructura idéntica, claves idénticas, valores traducidos.
2. Middleware: Detección automática del idioma del navegador, redirección al prefijo correcto (/fr/, /en/).
3. Enrutamiento: Cada página está en una carpeta [locale]. Los slugs se traducen a través de un archivo de mapeo.
4. Componentes: useTranslations('section') para acceder a las traducciones en cada componente.

La trampa clásica: empezar sin i18n y añadirla después. He visto proyectos donde esto costó semanas de refactorización. Al implementarlo desde el día 1, cada componente ya está listo para 6 idiomas. La traducción automática a través de LLM se encarga del resto.

Un punto importante: el contenido HTML del blog se almacena en archivos separados (content/blog/{locale}/{slug}.html), no en los archivos JSON. ¿Por qué? Porque next-intl interpreta las etiquetas HTML como variables ICU y genera errores. Esta separación me ahorró horas de depuración.

¿Cómo obtener una puntuación Lighthouse de 90+ con Next.js?

La puntuación final de Lighthouse: 94 Rendimiento, 100 Accesibilidad, 100 SEO. Estas son las optimizaciones clave:

• Imágenes optimizadas: Componente <Image> de Next.js con sizes y priority para el LCP. Formato WebP automático.
• Fuentes críticas: next/font para Google Fonts con display: swap. Cero cambios de diseño.
• Lazy loading: Todos los componentes por debajo del pliegue se cargan bajo demanda. El héroe animado es el único que se carga inmediatamente.
• CSS atómico: Tailwind CSS 4 genera un CSS mínimo — solo se incluyen las clases utilizadas.
• Generación estática: Todas las páginas de contenido se pre-renderizan en el build. Cero servidor en tiempo de ejecución para el contenido estático.

El punto de rendimiento más crítico fue el héroe animado. La animación de partículas sobre un fondo oscuro era hermosa pero pesada. Tuve que implementar un umbral: en móvil, la animación se reemplaza por un gradiente estático. En escritorio, solo comienza después del LCP (Largest Contentful Paint).

¿Qué páginas son indispensables para un sitio web de presentación de una aplicación móvil?

Para un lanzamiento, no necesitas 50 páginas. Aquí está el mínimo viable que creé en 3 días:

1. Página de inicio: Héroe + casos de uso + características + precios + preguntas frecuentes + CTA. Esto representa el 80% del tráfico.
2. Acerca de: Quién está detrás del proyecto. Para un desarrollador individual, es un activo de credibilidad.
3. Política de privacidad: Obligatoria para Play Store y el RGPD.
4. Términos de servicio: Obligatorios para las suscripciones dentro de la aplicación.
5. Política de cookies: Obligatoria con el consentimiento de cookies RGPD.
6. Blog: Opcional en el lanzamiento, pero puse la estructura en su lugar el día 3. El blog se ha convertido en un canal de adquisición SEO importante.

Cada página existe en 6 idiomas gracias a la i18n. Esto significa más de 30 páginas generadas a partir de 6 plantillas. La relación esfuerzo/impacto de la i18n es enorme — hablo de ello en detalle en mi artículo sobre la i18n como canal de adquisición.

¿Cómo evolucionó el sitio después del sprint inicial?

Los 3 días sentaron las bases. Desde entonces, el sitio ha evolucionado considerablemente:

• Aplicación de panel de control (/app/tasks, /app/memos, /app/agenda): Interfaz web completa para gestionar tareas y notas desde un navegador. Autenticación por código QR o correo electrónico.
• Panel de administración (/admin/dashboard): Métricas de usuario, gráficos de Recharts, alertas. Detallado en el artículo sobre el panel de administración.
• Blog SEO: Más de 40 artículos técnicos optimizados para SEO, con imágenes generadas por IA.
• Hoja de ruta pública: Página de hoja de ruta con funcionalidades entregadas y futuras.
• Guía de usuario: Documentación interactiva para nuevos usuarios.

Todo esto no habría sido posible sin las sólidas bases de los primeros 3 días. El App Router de Next.js, la i18n nativa, el despliegue automático de Vercel — cada pieza colocada al principio facilitó las adiciones posteriores.

¿Qué consejos para un desarrollador individual que lanza su sitio en un sprint?

Si eres un desarrollador individual y quieres lanzar un sitio web de presentación rápidamente, aquí tienes mis 5 recomendaciones:

1. Elige un framework que conozcas: No es el momento de aprender. Usa lo que dominas.
2. Configura la i18n el día 1: Aunque solo traduzcas a un idioma, la estructura ya está en su lugar. Añadir las traducciones más tarde será trivial.
3. Build local antes de cada push: npm run build. Sistemáticamente. Sin excepción.
4. Mobile first para el CSS: Empieza por el móvil, añade los breakpoints de escritorio. Lo contrario siempre cuesta más tiempo.
5. Lanza pronto, itera después: Un sitio imperfecto en línea es mejor que un sitio perfecto que solo existe en localhost. Las correcciones vendrán.

Preguntas frecuentes

¿Cuánto cuesta el alojamiento de un sitio Next.js en Vercel?

El plan gratuito de Vercel es suficiente para la mayoría de los sitios web de presentación. Incluye SSL, CDN global y despliegues de vista previa. Todavía uso el plan gratuito para tamsiv.com, incluso con más de 40 páginas y tráfico regular.

¿Es necesario Tailwind CSS u otro framework CSS?

Tailwind CSS es ideal para un sprint rápido. Codificas el diseño directamente en el JSX, sin necesidad de archivos CSS separados. El inconveniente: el código HTML es verboso. Pero para un desarrollador individual que quiere ir rápido, la sobrecarga de legibilidad se compensa con creces por la velocidad de desarrollo.

¿Cómo gestionar las traducciones sin un traductor profesional?

Utilizo un script de traducción automática a través de OpenRouter (LLM). El script detecta las claves modificadas (solo delta), traduce solo lo que ha cambiado y cuesta aproximadamente 0.05 EUR por pasada. La calidad es muy buena para textos técnicos. Los detalles están en el artículo sobre la i18n en 6 idiomas.

¿Es suficiente el SEO con generateMetadata de Next.js?

generateMetadata() gestiona el título, la descripción, Open Graph y los alternativos (hreflang). Esto es suficiente para el 90% de las necesidades de SEO on-page. Añadí un sitemap dinámico y un robots.txt para el rastreo. El resto (backlinks, contenido, autoridad) depende del blog y del marketing.

¿Se puede hacer el mismo sprint con Astro en lugar de Next.js?

Sí, Astro sería incluso más rápido para un sitio puramente estático. Pero si planeas añadir páginas dinámicas (autenticación, panel de control) más adelante, Next.js sigue siendo la mejor opción. El paso de estático a dinámico es transparente con el App Router.