Solution · Static WordPress
Static WordPress on AWS
A practical architecture for publishing WordPress to S3 and CloudFront without giving up the dynamic features that still matter.
Short answer: Static WordPress on AWS means using WordPress for editing while serving the public site from S3 and CloudFront. In the WP Suite model, static delivery can be combined with deployment-wizard-assisted AWS stacks for Cognito, AI-Kit, Flow and Site Guardian, so authentication, AI, forms, protected paths and knowledge-base features can run through customer-configured AWS endpoints instead of WordPress PHP.
Why this matters
Traditional WordPress performance and security work often starts by hardening PHP, caching database-driven pages and trying to keep a plugin-heavy runtime safe under peak load.
For many marketing, documentation and agency sites, most public page views do not need PHP or MySQL at request time. Static delivery removes that runtime dependency for anonymous traffic.
The difficult part is preserving the features that made the site useful: login, protected pages, forms, AI assistance, search, personalization or backend workflows. WP Suite is designed for that middle ground.
Architecture and data flow
WordPress editorial site
↓ crawl / render / rewrite
Static Publisher external runner
↓ deploy
S3 origin + CloudFront distribution
↓ browser-side runtime where needed
Gatey / AI-Kit / Flow components
↓ configured APIs
Cognito / API Gateway / Lambda / Bedrock / workflow services
Capability map
Static Publisher
Crawls rendered WordPress with the external Node/Playwright exporter, rewrites URLs, publishes assets to S3 and invalidates CloudFront. WordPress remains the editorial source, not the runtime for every public request.
Deployment wizard
Guided deployment can turn a few high-impact choices into a prefilled CloudFormation Create stack URL. This lowers the adoption barrier for backend and protection stacks because the deployer reviews the parameters in AWS and creates the stack instead of assembling template URLs manually.
Site Guardian stack
For protected static delivery, the Site Guardian template provisions S3, CloudFront, signed-cookie issuance, edge logic and optional DNS/refresh behavior so selected paths can stay private after export.
Gatey / Cognito infrastructure
Gatey can use a Cognito infrastructure template for user pools, app clients, token customization and email-delivery choices. It gives the static frontend a real identity layer without moving login back into WordPress PHP.
AI-Kit and Flow backends
AI-Kit and Flow can be backed by customer-configured AWS endpoints for chatbot, DocSearch, knowledge-base sync, form submissions, workflows and event-driven operations.
Runtime after export
The site can be static at the edge while browser-side WP Suite blocks call the configured APIs for auth, AI, forms and protected behavior. That keeps static delivery and dynamic capabilities separate.
Guided deployment path
The important adoption detail is that WP Suite is moving the AWS setup closer to a guided product experience. Instead of asking an agency or site owner to manually assemble template URLs and parameters, a deployment wizard can collect the few decisions that matter and generate a CloudFormation Create stack review URL with parameters already filled in.
Site Guardian template
Complete protected static-site stack for S3/CloudFront, signed cookies, JWT-verified cookie issuance and optional path-to-group authorization.
Cognito template
Gatey-oriented user pool and authentication infrastructure, including email delivery choices and deployment-time custom resources.
AI-Kit backend template
Backend endpoint for editor/frontend AI, chatbot, DocSearch, KB sync and RAG-style workflows.
Flow backend template
Backend endpoint for forms, submissions, workflow dispatching, webhook dispatching and automation.
The deployment wizard does not remove AWS review or permissions. It reduces the setup surface: the deployer still reviews the CloudFormation stack, accepts required capabilities and creates the stack in their AWS account.
Decision table
| Mode / dimension | Best for | Data path / approach | Trade-off |
|---|---|---|---|
| Static-only export | Fast public pages, brochure content, docs and marketing pages | Visitor → CloudFront → S3 | Simplest model, but does not solve login, forms or AI by itself |
| Static + browser auth | Private areas, profile-aware UI, signed API calls | Browser → Cognito / API Gateway | Requires Cognito and careful frontend configuration |
| Static + AI/runtime APIs | Search, chatbot, forms and workflows | Browser → configured endpoint → AWS backend | More setup, much more control |
| Staging/production profiles | Agencies and teams with repeatable release flows | One crawl artifact → multiple deployment profiles | Requires disciplined deployment profile management |
How this differs from the usual approach
Traditional cached WordPress
WordPress still serves requests; caching reduces load but PHP/DB remain part of runtime operations.
Headless WordPress
Often flexible, but usually introduces a separate frontend app, build pipeline and preview/editing complexity.
Static WordPress with WP Suite
Keeps WordPress editing while moving public delivery and selected runtime behavior to AWS services.
When this is a good fit
- You want WordPress editing but CloudFront-grade public delivery.
- You need a lower-attack-surface public frontend.
- Your site still needs login, forms, AI search or protected API calls.
- You run agency/client deployments where staging and production targets should be repeatable.
- You want to avoid designing a WordPress PHP/MySQL stack for peak public traffic.
When not to use this
- A small site that is already fast enough and has no security/runtime concerns.
- A complex WooCommerce-style checkout where most pages truly need live PHP and database state.
- A team that does not want to manage AWS, deployment profiles or external runner operations.
Implementation path
- Install and configure Static Publisher in WordPress.
- Install the external
@smart-cloud/publisher-exporterrunner on a machine with Node.js, Playwright and AWS credentials. - Define origin URL, target URLs, rewrite rules, S3 bucket and CloudFront distribution settings.
- Use crawl-only and preview stages before production deploy.
- Decide which dynamic capabilities remain: login, protected paths, AI, DocSearch, forms or workflows.
- Use the deployment wizard or SAR/CloudFormation templates for the needed backend stacks: Cognito, AI-Kit backend, Flow backend and/or Site Guardian.
- Copy stack outputs such as API base URLs, site keys or CloudFront details back into WordPress settings.
- Create staging and production deployment profiles where promotion workflows matter.
Related resources
Static Publisher
product page for crawl, rewrite, deploy and invalidation workflows
Secure Static WordPress
protected content and portal angle
Static WordPress vs Headless WordPress
architecture decision support
Static Publisher vs Simply Static
exporter comparison
Reference Architecture
WordPress + AWS runtime view
Flow
forms, workflow automation and frontend/backend submission patterns
Serverless WordPress Backend
API Gateway, Lambda and event-driven backend pattern
FAQ
Does static WordPress on AWS require manual CloudFormation setup?
Not necessarily. The intended deployment path can use guided wizard screens to generate prefilled CloudFormation Create stack URLs for the backend or protection stacks that the project needs.
Can the static site still use AI, forms or login?
Yes. Those features should be modeled as browser-side components calling configured AWS endpoints, rather than assuming WordPress PHP handles every request after export.
What is Static WordPress on AWS?
Static WordPress on AWS means keeping WordPress as the authoring system while serving the public site from S3 and CloudFront. With WP Suite, the static layer can still connect to runtime features such as Cognito login, forms, AI search, protected APIs and workflow endpoints when the project needs them.
Does this replace WordPress?
No. The recommended model keeps WordPress as the editorial and management layer. WP Suite adds cloud-native runtime capabilities around it rather than forcing a CMS migration.
Can this work with static WordPress?
Yes, when the required browser-side and API endpoints are reachable after export. Static publishing changes where the public HTML is served from; it does not prevent JavaScript components from calling configured APIs.
Is this only for large enterprise projects?
No, but it is most valuable when identity, security, AI, forms, workflows, protected APIs or repeatable AWS deployment patterns matter. For a simple brochure site, it may be unnecessary.
Does static WordPress mean no dynamic features?
No. Static delivery removes PHP from public page serving, but browser-side components can still call Cognito, API Gateway, Lambda, Bedrock-backed endpoints or workflow APIs.
Why not just use a static exporter?
A simple exporter can be enough for simple sites. WP Suite focuses on static delivery plus the surrounding application layer: identity, AI, forms, protected APIs and repeatable AWS deployment patterns.
Can Static Publisher reuse one crawl for multiple targets?
The architecture supports deployment profiles, so the same crawl artifact can be promoted to different targets such as staging and production when rewrite and deployment configuration allow it.
Does the WordPress admin remain dynamic?
Yes. The editorial WordPress installation remains the authoring/control plane. The public frontend can be exported and served separately.
Publish WordPress statically without losing the runtime features that matter
Turn WordPress into a static AWS-hosted site while keeping authentication, AI, forms, protected APIs and workflows through WP Suite components.