Durante las últimas semanas reconstruimos la web de PolluxData desde cero. El objetivo no era solamente cambiar el diseño: necesitábamos corregir problemas estructurales de SEO, seguridad, mantenimiento y despliegue que venían acumulándose en el sitio anterior.
El resultado es una web estática desarrollada con Astro 7, Tailwind CSS v4 y TypeScript, versionada en GitHub, construida como imagen Docker y desplegada sobre Oracle Kubernetes Engine (OKE).
Este post resume el proceso técnico, las decisiones tomadas y el flujo que dejamos funcionando para seguir actualizando el sitio con menos fricción.
1. La necesidad: salir de un WordPress difícil de mantener
El proyecto original estaba construido sobre WordPress. Durante mucho tiempo cumplió su función, pero con el paso de los años empezó a presentar problemas típicos de un sitio que depende de plugins, temas, redirecciones acumuladas y contenido que ha cambiado muchas veces.
Encontramos varios puntos críticos:
- SEO roto o inconsistente entre páginas.
- Múltiples links rotos hacia contenido inexistente.
- Redirecciones antiguas que ya no aportaban valor.
- Páginas duplicadas o desactualizadas.
- Dependencia de plugins para funciones que podían resolverse de forma estática.
- Superficie de ataque innecesaria para un sitio principalmente informativo.
La web de PolluxData no necesitaba edición dinámica en tiempo real, usuarios internos, comentarios ni funcionalidades transaccionales. Era, principalmente, un sitio nformativo con páginas de servicios, blog, contacto, SEO y analítica. Mantener WordPress para ese caso empezaba a ser más carga que beneficio.
2. El problema de seguridad de WordPress actualmente
WordPress sigue siendo una plataforma muy potente, pero también es uno de los objetivos más atacados de Internet. No porque WordPress sea malo en sí mismo es por su popularidad, el ecosistema de plugins y la cantidad de instalaciones mal mantenidas lo convierten en un blanco permanente.
En un WordPress típico hay varios puntos que deben vigilarse constantemente:
- Plugins instalados.
- Temas activos e inactivos.
- Usuarios administradores.
- Formularios y endpoints públicos.
- XML-RPC, REST API y panel de administración.
- Backups, permisos de archivos y configuración del servidor.
Cada plugin adicional incrementa la superficie de ataque. Incluso cuando todo está actualizado, el modelo operativo requiere disciplina: parches frecuentes, monitoreo, hardening, protección contra fuerza bruta, WAF, backups y revisión de vulnerabilidades.
Para un sitio informativo estático, ese costo operativo no era necesario.
3. Por qué decidimos usar Astro
Astro encajó muy bien con lo que buscábamos: una web rápida, segura, mantenible y fácil de generar con apoyo de IA.
La principal ventaja es que Astro permite producir un sitio estático. El resultado final son archivos HTML, CSS, JavaScript e imágenes servidos por nginx. No hay base de datos en producción, no hay panel de administración público y no hay ejecución server-side para cada request. Además Astro tiene un sitio web de desarrollo embebido puedes mirar los cambios a medida que se los pides a opencode que los haga. Cuando todo esta listo se hace el despliegue.
Esto reduce mucho la superficie de ataque, además nos permite realizar cambios en la página muy rápidamente.
Astro es ideal para un flujo de generación agéntica:
- Las páginas son archivos
.astroo Markdown. - El contenido vive en el repositorio.
- Los cambios son revisables con Git.
- Los modelos de lenguaje pueden ayudar a escribir, refactorizar y validar contenido.
- El build local detecta errores antes de publicar.
- El resultado estático es fácil de versionar, empaquetar y desplegar.
En nuestro caso usamos opencode como entorno de trabajo asistido por IA, junto con modelos open weights como DeepSeek V4 Flash, Qwen 3.6 y Mimo 2.5. Esto nos permitió acelerar tareas repetitivas: limpieza de páginas, reescritura de contenido, ajustes SEO, generación de componentes, revisión de estructura y documentar el despliegue.
4. Flujo del ciclo de desarrollo
El nuevo ciclo de trabajo quedó basado en Git y generación local.
Primero se trabaja el contenido o la página en local. Puede ser un post en Markdown, una página Astro, cambios de estilo en Tailwind o ajustes en el layout global. opencode ayuda a modificar el repositorio, pero el resultado siempre queda como archivos versionados.
Diagrama del flujo de desarrollo:
Abrir diagrama en pantalla completa
La validación local es importante. Antes de hacer push, el sitio debe compilar correctamente. Astro genera el contenido estático en dist/, incluyendo las páginas, posts, metadatos, canonical URLs y sitemap.
Este enfoque cambia la forma de operar el sitio: ya no se edita directamente en producción. Todo cambio pasa por el repositorio, se revisa localmente, se confirma con Git y luego se despliega.
5. Despliegue a OKE
Desplegar una web estática en Kubernetes puede verse como un acto de sobre ingeniería. Un sitio Astro podría publicarse perfectamente en un CDN como Cloudfare o un hosting estático.
En este caso decidimos usar OKE de forma intencional: queríamos mostrar un flujo real de contenedores sobre Oracle Cloud, usando OCIR, Kubernetes, Load Balancer y nginx.
La arquitectura desplegada quedó así:
- Astro genera el sitio estático en
dist/. - Docker construye una imagen multi-stage.
- La primera etapa usa Node.js para compilar el proyecto.
- La segunda etapa usa
nginx:alpinepara servir los archivos estáticos. - La imagen se publica en OCIR.
- OKE ejecuta un Deployment con 2 réplicas.
- Un Service tipo LoadBalancer expone el sitio hacia Internet.
- nginx gestiona redirects HTTP→HTTPS, www→non-www y cacheo de assets.
Diagrama de arquitectura OKE:
Abrir diagrama en pantalla completa
La imagen final no contiene Node.js ni dependencias de desarrollo. Solo nginx y los archivos estáticos generados. Esto reduce tamaño, complejidad y superficie de ataque.
6. Resultados y conclusiones
El cambio principal fue pasar de una web dinámica con mantenimiento constante a un sitio estático, rápido y controlado desde Git.
Los resultados más importantes son:
- Menor superficie de ataque: no hay WordPress, plugins ni base de datos pública.
- Mejor velocidad de carga: el sitio entrega HTML estático desde nginx.
- SEO consistente: canonical URLs, Open Graph, Twitter Cards, sitemap y Schema.org desde el layout global.
- Menos fricción para actualizar contenido: los cambios se hacen como código o Markdown.
- Mejor trazabilidad: cada modificación queda en GitHub.
- Despliegue reproducible: build Docker, push a OCIR y rollout en OKE.
- Uso práctico de IA: los modelos ayudan a acelerar escritura, refactorización y validación sin saltarse el control de versiones.
La combinación de Astro + Git + opencode + modelos open weights nos permitió reducir el tiempo de actualización del sitio. En lugar de pelear con plugins, editores visuales o configuraciones ocultas, trabajamos directamente sobre archivos simples, revisables y compilables.
OKE no era estrictamente necesario para servir una web estática, pero nos permitió demostrar el ciclo completo de entrega en Oracle Cloud: contenedor, registry, Kubernetes, Load Balancer y operación con kubectl.
En resumen: logramos una web más rápida, más segura y más fácil de evolucionar. Y, sobre todo, dejamos un flujo de trabajo que permite que el contenido siga creciendo sin que el mantenimiento técnico se convierta en una barrera.