A client called me last week. Sharp guy, but he’d been down a rabbit hole of ‘modern WordPress’ articles about bleeding-edge tech. He wanted to go “headless and serverless” to “scale effortlessly” and “future-proof” his growing e-commerce site. Sounded like a solid plan on paper, right? The problem was he didn’t realize he was mixing up two separate architectures, assuming they came as a package deal for some magical performance boost. That’s a common trap with these buzzwords.
I’ve been wrangling WordPress for well over a decade, and this confusion comes up again and again. Clients hear “less” and assume it means “less complexity,” when it usually means a different kind of complexity. Here is what each term actually means for WordPress, and, more to the point, what it means for your projects.
Understanding headless WordPress architecture
Start with headless WordPress. “Headless” means you decouple the frontend (the “head,” or what your users see, like themes and templates) from the backend (the “body,” meaning your WordPress core, database, and content management). Traditionally WordPress is a monolithic application where the frontend and backend are tightly integrated. Going headless severs that connection.
Instead of WordPress rendering the HTML, a separate frontend application, built with JavaScript frameworks like React, Vue, or Next.js, takes over that job. That frontend talks to your WordPress backend through its REST API or GraphQL to fetch content. WordPress becomes a content store that feeds data to whatever interface you choose. This gives you a lot of flexibility for custom interfaces and integrations, but it also adds a new layer of development and maintenance.
What serverless WordPress actually is
Serverless WordPress is a different thing entirely, though it often gets lumped in with headless. The “serverless” label is misleading, because there are still servers involved; you just aren’t managing them. It relies on Function-as-a-Service (FaaS) platforms, usually from cloud providers like AWS Lambda, Google Cloud Functions, or Azure Functions.
With serverless, you deploy individual functions that run only when triggered, and you pay only for the compute time they use. That helps a lot with scaling and cost, especially for sites with unpredictable traffic. Instead of a dedicated server running 24/7, your WordPress install, or parts of it, spins up only when a request comes in. The question isn’t what your frontend is built with, but how your backend handles requests and scales. Set up badly it is a nightmare, but done right it performs well, as Carl Alexander lays out at carlalexander.ca.
# Example: A typical API request to a (potentially serverless) WordPress backend
curl -X GET "https://your-wordpress-api-endpoint.com/wp-json/wp/v2/posts?per_page=5" \
-H "Accept: application/json"How headless and serverless relate
The key point: headless and serverless are often discussed together, and they can work well together, but they don’t depend on each other. You can run a headless WordPress site on a traditional LAMP stack server. And you can run a serverless WordPress install that isn’t headless, still using a classic WordPress theme to render the frontend, like the Ymir blog this post started from.
The confusion comes from the fact that modern decoupled frontends (headless) fit neatly with a serverless deployment for static assets, and the API calls to the WordPress backend can be routed through serverless functions too. But going headless doesn’t require going serverless, or the other way around. Each has its own trade-offs and its own best uses.
So, what’s the point?
The takeaway is clarity. Before chasing “headless and serverless,” understand what each choice actually involves. Do you want full control of the frontend and integration with complex UIs? That’s headless. Are you trying to cut infrastructure costs, handle traffic spikes, and get out of server management? That’s serverless. Sometimes you need both. Often you only need one, or neither.
This stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, get in touch with my team. We’ve probably seen it before.
