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 serving public WordPress output from S3 and CloudFront while keeping selected runtime features alive through browser-side components and configured APIs. The architecture is strongest when static publishing is treated as the delivery layer, not as a promise that the whole site must become featureless HTML.
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
Static does not mean frozen
Content delivery
HTML becomes edge-delivered output
Public pages, images and assets can be served without invoking WordPress PHP or querying MySQL for anonymous traffic.
Editorial workflow
WordPress remains the source of truth
Editors can keep using the block editor, previews and publishing workflow while the deployment process produces static output.
Runtime islands
Dynamic features move to APIs
Login, forms, AI, search and protected actions can continue as browser-side components that call dedicated endpoints.
Security posture
The public attack surface changes
The public visitor no longer needs direct access to wp-login.php, wp-admin or plugin PHP code when the static layer is deployed correctly.
Capability map
Publishing layer
Static Publisher
Crawls rendered WordPress pages with an external Node/Playwright exporter, rewrites URLs, deploys to S3 and invalidates CloudFront without executing shell commands from PHP.
Identity layer
Gatey
Adds Cognito login, SSO and authenticated API calls from the browser, so authentication can work even after export.
AI runtime
AI-Kit
Adds local-first editor AI and optional AWS-backed frontend AI, DocSearch or chatbot capabilities.
Workflow runtime
Flow
Keeps forms and workflows connected to configured endpoints or an AWS backend instead of depending on WordPress PHP for every submission.
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
Optimized PHP model
Traditional cached WordPress
WordPress still serves requests; caching reduces load but PHP/DB remain part of runtime operations.
Decoupled frontend model
Headless WordPress
Often flexible, but usually introduces a separate frontend app, build pipeline and preview/editing complexity.
Rendered-edge model
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-exporter runner on a machine with Node.js, Playwright and AWS credentials.
- Define origin URL, target URLs, rewrite rules, S3 bucket and CloudFront distribution settings.
- Run crawl-only and preview the artifact before production deploy.
- Add Gatey, AI-Kit or Flow only for the runtime features the static site actually needs.
- Create staging and production deployment profiles where promotion workflows matter.
- Connect this page from Static Publisher, platform, architecture and relevant blog posts.
Migration checkpoints
| Checkpoint | What to verify | Why it matters |
|---|---|---|
| URL rewriting | Canonical URLs, internal links, assets, feeds and language paths resolve after export. | Static export failures often look like SEO or navigation problems rather than infrastructure problems. |
| Dynamic dependencies | Forms, search, login, comments, carts and AI widgets have a non-PHP runtime path. | Anything that depended on WordPress request handling must be replaced, disabled or moved. |
| Preview and staging | Editors can review static output before production deployment. | The rendered site, not the database content alone, is what visitors will receive. |
| Cache invalidation | Changed pages and shared assets are invalidated predictably. | A fast CDN is only useful if stale pages can be controlled. |
| Protected content | Private pages and assets are not exported into public paths accidentally. | Static delivery makes misplaced sensitive HTML very easy to cache and share. |
Where this works best
- Marketing sites, documentation hubs and agency client sites where most traffic is anonymous and cacheable.
- Projects that need WordPress editing but do not need PHP/MySQL for every public page view.
- Hybrid sites where only specific features — login, forms, AI, protected downloads — need a runtime backend.
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
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.
Can a static WordPress site still have forms, login or AI?
Yes. Those features should not depend on WordPress PHP at request time. They can run as browser-side components that call Cognito, API Gateway, Lambda, Bedrock or another configured backend endpoint.
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.