Static WordPress, dynamic capabilities
Static WordPress with Login, Forms and AI
Use static delivery for page views without giving up the dynamic features that users still need.
Short answer A static WordPress frontend does not have to become a featureless brochure. Keep page delivery on S3 and CloudFront, then run each dynamic responsibility through the browser and a purpose-built service: Cognito for identity, signed cookies for protected static paths, API Gateway and Lambda for APIs, AI-Kit backend for AI, and Flow backend for forms and workflows.
The architecture mistake
One dynamic feature does not need to make the whole site dynamic
Static delivery works best when runtime decisions are made per feature instead of treating the entire site as one PHP application.
Problem 1
Login is often treated as a server-rendering requirement
Browser-based identity can authenticate directly against Cognito, so a static page does not need WordPress PHP just to display sign-in or account features.
Problem 2
Forms and AI are coupled to page rendering
If form processing or AI calls are proxied through WordPress, static export appears to remove those features even though the browser could call dedicated APIs directly.
Problem 3
Private content needs a separate delivery boundary
A static site still needs a way to protect selected paths or assets. That responsibility belongs at the delivery layer rather than inside page rendering.
Operational implication Classify runtime by feature: static files for pages, identity for login, protected delivery for restricted paths, APIs for dynamic actions, AI services for AI, and workflow services for forms.
Recommended architecture
Keep WordPress as the page-building system and move runtime per feature
The static frontend stays simple while browser-side components call the service responsible for each dynamic capability.
WordPress CMS
|
v
Static Publisher
|
v
S3 + CloudFront static frontend
|
+--> Gatey ----------> Amazon Cognito
+--> protected paths -> signed cookies / CloudFront
+--> Flow -----------> workflow API / Lambda
+--> AI-Kit ---------> AI backend / knowledge API
+--> app actions ----> API Gateway / Lambda
|
v
Mostly cacheable pages + selected dynamic services
Confirmed WP Suite behavior Gatey and AI-Kit run browser-side and remain compatible with static exports. WP Suite also provides static publishing, protected-delivery, and optional backend paths for dynamic features such as forms, APIs, and AI.
Decision path
Classify each site capability before choosing the runtime
Do not move a feature to WordPress PHP merely because it is interactive.
- Export the cacheable page layer — Keep WordPress as the authoring system, then publish public page output to static hosting where appropriate.
- Move identity to the browser — Use Cognito-backed browser authentication when login should continue without a live WordPress request.
- Give each dynamic feature its own endpoint — Route forms, AI, and authenticated application actions to dedicated APIs rather than proxying them through the page-rendering server.
- Protect private delivery separately — Use the CloudFront and authorization layer to control access to protected static paths instead of relying on WordPress sessions.
Static WordPress is a runtime choice, not a feature limit
Best fit
Mostly cacheable sites with selected dynamic features
- Content-heavy sites where most page views are public and identical for many visitors.
- Sites that need login, forms, AI, protected content, or secure APIs but do not need server rendering for every page.
- Teams that want to keep Gutenberg page building instead of creating a separate frontend application.
Choose another model when
The page itself requires server-side personalization
- Most page views depend on a server-side session before render.
- A separate frontend application is an explicit product requirement, making headless WordPress a better fit.
- Traditional dynamic WordPress already solves the runtime cleanly and the project does not benefit from separating delivery and services.
Common questions
Dynamic features on static WordPress
Can Cognito login still work after static export?
Yes. Gatey performs authentication in the browser against the configured Cognito User Pool, so it does not require WordPress PHP for the login flow.
Can a static WordPress site submit forms?
Yes. The browser can submit directly to a configured workflow API, provided the endpoint has the required CORS, validation, authentication, and abuse-protection controls.
Can AI still work on a static site?
Yes. AI-Kit can run locally in supported browsers or call a configured backend directly from the browser, depending on the selected mode.
Is static WordPress the same as headless WordPress?
No. Static WordPress can keep WordPress and Gutenberg as the page-building system and publish their rendered output. Headless WordPress normally introduces a separate frontend application and rendering stack.
Separate delivery from runtime
Keep the pages static and make only the features dynamic
Use the WP Suite static delivery model together with browser-side identity, AI, forms, and APIs so WordPress stays the CMS without remaining in every frontend request.