Solution · Secure static
Secure Static WordPress and Protected Client Portals
A static WordPress site can still support protected content, authenticated experiences and portal-style workflows when access control moves to AWS.
Short answer: Secure static WordPress means keeping public pages fast and static while moving login, protected access and runtime actions to identity-aware AWS patterns. The important distinction is that visibility, file access and API authorization are separate layers: hiding a section in HTML is not the same as protecting a path, and protecting a path is not the same as authorizing an API action.
Why this matters
Static sites are attractive because they reduce the public WordPress attack surface, but many real projects still need gated documentation, client-only downloads, profile-aware content or authenticated form flows.
Classic membership plugins often assume WordPress is serving every request. That assumption breaks when pages are exported to S3 and CloudFront.
A safer architecture separates public static delivery from identity, signed access and API authorization. WP Suite Static Site Guardian turns that separation into a deployable AWS pattern: you define protected path rules and Cognito group mappings first, then the deployment creates the CloudFront behaviors and cookie-signing flow around that plan.
Architecture and data flow
Protected path plan + Cognito group mapping
↓ configured in Deployment Wizard
Static Site Guardian stack
↓ creates CloudFront behaviors + signer flow
Visitor browser → Gatey Authenticator → Cognito User Pool
↓ current groups / token context
Cookie signer edge Lambda
↓ scoped signed cookies
CloudFront + S3 protected static paths
Access layers to separate
| Layer | What it protects | Typical mechanism | Important boundary |
|---|---|---|---|
| Public static pages | Marketing, docs and SEO pages | CloudFront + S3 | No user-specific secrets should be embedded in generated HTML. |
| Login experience | Who the visitor is | Gatey + Cognito | Authentication proves identity, but does not automatically grant access to every resource. |
| Protected static paths | Private downloads or portal sections | Static Site Guardian, CloudFront behaviors and signed cookies | The deployment should already know which paths map to which Cognito groups. |
| Runtime actions | Forms, profile updates, AI requests, client operations | API Gateway / Lambda / authorized backend | The API must validate tokens or IAM credentials on every request. |
| Editorial WordPress | Admin and publishing workflow | Private WordPress origin | The CMS should not be the public runtime for protected static visitors. |
Capability map
Identity layer
Gatey
Browser-side Cognito sign-in, sign-up, MFA, SSO and account attributes; no PHP OAuth callback requirement for the frontend flow.
Publishing layer
Static Publisher
Publishes public pages and assets to S3/CloudFront while WordPress remains the control plane.
Protected path stack
Static Site Guardian
Creates the CloudFront cache behaviors for protected paths and issues signed cookies according to the configured Cognito group mapping.
Runtime add-ons
Flow and AI-Kit
Authenticated forms, workflows and AI features can call configured APIs when the visitor is allowed to interact with them.
Decision table
| Mode / dimension | Best for | Data path / approach | Trade-off |
|---|---|---|---|
| Public static pages | Marketing and documentation content | CloudFront → S3 | Fastest and lowest runtime surface |
| Authenticated frontend UI | Login, profile, gated widgets | Browser → Cognito | Requires browser-side identity configuration |
| Protected files or paths | Client portals, private downloads | Static Site Guardian + CloudFront signed cookies | Path-to-group mapping is configured before deployment, not solved by editors after publishing |
| Authenticated APIs | Forms, account data, workflows | Browser → API Gateway/Lambda | Requires token validation and authorization rules |
How this differs from the usual approach
PHP-session model
Traditional membership plugin
Often simple inside dynamic WordPress, but expects PHP request-time logic.
Simple gate
Password-protected static files
Can hide assets, but does not provide modern user identity, SSO or API authorization.
Edge-protected model
WP Suite secure static model
Combines static delivery, Cognito identity, Static Site Guardian behaviors and selected AWS runtime services.
When this is a good fit
- Client portals where public pages should be static but selected areas need login.
- Documentation sites with private sections that can be mapped to Cognito groups.
- Agency projects where protected-path rules should be repeatable across environments.
- Static sites that need authenticated API calls, protected downloads or license/config refresh without reintroducing public WordPress runtime.
When not to use this
- A fully dynamic application where every view is personalized server-side.
- A site that only needs a single shared password for temporary preview.
- Projects that cannot define protected URL patterns, Cognito groups or access rules before deployment.
Implementation path
- Define public paths, protected paths and the Cognito groups allowed to access each protected area.
- Configure those path-to-group rules in the Static Site Guardian deployment wizard.
- Configure Cognito and Gatey for browser login and account state.
- Deploy the Site Guardian stack so CloudFront behaviors and the cookie signer are created from the access plan.
- Publish public and protected static output using Static Publisher.
- Use authenticated API calls for dynamic portal actions, and test expired cookies, group changes and cache boundaries.
Practical implementation checklist
- Define which URLs are public, which are login-only, and which require group-based signed-cookie access.
- Keep the protected content plan outside the editor workflow: editors should publish content, not handcraft CloudFront cache behaviors.
- Let Static Site Guardian issue signed cookies only for the paths and duration allowed by the current user’s Cognito groups.
- Keep API authorization separate from page visibility: every API endpoint should validate the caller independently.
- Test failure modes: expired cookies, changed group membership, logged-out refresh, direct S3 URL access, copied private URLs and blocked third-party cookies.
Pro configuration and license refresh
Static Site Guardian can also refresh the WP Suite Pro configuration and license file from wpsuite.io on a weekly schedule. The site key used for that refresh is stored in AWS Systems Manager Parameter Store as a SecureString, so the static site does not need a manual monthly license-file maintenance step.
Common mistakes to avoid
- Do not rely on JavaScript-only hiding for sensitive content. It improves UX, but it is not access control.
- Do not use one broad signed cookie policy for every private asset if different user groups need different access boundaries.
- Do not postpone protected-path design until after publishing. With Static Site Guardian, the deployment should create the right CloudFront behaviors from the protected content plan.
Related resources
Gatey
Cognito login, SSO, MFA and browser-side authentication
WordPress SSO with Amazon Cognito
federated identity and enterprise SSO use case
Secure Static WordPress with Signed Cookies
Static Site Guardian, signed cookies and protected-path architecture
Gatey vs WordPress SSO plugins
SSO decision support
Docs
shortcodes, blocks, CSS variables and JavaScript API
Static Publisher
product page for crawl, rewrite, deploy and invalidation workflows
FAQ
What is Secure Static WordPress?
Secure static WordPress means serving public or protected pages from a static AWS edge layer while moving access control and runtime behavior to services such as Cognito, CloudFront and API endpoints. In WP Suite, Gatey handles frontend identity, while Static Publisher and AWS patterns keep the public WordPress runtime out of the request path.
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.
Can a static WordPress site have members?
It can support authenticated experiences, but the membership model should be designed around external identity and APIs rather than PHP-only WordPress session state.
Does Gatey store secrets in WordPress?
Gatey is designed around browser-side Cognito flows. The public frontend does not need WordPress to store server-side OAuth secrets for the login flow.
Can CloudFront protect static files?
Yes. Static Site Guardian is designed to create the CloudFront behaviors for protected paths and use a cookie signer to issue signed cookies according to the configured path-to-Cognito-group mapping.
Is this the same as a classic membership plugin?
No. Classic membership plugins usually run inside WordPress request handling. This architecture keeps static delivery separate from identity and protected runtime APIs.
Can a static WordPress client portal be secure?
Yes, if the private assets and actions are protected outside the generated HTML. The safe pattern is static delivery for public content, Cognito for identity, Static Site Guardian for protected static paths, API-level authorization for runtime actions, and no direct public access to private S3 objects.
Build protected WordPress experiences on a static AWS edge layer
Use static WordPress delivery with Cognito login, protected paths, signed access and AWS-native runtime services for secure client portals.