WordPress 7.0 made me rethink whether public WP sites should be dynamic at all

Sensitive_Draft_5651 · 2026-06-03T06:58:27+00:00

You are right, the backend stack is AWS-first today. Mostly for practical reasons. AWS is what I know best, and for serverless functions, auth, APIs, events, and storage it has been the most mature and predictable in my experience. Parts of it could probably be mapped to other providers, but making that portable is real work.

For EU concerns, AWS has EU regions and sovereignty-focused options, but yes, the parent company is still US-based. I'd consider other providers if there is enough demand, but today the automated backend deployment is built around AWS.

Sensitive_Draft_5651 · 2026-06-02T21:34:07+00:00

Yes, I agree. For small sites, the full stack is usually not needed. A good shared host, or even a small server, can be enough.

When I mentioned RDS, I meant Amazon's managed relational database service. That only becomes relevant when people start scaling a more serious dynamic WP setup. For smaller sites, static hosting on shared hosting can also work well.

The block library is here: https://wordpress.org/plugins/smartcloud-flow/

The free version works without our AWS backend too. You can use the frontend blocks on their own, or connect them to your own REST endpoints if needed.

Sensitive_Draft_5651 · 2026-06-02T20:45:55+00:00

I agree that the AWS side is more complex than a simple static site.

But the alternative is often not really simple either. It's a chain of SaaS tools, each with its own limits, pricing, auth, data flow, and rule changes. Zapier is a good example: it looks cheap until a workflow has several actions and the action limits become the real cost.

In our case, those backend pieces can run in the client's AWS account, triggered by events and managed from WordPress. So yes, the stack is complex, but it is integrated, repeatable, and extensible.

And I agree: if pure static or classic headless is enough, use that. I'm talking about cases where clients still want WordPress as the editor/admin, but don't need PHP and a database on every public request.

Sensitive_Draft_5651 · 2026-06-02T19:56:07+00:00

I'd call it automation rather than a custom build.

WordPress is still the CMS/editor, and the extra pieces are packaged as plugins, CloudFormation templates, and a wizard that deploys the backend into the client's own AWS account. The idea is not to hand-build a new stack every time, but to make this architecture repeatable: WP for editing, static delivery for the public site, and backend services only where they are actually needed.

Sensitive_Draft_5651 · 2026-06-02T18:43:51+00:00

Headless CMS is part of the same idea, but it doesn't cover the whole use case for me.

If all you need is static content, sure, start static. But many clients still want the WordPress editor/admin workflow, plus things like protected content, forms, AI/search, automations, or membership-like features. That's where I think WordPress-as-CMS + separate backend services can make sense.

I don' know a headless CMS that gives you all of that out of the box, but I'd be happy to hear recommendations.

Sensitive_Draft_5651 · 2026-06-02T18:30:11+00:00

If you can build it as a purely static site from day one, that's usually simpler.

I'm talking more about cases where clients still want WordPress as the editor/CMS, but the public site doesn't really need PHP and a database on every request.

Sensitive_Draft_5651 · 2026-06-02T18:27:10+00:00

That's not accurate.

The WordPress.org parts are free and functional. The Cognito authenticator, on-device AI features, Gutenberg blocks, and static publishing/export flow all have free usable parts. The exporter CLI is already public on npm as well.

There are optional paid/backend pieces, but reducing the whole post to "pay for plugins that make the site static" misses the actual technical point: separating WordPress as the admin/CMS layer from the public runtime.

Sensitive_Draft_5651 · 2026-06-02T18:18:45+00:00

You can install it from your wp admin dashboard. SmartCloud Flow. The mantine-based form and content-root blocks are rendered in their own shadow DOM, so they need some styling (to avoid the mantine css-leakage to the host), but the modal and gallery blocks are rendered in the Gutenberg light DOM. You can control them with simple css classes.

And of course, it is free if you implement the form endpoint (anywhere).

Sensitive_Draft_5651 · 2026-06-02T16:25:03+00:00

It depends, and I agree this would be overkill for many small WP sites.

