Static WordPress + interaction runtime
Make WordPress Static Without Losing Dynamic Features
Static publishing can remove WordPress PHP from public page delivery without forcing the site to lose forms, discussions, nested replies, ratings, workflow actions, login, or AI. The key is to separate page delivery from the services that store state and process actions.
Short answer Publish the page layer with Static Publisher, then keep selected capabilities dynamic through dedicated browser-to-service paths. Flow handles forms, workflow actions, discussions, replies, and ratings; Gatey handles identity; AI-Kit handles local or configured-backend AI; protected delivery can use Static Site Guardian where required.
What static publishing changes
The difficult part is not exporting HTML — it is replacing runtime assumptions
A normal WordPress site hides many interactions behind PHP requests and the database. Once the public frontend becomes static, every feature that writes state, authenticates a user, aggregates data, or triggers a workflow needs an explicit runtime path.
Interaction state
Forms are only one part of the dynamic-feature gap
Form submissions need durable writes, but so do discussion threads, nested replies, ratings, moderation state, and other record-level interactions. Treating the problem as “find a form endpoint” leaves the larger interaction layer unresolved.
Post-submit work
A submission can start a workflow instead of ending at storage
Review, routing, notifications, webhooks, approvals, scoring, or other actions happen after Submit. Those processes need a backend that is independent from WordPress page rendering.
Identity and AI
Login and knowledge features also need separate execution paths
Authentication, protected APIs, DocSearch, chat, and AI actions can continue on a static frontend when browser-side components call Cognito or configured backend services directly.
Architecture rule Classify each feature by responsibility: static files for page delivery, Flow for persistent interactions and workflows, Gatey for identity, AI-Kit for AI/search, and protected delivery only where access control is required.
Capability-preservation architecture
Keep the frontend static and move persistent interactions behind APIs
WordPress remains the authoring system. Static Publisher deploys rendered pages. Browser-side WP Suite components keep only the capabilities that require state or runtime processing connected to purpose-built services.
WordPress CMS / Gutenberg
|
v
Static Publisher
|
v
S3 + CloudFront public frontend
|
+--> Flow
| forms / save-resume / discussions
| nested replies / ratings / workflows
| -> configured Flow backend / APIs
|
+--> Gatey -> Amazon Cognito
| login / registration / MFA / SSO
|
+--> AI-Kit
| on-device AI or configured backend
| DocSearch / chatbot / AI features
|
+--> Static Site Guardian where protected paths are required
Confirmed behavior vs architecture Static delivery does not automatically provide dynamic state. Flow, Gatey, and AI-Kit preserve specific capabilities because their frontend components can work against separate services after export. Use only the runtime layers the project actually needs.
Migration path
Inventory dynamic features before switching the public runtime
The safest static migration starts by listing what the current WordPress runtime does beyond rendering pages.
- Classify every runtime-dependent feature — List forms, uploads, save/resume, discussions, replies, ratings, login, profiles, protected content, AI/search, and downstream workflow actions that currently depend on WordPress requests.
- Keep page delivery separate — Publish the cacheable WordPress frontend through Static Publisher and verify links, assets, routes, listings, and the public target before moving interaction traffic.
- Assign each dynamic responsibility to a service — Use Flow for persistent interactions and workflows, Gatey for Cognito identity, AI-Kit for AI or knowledge access, and protected-path controls only where private static content exists.
- Test state, identity, and failure modes after export — Verify submissions, drafts, discussion replies, rating aggregation, auth transitions, API authorization, AI fallback, and cache behavior on the actual static frontend rather than only on the WordPress origin.
When static WordPress with external capability services fits
Good fit
Use this pattern when most pages are cacheable but selected features remain interactive
- The site needs forms, workflows, discussions, replies, ratings, login, or AI but most page views do not require WordPress PHP.
- You want to keep Gutenberg and WordPress content management instead of rebuilding the frontend as a separate application.
- The team is willing to operate explicit APIs and identity services for the features that need persistent state.
Keep dynamic WordPress
A normal WordPress runtime may be simpler when
- Most public page views require server-side session state or database personalization before rendering.
- The required plugins depend deeply on synchronous WordPress PHP hooks and cannot be replaced with explicit service boundaries.
- The operational cost of separate APIs and services is not justified by the project’s delivery, security, or scaling requirements.
Buyer questions
Dynamic features after static publishing FAQ
How can I make WordPress static without losing comments, forms, or ratings?
Keep the public page layer static and move persistent interactions to a separate backend. Flow can support forms, discussions, nested replies, ratings, and workflow actions without requiring WordPress PHP to serve each interaction.
Can a static WordPress site support discussions and ratings?
Yes, when the frontend discussion and rating components write to a dedicated interaction backend. The static HTML delivers the interface; the service stores replies, rating state, aggregation, and related workflow data.
Can login and protected APIs still work after static export?
Yes. Gatey authenticates in the browser against Amazon Cognito, and protected APIs can validate JWT or IAM identity independently from the static page delivery path.
Can AI search or a chatbot work on static WordPress?
Yes. AI-Kit can run supported AI locally in the browser or call a configured backend directly. DocSearch and chatbot experiences can use an AWS-backed knowledge endpoint without a WordPress PHP proxy.
WP Suite static capability stack
Choose static delivery without giving up the features that make the site useful
Use Static Publisher for the page layer, then add Flow, Gatey, AI-Kit, or protected delivery only for the dynamic responsibilities the project needs.