Static Publisher for WordPress
Keep WordPress for editing. Move public delivery to AWS.
Publish your WordPress site to Amazon S3 and CloudFront in your own AWS account. After handover, scheduled content-sync jobs keep the live site up to date with content changes, faster than re-exporting the entire site. Keep familiar editing, with login, forms and AI connected to their own services.
WordPress to edge
A publishing pipeline, not only an export file
Manage content and publishing settings in WordPress. An external publishing engine renders pages, collects their assets, rewrites URLs, deploys the output and refreshes the cache.
Static pages with live features
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
Keep editing in WordPress and use a repeatable process to publish changes. Visitors receive pages from S3 and CloudFront, while interactive features connect to their own services.
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 publishing and scheduled content sync
Once the site has been published and handed over, content-sync mode can run as a scheduled task to publish later content changes. It uses the verified baseline and recorded changes to update affected pages, listings, archives and sitemaps. This is faster than exporting the whole site again for each content update and is available in Professional and Agency workflows.
04
Private editing origin
Keep the WordPress source private, staging or internal while only the generated frontend is exposed publicly.
Capabilities
Publish the whole site or update what changed
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.
Keep login, forms and AI working
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.
Optional Lambda processing
Delegate publishing work instead of sizing one exporter VM for the peak
The external exporter can remain the coordinator while page rendering, asset fetching, HTML rewriting and deployment run in bounded Lambda batches. This keeps the publishing workload separate from WordPress/PHP and can also move the heavier exporter-side processing away from one long-running host.
WordPress origin
→ exporter coordinator
├→ page render batches → Lambda + Chromium
├→ asset batches → Lambda
├→ rewrite batches → Lambda
└→ deploy batches → Lambda
↓
S3 workspace → target S3 → CloudFrontScaling boundary Page rendering still depends on the WordPress origin serving the requested pages. The coordinator continues to own queue state, safety and incremental decisions, retries, logs, invalidation and final job status. With full delegation, completed HTML and assets stay in the S3 workspace for rewrite and direct S3-to-S3 deployment. See the Lambda worker 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 publishing, scheduled content-sync jobs for changes to an existing live site, and uploads limited to changed files | 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.
Common questions
Using Static Publisher in your project
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.
WordPress editing. AWS delivery.
Publish to your own AWS account
Keep WordPress as the content source, publish the site to S3 and CloudFront, then schedule content-sync jobs for ongoing content changes. Add Gatey, Flow, AI-Kit and Static Site Guardian when your site needs login, forms, AI or protected pages.