Static Publisher para WordPress
Mantén WordPress para editar. Mueve la entrega pública a AWS.
Renderiza el frontend WordPress aprobado, desplíegalo en Amazon S3 y CloudFront y mantén las capacidades dinámicas en rutas explícitas de navegador o servicios AWS, en lugar de exponer el CMS para cada petición de página pública.
De WordPress al edge
Un pipeline de publicación, no solo un archivo exportado
WordPress sigue siendo la fuente y control plane. Un publishing engine externo gestiona renderizado, asset discovery, reescritura de URLs, deployment y refresh de caché.
Límite de runtime
Static Publisher genera la capa de páginas. Login, forms, AI, rutas protegidas y APIs de aplicación permanecen como servicios separados cuando el sitio los necesita.
Por qué Static Publisher
Separa el sistema editorial de la ruta de entrega pública
Un sitio production estático necesita un mecanismo de release repetible y una respuesta clara a qué permanece en WordPress y qué se ejecuta fuera.
01
Publicación render-aware
Captura el frontend como lo usa el navegador, incluidos los assets responsive y solicitados dinámicamente que necesita la experiencia renderizada.
02
Entrega S3 y CloudFront
Despliega el output generado en storage AWS controlado por el cliente y edge delivery, sin requerir el origin WordPress para page views públicas.
03
Releases incrementales y dirigidos
Los workflows Professional y Agency pueden usar una baseline verificada y cambios editoriales journaled para actualizar páginas, listings, archivos y sitemaps afectados.
04
Origin de edición privado
Mantén la fuente WordPress privada, staging o interna y expón públicamente solo el frontend generado.
Capacidades
Opera WordPress estático como un pipeline de releases
Crawl y publicación de todo el sitio
Construye un artifact estático completo desde el frontend WordPress renderizado y desplíegalo sin sustituir Gutenberg, Elementor, medios ni el trabajo editorial normal.
Reescritura consciente del target
Reescribe URLs de origen para el target público seleccionado para evitar que referencias de staging o private origin aparezcan en navegación y assets production.
Deployment profiles y visibilidad
Mantén separados los ajustes específicos de cada target y conserva feedback de jobs para workflows de agencia y operación repetibles.
Las funciones dinámicas siguen explícitas
Combina la capa de páginas estáticas con Gatey, Flow, AI-Kit, Static Site Guardian o APIs custom cuando identidad, forms, AI o recursos protegidos necesiten seguir live.
Ruta de publicación
Del editor WordPress al edge de AWS
El CMS fuente, publishing engine, capa de entrega pública y servicios dinámicos opcionales siguen siendo responsabilidades separadas.
WordPress privado / staging
→ Static Publisher
├→ render + asset discovery
├→ rewrite de URLs target
├→ build full / incremental release
└→ deploy + invalidation
↓
Amazon S3 → CloudFront
├→ páginas estáticas públicas
└→ rutas estáticas protegidas opcionales
Necesidades dinámicas
→ Gatey / Flow / AI-Kit / APIs protegidas
WordPress sigue siendo la fuente editorial. El entorno público S3/CloudFront y los runtime services opcionales pertenecen a la arquitectura AWS y de aplicación seleccionada por el cliente.
Encaje
Compara el modelo de publicación, no solo el botón de exportar
| Capacidad | Static Publisher | WP2Static | Simply Static / Pro |
|---|---|---|---|
| Posicionamiento principal | Publicación estática AWS-native para WordPress | Exportador HTML estático clásico | Generador WordPress estático maduro |
| Papel de WordPress | Entorno de edición y source | Fuente del output estático | Fuente del output estático |
| Runtime objetivo | AWS propiedad del cliente | Targets de hosting estático | Varios hosts o Studio gestionado |
| Ruta AWS S3 / CloudFront | Modelo principal de delivery | Disponible mediante setup/add-ons | Disponible en Pro |
| Asset discovery * | Captura los assets que necesita la página renderizada, incluidos srcset, picture fallbacks y assets dinámicos | Principalmente basado en export/crawler | Generación estática + optimización Pro |
| Reescritura de URLs | Rewrites de target-origin y por profile | Necesidad básica del export | Funciones de rewrite y hide-WP |
| Automatización portable | Publishing engine orientado a queue/runtime | Existe uso orientado a developers | WP-CLI y workflows en Pro |
| Publicación incremental y focalizada | Professional/Agency: jobs incrementales, content sync dirigido por journal y deploy diff | Depende del setup/versión | Changes Only, Single Push y Builds en Pro |
| Varios deployment profiles | Pro: un crawl, varios targets | No es el posicionamiento principal | Varios targets compatibles |
| Rutas estáticas protegidas | Gatey + Static Guardian en AWS del cliente | No es core | No es el modelo principal |
| Workflows backend | Flow + backends serverless AWS | Fuera de alcance | Integraciones de forms/search/comments |
| Mejor encaje | Agencias que estandarizan delivery WP + AWS | Developers que necesitan export estático | Equipos que quieren deployment WordPress estático amplio |
* Exporta lo que la página realmente usa
Muchos workflows de exportación estática empiezan escaneando archivos y siguiendo referencias. Puede funcionar en sitios simples, pero las páginas WordPress modernas suelen depender de imágenes responsive, variantes srcset, picture fallbacks, scripts de page builders, assets lazy-loaded y comportamiento frontend que solo aparece después del renderizado.
Static Publisher sigue la página renderizada. Captura los assets que el navegador realmente necesita para mostrar correctamente la experiencia, manteniendo además links y referencias necesarios para navegación y delivery estático.
Para una comparación enfocada de exporters, consulta Static Publisher vs Simply Static. Si la decisión arquitectónica es entrega estática frente a un frontend construido por separado, consulta Static WordPress vs Headless WordPress.
Preguntas de evaluación
Empieza por el problema de delivery
¿Cómo mantengo WordPress para editar sin exponerlo públicamente?
Usa un modelo con origin WordPress privado y entrega pública estática. Static Publisher es el mecanismo de release detrás de esa separación.
¿Puede WordPress estático mantener login, formularios y AI?
Sí, si esas funciones usan sus propias rutas browser-to-service. Login, forms, discussions y AI pueden seguir operativos en runtimes separados después de publicar.
¿Ayuda con picos de tráfico?
La entrega estática elimina peticiones públicas cacheables de la ruta live PHP/MySQL. La capacidad total sigue dependiendo de la arquitectura completa.
¿Cómo protejo rutas estáticas seleccionadas?
Gatey puede proporcionar identidad basada en Cognito y Static Site Guardian puede aplicar rutas protegidas en CloudFront mediante signed cookies.
Empieza por el límite de delivery
Mantén el CMS para editar y sácalo de la entrega pública de páginas
Usa la guía del problema de WordPress estático para la separación general y la arquitectura runtime cuando el sitio publicado también necesite identidad, forms o AI live.