Static Publisher for WordPress
Keep WordPress for editing. Move public delivery to AWS.
Crawl the rendered site, capture the assets visitors actually need, rewrite URLs for the target environment, publish to Amazon S3, and refresh CloudFront. WordPress remains the familiar content system while the public site no longer depends on PHP and MySQL for every request.
WordPress to edge
A publishing pipeline, not only an export file
The source site can stay private or internal while repeatable jobs prepare and deliver the public frontend to customer-owned AWS infrastructure.
Runtime boundary
Static Publisher generates and deploys the frontend. Gatey, Flow, AI-Kit, Static Site Guardian, and AWS APIs can preserve selected dynamic capabilities after publishing.
Why Static Publisher
Operate a repeatable path from editor to production
A production static site needs more than downloaded HTML. It needs reliable rendering, asset discovery, target-aware rewriting, deployment, cache refresh, and a clear boundary between the authoring system and the public runtime.
01
Render-aware capture
Visit the frontend as a browser would, then capture HTML, responsive images, scripts, styles, fonts, and dynamically referenced assets required by the rendered experience.
02
Target-aware rewriting
Rewrite source URLs for staging or production so a private WordPress origin does not leak into navigation, assets, canonical paths, or public references.
03
AWS delivery path
Upload generated output to Amazon S3 and serve it through CloudFront, including invalidation after publishing so updated files reach visitors.
04
Portable publishing engine
Use WordPress administration as the control surface or run the publishing engine through scheduled jobs, automation, and deployment workflows outside the editor.
Capabilities
The publishing layer for serious static WordPress projects
Full-site crawl and publish
The free workflow can crawl and publish a complete site, including pages and browser-required assets, without replacing Gutenberg, Elementor, media, or normal content editing.
Incremental delivery
Pro workflows can compare deployment output and publish only the changed part of a site, reducing unnecessary uploads and allowing more focused cache refreshes.
Multiple deployment profiles
Reuse one source and crawl configuration for different targets such as staging and production, with target origins, credentials, and deployment settings kept separate.
Logs and operational visibility
Keep publishing records and job feedback available for troubleshooting, repeatable agency operations, and automated delivery rather than treating each export as an isolated action.
Publishing path
From WordPress editor to the AWS edge
Static Publisher treats WordPress as the authoring source and AWS as the public delivery layer. Optional runtime products connect directly to browser or AWS services instead of sending public traffic back through WordPress.
PRIVATE OR STAGING WORDPRESS
├── Gutenberg / Elementor
├── media and SEO tooling
└── normal editorial workflow
│
▼
STATIC PUBLISHER ENGINE
├── render and crawl pages
├── discover required assets
├── rewrite target URLs
└── calculate deployment output
│
▼
AMAZON S3 ORIGIN
│
▼
AMAZON CLOUDFRONT
├── public static routes
└── optional protected routes
└── Gatey + Static Site Guardian
Dynamic needs
└── Flow / AI-Kit / customer AWS APIs
The WordPress source remains under the site owner’s control. S3, CloudFront, protected routes, API backends, logs, and deployment credentials belong to the selected customer AWS environment.
Comparison
More than a static exporter
WP2Static and Simply Static helped prove that WordPress can be used as a static site source. SmartCloud Static Publisher aims at a different category: a WordPress-to-AWS publishing pipeline that can become part of a larger application architecture.
| 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 publishing | Pro: incremental jobs + deploy diff | Depends on setup/version | Quick updates 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.
Evaluation questions
What teams usually need to know
Does Static Publisher replace WordPress?
No. WordPress remains the editor, media library, administration environment, and source of content. Static Publisher changes how the public frontend is generated and delivered.
Can the source WordPress site stay private?
Yes. A common pattern is to keep WordPress on a private, staging, VPN-protected, or IP-restricted origin and publish only the generated frontend to the public S3 and CloudFront environment.
Can static pages still use forms, AI, or login?
Yes, when those features run in the browser and call independent services. Flow can submit to a backend, AI-Kit can use local or configured backend processing, and Gatey can authenticate directly with Cognito.
When is Static Site Guardian needed?
Use it when selected static paths must be rejected at CloudFront before their files are delivered. Gatey supplies the Cognito login experience; Static Site Guardian adds the signed-cookie and edge protection layer.
WordPress as source, AWS as runtime
Build normally in WordPress and publish a production frontend to the edge
Start with a complete static crawl and AWS publish. Add incremental jobs, deployment profiles, protected routes, forms, AI, or authentication as the site’s delivery model grows.