Modernización de sitios y plataformas
Migraciones de WordPress a Next.js, sitios estáticos en AWS S3 y CloudFront, preservando el SEO y ganando rendimiento.
Contexto
Conjunto de trabajos de modernización de presencia digital: sitios y plataformas que corrían sobre WordPress o stacks heredadas y necesitaban más rendimiento, menos superficie de mantenimiento y un coste de operación predecible.
Desafío
Migrar sin perder lo que ya funcionaba. Un sitio con historial de indexación acumula valor SEO: cambiar la stack y perder las URLs significa tirar ese valor a la basura.
Mi papel
Arquitectura, desarrollo, infraestructura y despliegue.
Responsabilidades
- Arquitectura de la migración y del modelo de contenido.
- Implementación en Next.js con export estático.
- Infraestructura en AWS S3 y CloudFront.
- Pipeline de despliegue.
Restricciones
- Preservación de las URLs y del posicionamiento ya conseguido.
- Contenido multilingüe con metadatos correctos por idioma.
- Presupuesto de operación bajo: la solución debe ser barata de mantener.
Arquitectura
- Export estático: sin servidor de aplicación, sin base de datos en runtime, sin superficie de ataque de CMS.
- Alojamiento en S3 con distribución por CloudFront.
- CloudFront Function en viewer-request reescribiendo URLs limpias sobre los objetos .html del export.
- Metadatos por idioma, con canonical y hreflang.
Principales decisiones técnicas
Sustituir el CMS por un export estático en lugar de mantener WordPress.
Por qué
Para sitios cuyo contenido cambia poco, un CMS en runtime es un coste permanente: servidor, base de datos, plugins y una superficie de seguridad que exige atención continua. Nada de eso se paga solo.
Trade-offs
- Publicar contenido pasa a exigir un build, en vez de un editor en el navegador.
- No sirve para quien publica muchas veces al día ni para redacción no técnica.
- A cambio: coste de operación cercano a cero, sin servidor que mantener y sin vulnerabilidades de plugin.
Resolver las URLs limpias en el borde, con una CloudFront Function.
Por qué
El export estático genera /pagina.html, pero la URL pública debe seguir siendo /pagina, incluidas las ya indexadas. Resolverlo en el borde mantiene el export intacto y no exige servidor.
Trade-offs
- Añade un componente de infraestructura que debe versionarse y desplegarse junto al sitio.
- Un error en la función rompe el sitio entero, no una página. Exige cuidado en el despliegue.
Implementación
- Next.js con App Router y salida estática.
- Contenido multilingüe con diccionarios por locale.
- Despliegue versionado a S3 con invalidación de CloudFront.
- Este mismo sitio es uno de los resultados de ese enfoque.
Operación en producción
- Caché largo e inmutable para assets con hash; HTML revalidable.
- Invalidación de CDN en el despliegue.
- Sin servidor de aplicación que operar o parchear.
Resultados
- Eliminó el servidor de aplicación y la base de datos en runtime de la operación de estos sitios.
- Preservó las URLs y los metadatos durante el cambio de stack.
- Redujo la superficie de mantenimiento y de seguridad al quitar el CMS.
Stack
- Next.js
- React
- TypeScript
- Tailwind CSS
- AWS S3
- AWS CloudFront
- CloudFront Functions
- WordPress (origen)