In a headless build the origin's job is to answer API calls and to tell the frontend when something changed. Almost everything a normal WordPress host optimises is irrelevant here.
No theme renders here. What matters is API response time and whether your frontend hears about an edit.
Saving a post fires a webhook carrying the affected paths, so your Next.js or Astro deployment revalidates those routes instead of waiting for a scheduled rebuild or a full redeploy.
REST and GraphQL responses lean entirely on the object cache, because when the response is JSON there is no page cache in front of it to hide a slow query behind.
Preview requests are authenticated with short-lived tokens, so your frontend can render unpublished content without that content being reachable by anybody who guesses the URL.
Allowed origins are set at the edge for your production frontend and its preview deployments, which is the setting most headless builds discover is wrong on launch day.
Uploads keep serving from the WordPress origin through the edge, so changing frontend framework never means re-hosting the media library.
Headless setups end up with a production frontend, a preview deployment and a build pipeline all reading the same WordPress. The dashboard is built for that rather than for one site.
A build hits the API hundreds of times in a few seconds. That burst, rather than a visitor's page load, is the workload the origin actually has to survive.
These are the settings that differ from a standard WordPress site on the same plan. Each follows from the origin answering machines rather than browsers.
| Setting | What we do | Why |
|---|---|---|
| Full-page cache | Disabled at the origin; caching belongs to the frontend | Nothing here renders HTML, so a page cache in front of an API endpoint only adds a layer that then has to be invalidated correctly. |
| Publish hooks | Webhook fired on save carrying the affected paths | Without one the frontend either rebuilds everything on a timer or serves stale content until somebody notices and triggers a deploy. |
| Object cache | Redis, sized for repeated API reads during builds | A static build queries the same taxonomies hundreds of times within a few seconds, and every uncached one of those is a database round trip. |
| Preview requests | Authenticated with short-lived tokens rather than a shared secret | A long-lived preview key ends up committed to a frontend repository, and at that point the drafts are effectively public. |
| CORS policy | Allowed origins configured for production and preview domains | Preview deployments get a fresh hostname on every branch, and a policy written once for production blocks all of them. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Free migration, invalidation pushed on publish, and previews that never expose a draft.