Static Publisher for WordPress
Keep WordPress for editing. Move public delivery to AWS.
Render the approved WordPress frontend, deploy it to Amazon S3 and CloudFront, and keep dynamic capabilities on explicit browser or AWS service paths instead of exposing the CMS for every public page request.
WordPress to edge
A publishing pipeline, not only an export file
WordPress remains the source and control plane. An external publishing engine handles rendering, asset discovery, URL rewriting, deployment and cache refresh.
Runtime boundary
Static Publisher generates the page layer. Login, forms, AI, protected paths and application APIs remain separate services when the site needs them.
Why Static Publisher
Separate the editorial system from the public delivery path
A static production site needs a repeatable release mechanism and a clear answer to what stays in WordPress versus what runs elsewhere.
01
Render-aware publishing
Capture the frontend as a browser uses it, including responsive and dynamically requested assets needed by the rendered experience.
02
S3 and CloudFront delivery
Deploy generated output to customer-controlled AWS storage and edge delivery instead of requiring the WordPress origin for public page views.
03
Incremental and targeted releases
Professional and Agency workflows can use a verified baseline and journaled editorial changes to update affected pages, listings, archives and sitemaps.
04
Private editing origin
Keep the WordPress source private, staging or internal while only the generated frontend is exposed publicly.
Capabilities
Operate static WordPress as a release pipeline
Full-site crawl and publish
Build a complete static artifact from the rendered WordPress frontend and deploy it without replacing Gutenberg, Elementor, media or normal editorial work.
Target-aware rewriting
Rewrite source URLs for the selected public target so staging or private-origin references do not leak into production navigation and assets.
Deployment profiles and visibility
Keep target-specific settings separate and retain job feedback for repeatable agency and operational workflows.
Dynamic features stay explicit
Pair the static page layer with Gatey, Flow, AI-Kit, Static Site Guardian or custom APIs when identity, forms, AI or protected resources must remain live.
Publishing path
From WordPress editor to the AWS edge
The source CMS, publishing engine, public delivery layer and optional dynamic services remain separate responsibilities.
Private / staging WordPress
→ Static Publisher
├→ render + discover assets
├→ rewrite target URLs
├→ build full / incremental release
└→ deploy + invalidate
↓
Amazon S3 → CloudFront
├→ public static pages
└→ optional protected static paths
Dynamic needs
→ Gatey / Flow / AI-Kit / protected APIs
WordPress remains the editorial source. The public S3/CloudFront environment and optional runtime services belong to the selected customer AWS and application architecture.
Fit
Compare the publishing model, not just the export button
| Capability | Static Publisher | WP2Static | Simply Static / Pro |
|---|---|---|---|
| Primary positioning | AWS-native static publishing for WordPress | Classic static HTML exporter | Mature static WordPress generator |
| WordPress role | Editor and source environment | Static output source | Static output source |
| Target runtime | Customer-owned AWS | Static hosting targets | Multiple hosts or managed Studio |
| AWS S3 / CloudFront path | Core delivery model | Available via setup/add-ons | Available in Pro |
| Asset discovery * | Captures assets required by the rendered page, including srcset, picture fallbacks, and dynamic assets | Primarily export/crawler based | Static generation + Pro optimization |
| URL rewriting | Target-origin and profile-level rewrites | Core export concern | Rewrite and hide-WP features |
| Portable automation | Queue/runtime-oriented publishing engine | Developer-oriented usage exists | WP-CLI and workflows in Pro |
| Incremental and focused publishing | Professional/Agency: incremental jobs, journal-driven targeted content sync and deploy diff | Depends on setup/version | Changes Only, Single Push and Builds in Pro |
| Multiple deployment profiles | Pro: one crawl, multiple targets | Not the main positioning | Multiple targets supported |
| Protected static routes | Gatey + Static Guardian on customer AWS | Not core | Not the main model |
| Backend workflows | Flow + AWS serverless backends | Outside scope | Forms/search/comments integrations |
| Best fit | Agencies standardizing WP + AWS delivery | Developers needing static export | Teams wanting broad static WP deployment |
* Export what the page really uses
Many static export workflows start by scanning files and following references. That can work for simple sites, but modern WordPress pages often rely on responsive images, srcset variants, picture fallbacks, page-builder scripts, lazy-loaded assets, and frontend behavior that only becomes visible after rendering.
Static Publisher follows the rendered page instead. It captures the assets the browser actually needs to display the experience correctly, while still preserving the links and references required for navigation and static delivery.
For a focused exporter comparison, see Static Publisher vs Simply Static. If the architectural choice is static delivery versus a separately built frontend, see Static WordPress vs Headless WordPress.
Evaluation questions
Start from the delivery problem
How do I keep WordPress for editing without exposing it publicly?
Use the private WordPress with public static delivery guide. Static Publisher is the release mechanism behind that editorial-origin/public-delivery split.
Can static WordPress keep login, forms and AI?
Yes, when those features use their own browser-to-service paths. The static WordPress with dynamic features guide maps login, forms, discussions and AI to the runtimes that keep working after publishing.
Can this help with traffic spikes?
Static delivery removes cacheable public page requests from the live PHP/MySQL path. See the traffic-spike delivery guide for the problem framing; capacity still depends on the complete architecture.
How do I protect selected static paths?
Use Gatey for Cognito-backed identity and Static Site Guardian for CloudFront-enforced protected paths. The secure static WordPress guide covers the login boundary, and the signed-cookie architecture covers delivery enforcement.
Start with the delivery boundary
Keep the CMS for editing and remove it from public page delivery
Use the static WordPress problem guide for the overall split, then use the runtime architecture when the published site also needs live identity, forms or AI.