Compare · Static WordPress publishing
Static Publisher vs Simply Static
A fair comparison for teams choosing between a mature WordPress static-site generator and an AWS-first publishing model built for static WordPress plus optional runtime services.
Short answer: Simply Static is a strong choice when you want a WordPress-native static export workflow, including ZIP/local export in the free version and broader deployment/automation features in paid editions. Static Publisher is aimed at teams that want the export step to become part of an AWS-native publishing pipeline: external runner, browser-accurate crawl, optimized asset discovery, deployment profiles, S3/CloudFront operations and integration with adjacent WP Suite runtime products.
Why this matters
Static WordPress is no longer a single problem. One team may only need to generate HTML and upload it somewhere. Another team may want WordPress to become an internal editorial system while the public site runs on S3, CloudFront, WAF, signed cookies, Cognito-backed login, AI widgets and serverless forms.
Those are different operating models. A plugin-centered exporter can be excellent for a straightforward static site. An external publishing pipeline becomes more interesting when the crawl, rewrite, deployment target, invalidation strategy and runtime integrations must be predictable across multiple environments or client projects.
This comparison is not about claiming that one tool is universally better. It is about deciding whether static export is the final feature, or whether static publishing is one stage in a larger WordPress-on-AWS architecture.
Architecture and data flow
WordPress editor / admin settings
↓ publish request + site configuration
Static Publisher plugin control plane
↓ job/config handoff
External Node + Playwright exporter
↓ crawl, render, rewrite, artifact build
S3 bucket + CloudFront invalidation
↓
Static frontend with optional Gatey, AI-Kit and Flow runtime components
The key design choice is that the heavy crawl and deploy work does not have to run inside the WordPress PHP pool. A dedicated runner can use a browser-like crawl model, controlled credentials and a deployment profile for the target environment. Even if the runner is on the same machine, it is not consuming the PHP workers that serve WordPress; if it runs on a separate VM, the WordPress host is protected even further.
That makes the pattern feel less like “click export” and more like a publishing pipeline. It is especially relevant when the same WordPress source needs dev, staging and production targets, when pages rely on JavaScript, timers or scroll-triggered rendering, or when static output is only one layer in a broader AWS runtime.
Capability map
Mature static export
Simply Static strength
Simply Static is well suited to WordPress users who want a familiar plugin workflow for generating a static copy of a site and, in paid tiers, additional deployment and automation options.
External runner
Static Publisher strength
Static Publisher separates WordPress admin/control concerns from crawler/deploy execution, making the publishing job more explicit, easier to isolate and less likely to overload WordPress PHP resources.
Browser rendering
JavaScript-aware crawl mindset
A Playwright-based exporter can wait for hydration, lazy loading, timers and scroll-triggered rendering, so assets that only appear in the real browser state can still be captured.
AWS-first deployment
S3 and CloudFront as primary targets
The product is designed around AWS static delivery, including object deployment, URL rewriting and invalidation as first-class concerns, while still allowing the rewritten output to be downloaded, archived and hosted elsewhere if needed.
Deployment profiles
Repeatable environment publishing
Profiles let teams treat dev, staging and production as predictable targets rather than ad-hoc export destinations.
Runtime ecosystem
Static output plus dynamic features
Static Publisher can sit beside Gatey, AI-Kit and Flow when the exported site still needs login, AI, forms, workflows or API-backed interactions.
Decision table
| Decision axis | Static Publisher | Simply Static | Trade-off |
|---|---|---|---|
| Best starting point | AWS-first static delivery with external runner and runtime roadmap | WordPress-native static generation with broad plugin ecosystem familiarity | Choose based on operational model, not only feature count. |
| Free/simple use | Not positioned as a generic one-click ZIP exporter, but the rewritten output can be downloaded from the WordPress host and moved elsewhere. | Free version covers basic static generation and ZIP/local workflows | Simply Static is easier for simple exports; Static Publisher is more pipeline-oriented. |
| Deployment model | S3/CloudFront-focused deployment profiles | Multiple deployment options in paid tiers, including common static hosts | Static Publisher is more opinionated around AWS. |
| Execution model | External Node/Playwright runner outside the WordPress PHP pool | Primarily WordPress plugin workflow with additional automation in paid tiers | External runner adds setup but avoids burning PHP workers during heavy crawl work. |
| Rendered asset discovery | Downloads assets and URLs that become effective during browser rendering, including lazy-load, timer and scroll-based content, while skipping code-declared assets that never load. | Can discover many linked assets from the generated/source output and supported integrations. | Browser-effective discovery can avoid over-exporting large bundles that contain unused URLs. |
| Dynamic features | Designed to combine with Gatey, AI-Kit and Flow | Forms/search/comments can be handled through supported integrations in paid editions | Different philosophy: ecosystem runtime vs exporter feature integrations. |
| Agency use | Repeatable AWS publishing pattern for client sites | Useful for developers/agencies that want static WordPress exports | Both can serve agencies; WP Suite is more architecture-led. |
The practical difference is not “static vs static.” It is whether the static exporter is the product boundary or one component in a larger AWS delivery and runtime system.
How this differs from the usual approach
Straight export case
When Simply Static is enough
Choose Simply Static when you need a proven static WordPress generator, the site is mostly public content, the deployment target is straightforward, and the team wants the exporter to stay inside the WordPress plugin workflow.
AWS-first publishing
When Static Publisher is better
Choose Static Publisher when AWS delivery, external runner control, multi-environment profiles, JavaScript-heavy rendering, optimized asset discovery and future runtime services are part of the plan.
Migration rhythm
Adoption path
Start by proving crawl fidelity and deployment safety. Then add profiles and invalidation rules. Only after that should you add protected content, AI, forms or identity runtime features.
When this is a good fit
- A team wants WordPress as an editorial backend but S3/CloudFront as the public delivery layer.
- The site has modern JavaScript behavior that must be crawled and exported reliably.
- The site includes large theme or builder bundles where many URLs exist in code but only some become effective in the rendered page.
- Agencies need repeatable publishing profiles for multiple AWS environments.
- The roadmap includes login, protected static content, AI features, forms or workflows after static export.
- Security policy prefers the public site to serve no PHP or database-backed pages.
When not to use this
- The goal is only a one-off ZIP export of a small public website.
- The team wants a fully WordPress-admin-centered exporter and no external runner.
- There is no AWS target, no interest in S3/CloudFront deployment profiles, and no need for runner isolation.
- The project does not need future runtime features around the static frontend.
Implementation path
- Define whether static export is the final deliverable or part of a wider AWS architecture.
- Create representative crawl tests: homepage, templates, lazy-loaded sections, timer-based content, scroll-triggered galleries, forms, translated pages and dynamic widgets.
- Decide where the external runner executes and how it receives credentials and deployment configuration.
- Compare exported assets against the rendered browser state, not only against URLs that exist inside JavaScript or builder bundles.
- Create separate deployment profiles for dev, staging and production instead of changing settings manually.
- Verify URL rewriting, canonical URLs, sitemap output, asset paths and CloudFront behavior before production publishing.
- Download and archive the rewritten output when you need a portable artifact outside the direct S3 deployment path.
- Add runtime products only where static HTML alone cannot satisfy the user experience.
Related resources
FAQ
Is this an anti-Simply Static comparison?
No. Simply Static is a strong static WordPress product. This page explains when WP Suite’s AWS-first publishing model is a better architectural fit.
Does Static Publisher replace the need for S3 or CloudFront configuration?
No. It helps publish to AWS-oriented targets, but the delivery architecture still needs correct bucket, distribution, DNS, cache and invalidation decisions.
Why use an external runner?
An external runner keeps crawl and deploy execution out of the WordPress PHP pool, makes credentials and resource limits more explicit, and supports a browser-oriented export model. On a separate VM it can reduce load on the WordPress host even further.
Can Simply Static also deploy to AWS?
Simply Static’s public plugin information describes advanced deployment options in paid editions, including AWS S3. The difference here is not whether AWS is possible, but how central AWS is to the product architecture.
Can Static Publisher handle dynamic site features?
Static Publisher handles the publishing layer. It can capture browser-rendered static output, including assets that appear after JavaScript, timers or scrolling, but live runtime behavior should be handled by adjacent services such as Gatey, AI-Kit, Flow or custom APIs.
Which should a small site choose?
For a small public site with simple static output, a simpler exporter may be enough. Static Publisher becomes more valuable when crawl fidelity, runner isolation, AWS operations, optimized asset discovery or runtime architecture matter.
Choose the right static publishing model
Use a simple static generator when export is the whole project. Use an AWS-first publishing pipeline when static WordPress is becoming part of a broader cloud architecture.