Publish WordPress as a fast, secure AWS-backed static site.
Static Publisher turns WordPress into the editing source while your public site is delivered from AWS. Crawl, rewrite, publish, and invalidate from a workflow designed for real production sites — not just one-off exports.
Render-aware publishing
Capture real frontend output, including modern WordPress, Elementor, scripts, styles, images, and assets.
AWS delivery path
Publish static output to S3 and serve globally through CloudFront, with cache invalidation when needed.
Portable engine
Use WordPress admin as the control surface, or run the publishing engine outside WordPress in automation.
Platform-ready
Add Gatey, Cognito, Static Guardian, AI-Kit, and Flow when static delivery needs authentication, APIs, AI, forms, or workflows.
Static export is useful. A publishing pipeline is stronger.
A basic static export can make a WordPress site faster and safer. But production publishing usually needs more than a generated ZIP or a one-click copy.
Teams need reliable crawling, asset discovery, URL rewriting between development, staging, and production, deployment targets, CloudFront invalidation, logs, repeatable jobs, and a clean way to move from a private WordPress editing environment to a public AWS delivery layer.
WordPress becomes the editing source. AWS becomes the runtime. Static Publisher is the publishing bridge.
This is the difference between exporting files and operating a repeatable publishing path for client-owned infrastructure.
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.
From WordPress editor to AWS edge.
Build in WordPress
Keep Gutenberg, Elementor, media, SEO plugins, landing pages, and normal WordPress content workflows.
Crawl and capture the rendered site
Visit the site like a real frontend, capture HTML, discover assets, and prepare output for the target environment.
Rewrite for the target domain
Move from development or private WordPress domains to staging or production without baking in the wrong URLs.
Publish to AWS
Upload the generated output to S3 and serve the site through CloudFront.
Invalidate only what needs to refresh
Trigger CloudFront invalidation so visitors see the latest version without falling back to dynamic WordPress.
Add protection or runtime features
Keep the public site static, but add Gatey, Static Guardian, AI-Kit, Flow, and backend APIs when needed.
Static does not have to mean public-only.
WP Suite separates publishing from access control. Static Publisher handles the build. Gatey connects the frontend to Cognito. Static Guardian protects selected CloudFront paths before visitors reach the origin.
Gatey
WordPress-facing Cognito login: sign-in, sign-up, MFA, profile screens, shortcodes, Gutenberg blocks, and Elementor widgets. It keeps working after static export because auth runs in the browser against Cognito.
Static Guardian
The AWS-side protection layer for selected CloudFront routes, using signed cookies and Cognito-aware access patterns.
Static Publisher
Publishes public and protected static output. Public routes stay cacheable; private routes can be delivered only to authenticated users.
The publishing layer for serious static WordPress projects.
Static crawl and asset capture
Export pages, media, CSS, JavaScript, fonts, and other assets needed by the rendered frontend.
Runtime URL rewriting
Prepare output for a different public domain than the WordPress source: private authoring, staging, and production.
AWS-first deployment
Publish output to S3 and serve through CloudFront so public traffic no longer depends on PHP and MySQL.
CloudFront invalidation
Clear edge cache paths after publishing while keeping the performance benefits of static delivery.
Admin-friendly configuration
Manage publishing from WordPress admin, giving agencies and site owners a familiar control surface.
Automation-ready direction
Use the publishing engine outside wp-admin for scheduled jobs, cron runners, CI/CD, or server-side automation.
Start with static publishing. Grow into an AWS-backed platform.
Scheduled publishing, incremental crawl and publish, audit logs, deployment profiles, staging and production targets from one crawl, Gatey-protected routes, and repeatable AWS deployment templates form the Pro/platform direction.
Agency client sites
Standardize a safer, faster hosting pattern across projects without forcing clients to learn a new CMS.
Private authoring
Keep WordPress behind a private, staging, VPN-protected, or IP-restricted environment.
Knowledge sites
Publish fast documentation, then extend it with AI-Kit DocSearch or chatbot experiences.
Member portals
Use static delivery for the shell, Gatey for login, Static Guardian for route protection, and AWS APIs for dynamic data.
Frequently asked questions.
Is this just another static export plugin?
No. It does export static WordPress output, but the product direction is broader: a publishing pipeline for AWS-backed WordPress projects, including repeatable publishing, URL rewriting, CloudFront delivery, protected static routes, and future workflow automation.
Does it replace WordPress?
No. WordPress remains the editing and admin environment. Static Publisher changes what serves public traffic.
Does it work with Elementor?
The product direction is render-aware publishing, which is important for modern WordPress sites and visual builders. The goal is to capture the frontend output visitors actually see, including generated layouts and assets.
Can I use it without Gatey?
Yes. If your site is fully public, Static Publisher can be used as the publishing layer on its own.
When do I need Static Guardian?
Use Static Guardian when selected static paths should be protected at the CloudFront edge instead of being publicly accessible.
Can static pages still have forms?
Yes, but forms should not depend on the WordPress PHP runtime after publishing. The WP Suite direction is to pair static delivery with Flow or backend-connected endpoints.
Keep WordPress for editing. Move delivery to AWS.
Publish static WordPress sites with a path toward protected routes, Cognito authentication, AI, forms, workflows, and client-owned AWS infrastructure.