Render-aware publishing
Capture real frontend output, including modern WordPress, Elementor, scripts, styles, images, and assets.
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.
Capture real frontend output, including modern WordPress, Elementor, scripts, styles, images, and assets.
Publish static output to S3 and serve globally through CloudFront, with cache invalidation when needed.
Use WordPress admin as the control surface, or run the publishing engine outside WordPress in automation.
Add Gatey, Cognito, Static Guardian, AI-Kit, and Flow when static delivery needs authentication, APIs, AI, forms, or workflows.
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.
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 |
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.
Keep Gutenberg, Elementor, media, SEO plugins, landing pages, and normal WordPress content workflows.
Visit the site like a real frontend, capture HTML, discover assets, and prepare output for the target environment.
Move from development or private WordPress domains to staging or production without baking in the wrong URLs.
Upload the generated output to S3 and serve the site through CloudFront.
Trigger CloudFront invalidation so visitors see the latest version without falling back to dynamic WordPress.
Keep the public site static, but add Gatey, Static Guardian, AI-Kit, Flow, and backend APIs when needed.
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.
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.
The AWS-side protection layer for selected CloudFront routes, using signed cookies and Cognito-aware access patterns.
Publishes public and protected static output. Public routes stay cacheable; private routes can be delivered only to authenticated users.
Export pages, media, CSS, JavaScript, fonts, and other assets needed by the rendered frontend.
Prepare output for a different public domain than the WordPress source: private authoring, staging, and production.
Publish output to S3 and serve through CloudFront so public traffic no longer depends on PHP and MySQL.
Clear edge cache paths after publishing while keeping the performance benefits of static delivery.
Manage publishing from WordPress admin, giving agencies and site owners a familiar control surface.
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.
Standardize a safer, faster hosting pattern across projects without forcing clients to learn a new CMS.
Keep WordPress behind a private, staging, VPN-protected, or IP-restricted environment.
Publish fast documentation, then extend it with AI-Kit DocSearch or chatbot experiences.
Use static delivery for the shell, Gatey for login, Static Guardian for route protection, and AWS APIs for dynamic data.
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.
No. WordPress remains the editing and admin environment. Static Publisher changes what serves public traffic.
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.
Yes. If your site is fully public, Static Publisher can be used as the publishing layer on its own.
Use Static Guardian when selected static paths should be protected at the CloudFront edge instead of being publicly accessible.
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.
Publish static WordPress sites with a path toward protected routes, Cognito authentication, AI, forms, workflows, and client-owned AWS infrastructure.