Headless WordPress hosting means two things running in two places: a WordPress install that holds your content, and a separate frontend (Next.js, Astro, Nuxt or similar) that fetches that content over an API and shows it to visitors. The WordPress side needs a stable, secure, fast-responding host. The frontend needs a place to build and serve pages. Most of the work is choosing where each lives and how they talk to each other.
This guide covers the architecture, what each half needs from a host, a practical setup order, and the mistakes that cost small teams the most time.
TL;DR
- Headless WordPress keeps WordPress as the content backend (admin, database, media library) and serves the public site from a separate frontend stack.
- You host two things: the WordPress backend, which needs reliable PHP hosting with HTTPS and good API response times, and the frontend, which needs a build and serving environment.
- Secure the API with Application Passwords over HTTPS, and use webhooks so published edits reach the frontend quickly.
- Headless adds moving parts. If you do not need multi-channel delivery or a custom JavaScript frontend, a well-tuned classic WordPress site is usually cheaper to run.
- Start with the backend on managed WordPress hosting, then add frontend infrastructure once the content model works.
Table of Contents
- What headless WordPress actually is
- Why teams go headless (and why many should not)
- The two halves and what each needs from a host
- Choosing REST or GraphQL
- A practical setup order
- Authentication done safely
- Keeping the frontend fresh
- Where to host each half
- Our perspective
- Hosting your headless backend with inSave
- Mistakes that cost the most time
- FAQ
- Sources
What headless WordPress actually is
In a classic WordPress site, one install does everything: it stores content, runs the admin, renders themes and answers visitors. In a headless setup, WordPress keeps the first two jobs and drops the third. As one 2026 practical guide puts it, WordPress remains the content backend (admin, database, editorial workflow, media library) while a completely separate stack, typically Next.js, Astro, SvelteKit or Nuxt, serves the front end.
Your editors still log in to the familiar dashboard. They still write in the block editor and upload to the media library. What changes is that visitors never hit WordPress templates. Instead, the frontend asks WordPress for data and builds pages from the response.
If you searched "WordPress as a headless CMS," this is the core idea: WordPress stops being the website and becomes a content service. The Astro documentation describes the same model, noting that WordPress can supply content to an Astro project instead of rendering it.
Why teams go headless (and why many should not)
The honest reasons to choose headless are specific:
- One content source, several outputs. A website, a mobile app and a kiosk can all read the same posts.
- A custom frontend. Your developers want React, Svelte or another framework, with full control over markup and interactions.
- Static or edge delivery. Prerendered pages can be served with very little work per request.
- A smaller public attack surface. Visitors never touch the WordPress login or PHP, which reduces what is exposed to the open internet.
The honest reasons not to:
- Plugins stop doing what they did. Page builders, many SEO plugins, form plugins and previews assume WordPress renders the page. In a headless build you rebuild or replace that behavior in the frontend.
- You now run two systems. Two deployments, two sets of logs, two things that can fail.
- Editors lose easy previews unless you build a preview route.
A small business site with 20 pages and a blog rarely needs any of this. A publisher with a custom app, or a product team with a JavaScript-heavy frontend, often does.
The two halves and what each needs from a host
Think of hosting as two separate decisions.
| WordPress backend | Frontend | |
|---|---|---|
| Job | Store content, run the admin, expose the API | Fetch content, build and serve pages |
| Runtime | PHP, MariaDB or MySQL | Node.js (or static files on a CDN) |
| Traffic | Editors, build processes, API calls | Public visitors |
| Key needs | HTTPS, fast API responses, backups, security | Build pipeline, caching, fast delivery |
| Failure impact | Editing and rebuilds stall | Public site goes down |
The split matters because the backend can have modest traffic. When the frontend is prerendered, the public does not hit WordPress at all. What the backend needs is consistency: fast responses to API requests during builds, reliable uptime so rebuilds do not fail, and dependable backups, since the database is the only copy of your content.
What the backend needs
- HTTPS everywhere. The WordPress documentation states that Application Passwords should always be sent over HTTPS to prevent interception. Free SSL on the backend domain is a baseline, not a bonus.
- Fast, steady PHP and database performance. Each page build can fire dozens or hundreds of API requests. A slow database turns a one-minute build into ten.
- Object and page caching on API responses. Server-level caching reduces repeat work when the frontend requests the same content.
- Daily backups and a staging copy. When the backend is also your content model, schema changes (custom post types, fields) are risky to test on production.
- Modern PHP. Current PHP versions run noticeably better than old ones, and security fixes only land on supported releases.
- Security hardening. The admin still exists on the open internet, usually at a separate subdomain like
cms.example.com. Lock it down.
What the frontend needs
The frontend is a JavaScript application. Depending on how you build it, it is one of three things:
- Static output (prerendered at build time) served from files on a CDN.
- Server-rendered pages that run on a Node.js process.
- A hybrid, with most pages prerendered and some regenerated on demand.
The Vercel guide to headless WordPress with Next.js shows a typical pairing: prerendered HTML from WordPress content, delivered from a platform built for the frontend. Many teams do exactly that: WordPress on a managed host, the frontend on a platform designed for JavaScript deployment. Others run Node.js on a virtual private server so that everything sits with one provider.
Choosing REST or GraphQL
WordPress ships with a built-in REST API, so you can start with no extra plugins. The WordPress REST API documentation covers authentication, including the default cookie method and its nonce protection against CSRF. Cookie authentication fits code running inside WordPress. It is the wrong tool for an external frontend, which is why headless projects use other methods.
GraphQL is the other common option, added through the WPGraphQL plugin. It lets the frontend request exactly the fields it needs in one query, rather than several REST calls. For content-heavy sites with relationships between posts, authors and categories, this can cut the number of requests per build. For a simple blog, REST is enough and has one less dependency.
Whichever you pick, test response time on your host with real content, not an empty install.
A practical setup order
This is the sequence we would follow for a small team moving to headless, and it also answers the common question about how a headless setup works in practice.
- Stand up WordPress on its own subdomain. Use something like
cms.yourdomain.com. Install WordPress, enable HTTPS and set permalinks so the REST routes work cleanly. - Model your content. Define custom post types and fields before anyone writes content. Changing the model later means changing the frontend too.
- Test the API. Request a list of posts and a single post in the browser or a REST client. Confirm you get what the frontend will need: titles, slugs, featured images, categories, dates.
- Set up authentication for private data. Public posts need no credentials. Drafts and previews do. Create an Application Password for the frontend, as described below.
- Build the frontend against the API. Start with one page type, such as the blog index and a single post template, then widen.
- Wire up revalidation. Connect publish events to the frontend so edits show up without a manual rebuild.
- Redirect or block the old public site. Otherwise WordPress themes remain reachable and search engines may index duplicate content.
- Add monitoring. Watch both uptime and build failures.
Authentication done safely
For server-to-server requests, WordPress Application Passwords are the standard route. They are revocable, tied to one application, and remove the need to share a main account password. They arrived in WordPress 5.6 in December 2020, so any current install has them.
A few rules we follow:
- Create a dedicated WordPress user for the frontend with the lowest role that does the job, rather than using an administrator account.
- Keep the credential in server-side environment variables. Never ship it in browser code.
- Remember that Application Passwords are for API calls only. They will not work for logging in to wp-admin.
- Revoke and replace the password when a developer leaves.
Admin logins also deserve their own protection. Our guides on protecting the WordPress login on small sites and setting up two-factor authentication apply unchanged to a headless backend. Security headers matter on the CMS domain too.
Keeping the frontend fresh
A statically generated frontend is stale the moment someone edits a post. There are three ways to deal with it:
- Rebuild everything on each change. Simple, but slow on large sites.
- Rebuild on a schedule. Cheap, but edits wait.
- Revalidate only what changed. The best experience for editors.
The third option usually uses webhooks. When an editor publishes, updates or deletes a post, WordPress sends a request to a route on the frontend, which refreshes just that page. The HeadlessNext Connector plugin is one example: it sends an asynchronous, non-blocking webhook on those events to trigger Incremental Static Regeneration in Next.js, so the cache updates without a full rebuild.
This is where backend hosting quality shows. Webhooks fire from the WordPress process, so a slow or overloaded server delays the signal. Teams that publish often, or run several sites, also look at automating WordPress publishing and content updates, since a scripted pipeline puts steady load on both the API and the revalidation route. Plan for that traffic when you pick a plan.
Where to host each half
There is no single right answer, but there are sensible patterns.
Pattern 1: managed WordPress for the backend, a frontend platform for the rest. The backend gets caching, backups and security handled for you. The frontend deploys from Git. This is the lowest-effort route for small teams.
Pattern 2: everything with one provider. WordPress on a managed plan, and the frontend on a virtual private server running Node.js. You get one invoice and one support relationship, at the cost of managing the server.
Pattern 3: static frontend, minimal infrastructure. If your site builds to plain files, you can serve them from almost anywhere, including ordinary web hosting, and only the backend needs WordPress features.
| Situation | Suggested approach |
|---|---|
| Marketing site, a few editors, no app | Consider whether headless is needed at all |
| Blog or docs with a custom frontend | Pattern 1 or 3 |
| Multiple channels, a team of developers | Pattern 1 or 2 |
| Custom server-side logic in the frontend | Pattern 2, on a VPS or similar |
Our perspective
We manage a lot of WordPress sites, and the pattern we see is that headless projects fail on operations, not on code. The frontend gets built beautifully, then nobody owns backups for the content database, or the CMS login stays exposed with a weak password, or a PHP update breaks the API on a Friday.
So we tell customers to treat the WordPress backend as production infrastructure from day one. That means daily backups, a staging copy for schema changes, HTTPS, current PHP and a monitored uptime record. Our sites are looked after by experienced SRE and DevOps engineers in the EU and US, and we offer free migrations, daily backups and a 30-day money-back guarantee, so moving an existing site into a backend role is low risk.
We also say plainly: if your editors only need pages and a blog, you may be better off with a fast classic WordPress site. Headless is a tool for a real requirement, not an upgrade.
— Ihor
Hosting your headless backend with inSave
For the WordPress half, our WordPress hosting plans (WP Start, WP Growth, WP Pro and WP Agency) are built for this role, with free SSL, daily backups, staging tools, free migration and LiteSpeed caching. If your frontend needs a Node.js process of its own, our VPS plans give you a separate server to run it. Agencies running several client backends can read our guide to managed WordPress hosting for agencies. You can also start from our home page to register a domain for the CMS subdomain.
Mistakes that cost the most time
- Leaving the default theme public. The CMS domain should not serve a second, indexable copy of your site.
- Skipping preview. Editors will ask for it in week one. Build a draft preview route early, using authenticated requests.
- Fetching too much per request. Request only the fields you render, and paginate.
- Hardcoding the CMS URL in templates, which makes moving hosts painful.
- Using an admin account for the API. A leaked key then hands over the whole site.
- Ignoring plugin compatibility. Check each plugin you rely on, such as SEO, forms and redirects, for headless support before committing.
FAQ
Can I use shared hosting for the WordPress backend?
Often yes, because the backend sees modest traffic when the frontend is prerendered. What matters is stable PHP and database performance, HTTPS and backups. Test API response time with your real content before committing, and move up a tier if builds are slow.
Do I need a separate server for the frontend?
Not always. A fully static frontend can be served as plain files. You need a Node.js runtime only when the frontend renders pages on request or revalidates on demand, and that is where a VPS or a frontend platform comes in.
Is headless WordPress more secure?
It can reduce exposure, since visitors never reach WordPress directly, but it does not remove risk. The admin and API still sit on the internet. Use HTTPS, Application Passwords with a low-privilege user, two-factor authentication and regular updates.
Is the REST API or GraphQL better?
REST ships with WordPress and is enough for simple sites. GraphQL, through a plugin, helps when pages need related data from several content types in one request. Choose based on how many requests your pages make.
Sources
- Headless WordPress: A Practical 2026 Guide
- Headless WordPress & Astro, Astro Docs
- Using Headless WordPress with Next.js and Vercel
- REST API Authentication, WordPress Developer Resources
- Application Passwords, WordPress Developer Resources
- HeadlessNext Connector, WordPress.org