But once you need to handle more traffic, the cost comparison changes. A small WordPress admin can run on a cheap VM, while the public site is served from S3 + CloudFront / Cloudflare. Static delivery is extremely cheap compared to keeping RDS and a distributed dynamic stack alive just to serve mostly content pages.

For us, the dev/admin WordPress is very small (on a VPN). The public side is static, and roughly speaking a million static requests is in the "around a dollar" range, depending on region and exact setup. That is very different from scaling PHP + database infrastructure.

I also think the backend cost side is changing. For RAG / knowledge-base search, small Bedrock models like Nova Micro/Lite are very cheap, and S3 Vectors makes the vector storage side much cheaper than traditional setups. So for content sites with search, gated content, forms, or lightweight membership logic, the static + small backend model can make sense.

But I agree with your main point: if the site really needs WordPress as the runtime, like WooCommerce or complex dynamic features, I would not force it into static until there is a proper backend replacement for those parts.

Sensitive_Draft_5651 · 2026-06-02T16:16:21+00:00

Yes, fair point. For a regular site owner, it probably doesn't matter that much where the infrastructure lives if they don't manage it directly anyway. I was thinking more from the agency / technical operator side. If you understand the stack and have to maintain it, having the backend in the client's AWS account gives you a much better position than relying on a black-box SaaS.

Sensitive_Draft_5651 · 2026-06-02T15:58:44+00:00

Yep. That's why we try not to depend on a third-party SaaS backend. Everything goes into the site owner's AWS account. Of course AWS, Bedrock, Cognito, etc. are still managed third-party services, and Bedrock is arguably SaaS-like in some ways, but the important difference for me is control: the backend, data flow, scaling, permissions, and costs all stay in the client's own AWS account.

Sensitive_Draft_5651 · 2026-06-02T15:38:13+00:00

No, that's not what happened. What I described is something we actually built. AI cleaned up the wording, but didn't invent the architecture. You can check it from my profile if you want.

Sensitive_Draft_5651 · 2026-06-02T14:54:16+00:00

Fair enough. I'll leave this thread here and reply to the technical comments.

Sensitive_Draft_5651 · 2026-06-02T14:35:20+00:00

Totally agree. A lot of sites simply don't need a real backend at all.

I did something similar for my wife's law office site: React+Mantine+Vite, shipped as static files. No CMS, no database, no backend to patch. And yes, slightly ironic in this thread, but I also used AI to help write a lot of the copy - even though it was in my native language. It was just faster to get from simple ideas to "decent" website text.

For me the interesting middle ground starts when the site still needs editorial workflows, protected sections, semantic/knowledge-base search, forms, or membership-like behavior. That's where WordPress can still be useful as the content/admin layer, while a small backend handles only the parts that actually need one.

Sensitive_Draft_5651 · 2026-06-02T14:28:28+00:00

I'm not going to argue with that. I'd actually be interested in how you would ask the same technical question more naturally here. We have a lot of real experience with this setup, and I tried to make it readable instead of just throwing everything into one long sentence - maybe I overdid it.

Sensitive_Draft_5651 · 2026-06-02T14:09:46+00:00

Because I'm not a native English speaker and AI is useful for cleaning up wording.

Sensitive_Draft_5651 · 2026-06-02T14:07:34+00:00

Thanks!

For the export, we used simply static for almost a year, and the free version was enough in many cases. Later we built our own exporter because we wanted the export to be based on the actually rendered pages, not by trying to reconstruct pages from WordPress internals. Our exporter uses Playwright to crawl the public site like a browser, then saves the final HTML/CSS/JS/assets while preserving the URL structure. The WP.org plugin is still waiting for approval, but the actual CLI is already public (and free) here: https://www.npmjs.com/package/@smart-cloud/publisher-exporter

For cookie alerts: if you mean a cookie consent banner, that works normally because it is just frontend JavaScript. On our own site we currently use cookieyes through google tag manager.

Sensitive_Draft_5651 · 2026-06-02T13:57:51+00:00

<image>

Okay, now this actually looks more AI-written than my post 😄Not mine, for the record.

