Static Publisher + WordPress
Keep WordPress for Editing Without Exposing WordPress Publicly
Editors can keep WordPress, Gutenberg, previews, and the publishing workflow while public visitors receive rendered files from S3 and CloudFront instead of a publicly reachable WordPress/PHP runtime.
Short answer Use WordPress as the private authoring layer, render the site with Static Publisher, and serve the public output from S3 and CloudFront. WordPress remains the CMS, but it no longer has to sit in the public request path.
The production-boundary problem
Teams often want WordPress editing without WordPress page delivery
The CMS and the public runtime do not have to be the same system. Separating them changes which components need to be reachable during a normal visitor request.
Exposure
The public site inherits the WordPress runtime surface
When every page view reaches WordPress, the public delivery path also includes PHP, the database, wp-login, plugin code, and the operational dependencies around that stack.
Traffic
Anonymous traffic still depends on origin capacity
Caching helps, but a traditional setup still needs a WordPress origin designed and operated as part of the public serving architecture.
Migration risk
Leaving WordPress often means rebuilding the editing workflow
A headless rebuild can remove WordPress from page delivery, but it may also introduce a new frontend application, preview model, and content workflow that editors did not ask to replace.
Boundary decision Keep WordPress where it is strongest—authoring and content management—and move public page delivery only when that separation creates a concrete operational benefit.
Publishing path
Private WordPress authoring, rendered artifact, public static delivery
Static Publisher treats WordPress as the source and the rendered site as the deployable artifact. Selected dynamic capabilities can remain separate browser-to-API interactions.
Private / staging WordPress
|
v
Editors use Gutenberg and normal WordPress workflows
|
v
Static Publisher external runner
| crawl / render / rewrite / verify
v
S3 origin + CloudFront distribution
|
v
Public visitor receives static HTML and assets
|
+--> optional Gatey identity
+--> optional Flow interactions
+--> optional AI-Kit search / AI
+--> configured APIs
Scope boundary Static publishing removes WordPress from public page rendering. It does not automatically replace forms, authentication, comments, workflows, search, or AI features; those need an explicit runtime path when the site uses them.
Implementation
Move page delivery without rebuilding the CMS
Start with the public serving boundary, then add only the runtime services the static site actually needs.
- Keep WordPress as the authoring origin — Use the existing WordPress content model, Gutenberg blocks, previews, and editorial workflow as the source for the public site.
- Configure Static Publisher — Set the origin, public target, URL rewrites, S3 bucket, CloudFront distribution, and deployment profile for the environment.
- Render and verify the public artifact — Run a full publish first, review the generated site, confirm internal links and assets, then verify the public target before relying on incremental or content-sync workflows.
- Add dynamic capabilities separately — Use Gatey, Flow, AI-Kit, or other APIs only for the features that still require runtime state or authenticated actions after the site becomes static.
When private WordPress + public static delivery fits
Good fit
Use this model when WordPress is valuable as a CMS but not as the public runtime
- Most public page views are anonymous and cacheable, such as marketing, documentation, editorial, or agency sites.
- You want editors to keep WordPress while reducing public dependence on PHP and MySQL page rendering.
- The project can separate remaining dynamic features into browser-side identity, APIs, workflows, or AI services.
Keep dynamic WordPress
A normal WordPress runtime may be simpler when
- Most public pages require server-side personalization or database state on every request.
- The site relies heavily on runtime features that cannot be separated cleanly from WordPress request handling.
- The team does not want to operate a static publishing and deployment workflow.
Buyer questions
Private WordPress and static delivery FAQ
How can I use WordPress without exposing it publicly?
Keep WordPress on a private or staging origin for editing, then publish rendered output to S3 and CloudFront. Public visitors receive the static site instead of connecting to the WordPress runtime.
Can WordPress be private while the website is public?
Yes. WordPress can remain the CMS and authoring environment while the public website is a separately deployed static artifact.
Do static WordPress sites lose all dynamic features?
No. Static page delivery and dynamic capabilities are separate decisions. Login, forms, workflows, search, and AI can use browser-side components and configured APIs where needed.
Is this the same as headless WordPress?
No. A headless setup usually introduces a separate frontend application. Static Publisher renders the existing WordPress frontend, so the site can keep its WordPress templates, blocks, and editorial workflow.
WP Suite Static Publisher
Keep WordPress as the CMS, not the public request path
Publish the rendered site to S3 and CloudFront while editors continue working in WordPress.