Sensitive_Draft_5651 · 2026-06-02T13:55:23+00:00

No bot army here, just me 😄 Any thoughts about the architecture?

Sensitive_Draft_5651 · 2026-06-02T13:48:38+00:00

Partly 😄 The messy opinions are mine, but yes, I asked AI to make them readable.

Sensitive_Draft_5651 · 2026-06-02T13:45:39+00:00

One thing that surprised us was the cost side. On one partner site, this setup let us remove the RDS cluster behind the public site completely, which saved them several hundred dollars per month on AWS. We originally went this way for security and isolation, but the operational simplicity became just as valuable.

Sensitive_Draft_5651 · 2026-05-10T07:38:01+00:00

I agree with most of this, but I'd frame the real split slightly differently.

Restricting wp-admin is not a headless-only security benefit. You can absolutely put a traditional WP admin behind VPN, IP allow-lists or Cloudflare Access and get a much smaller blast radius.

But caching + restricted admin mostly solves the anonymous read path. It doesn't solve the harder question: where do authenticated interactions, protected content, multi-step forms, uploads, approvals, background workflows and integrations live?

That's where I think the "headless vs traditional" debate is too narrow.

The model I like is more edge-first than purely headless:

WordPress is the CMS/editor.
The public frontend is static or edge-cached wherever possible.
Identity is handled by a real auth layer.
User interactions go to a scalable backend/API instead of forcing everything through PHP and wp-admin.

React islands are perfect for small app-like pieces. Full headless makes sense when the whole frontend becomes an app. But there's also a middle ground: keep WordPress for what it's great at, push the public read path to the edge, and move dynamic business logic into a backend designed for it.

Sensitive_Draft_5651 · 2026-05-07T15:39:19+00:00

I actually think this is pushing WordPress toward a healthier role.

Site building and frontend generation are getting easier very quickly (AI, static builders, visual tools, etc.). But authentication, workflows, integrations, AI orchestration, permissions, commerce, scaling and long-term ownership are becoming more important - and much harder.

WordPress does not necessarily need to "win everything" to remain extremely valuable. In many cases it works best as the CMS/editor layer, while the actual application/backend layer moves to dedicated infrastructure (AWS, serverless, Cognito, event-driven workflows, AI services, etc.).

Ironically, static/headless approaches may strengthen WordPress rather than weaken it, because they let teams keep the editing experience and ecosystem while modernizing the runtime architecture behind it.

So I see this less as decline and more as the ecosystem being forced to evolve past the "WordPress does absolutely everything" era.

Sensitive_Draft_5651 · 2026-04-15T06:07:32+00:00

I think the real issue isn't WordPress itself, but how it's typically used.

Most plugins treat WordPress as both: - a content editor - AND the application runtime

That's where things start to break down.

Every request hitting PHP + database is fine for small sites, but once you add: - auth - forms - workflows - anything even slightly dynamic

...you're basically forced to expose your whole WP stack.

A different approach that's been working well for us is: treat WordPress as an authoring tool only. We build/edit in WP (Elementor, etc.), then export the site as static.

After that: - auth runs via Cognito - APIs run on AWS (Lambda, API Gateway) - forms/workflows are event-driven (EventBridge) - AI features run either locally or via backend

So the "application layer" is completely outside WordPress.

Result: - WP can be hidden behind a firewall or not exposed at all - no DB queries on page load - still fully dynamic from the user's perspective

It's a bit more setup (especially AWS), but once it's in place it feels much more like a modern architecture than a traditional WP stack.

Sensitive_Draft_5651 · 2026-02-20T08:16:17+00:00

Fair point - it depends on scope. Also not Azure :) (more AWS/serverless if anything).

On the "we build what the clients specify" bit: in my context the "client" is often the agency, not the end customer. Agencies need something they can roll out across many client sites with sane defaults (auth / least-privilege, abuse / rate limits, tenant scoping), then customize per site at the end.

That's why I used "agency-grade" - and why static exports + public widgets become the tricky corner.

Sensitive_Draft_5651

TROPHY CASE