WordPress Headless CMS: Astro Front End, wp-admin Stays

In short

Headless means WordPress stays and the theme goes. Your editors keep working in wp-admin. What visitors see is built by Astro and delivered as static HTML. Day-to-day editing does not change.
Two ways to reach the content. The WP REST API ships with WordPress core and needs no installation. WPGraphQL is an additional plugin that fetches nested data in a single typed query. Both work – the choice follows your content model, not taste.
Build time or request time. The default is static: a webhook on publish triggers the build. Content that has to be correct in the same second is served through individual server-rendered routes.
Draft preview is the genuinely hard part. It stops working on its own and has to be built. A proposal that stays quiet about preview is selling a project your editors will reject three months in.
Front-end plugins stop applying. Anything that used to render output – page builders, sliders, forms, cookie banners, popups – no longer renders. Every plugin needs a decision: rebuild, replace or retire.
Sometimes headless is the wrong answer. On small sites, on page-builder layouts, and when nobody will own the build pipeline. Then you are better off staying on WordPress – or leaving it entirely: WordPress to Astro migration and Astro CMS.

01 — For your editors

What changes – and what explicitly does not.

Most resistance to a headless project comes from the editorial team rather than from engineering: "do we have to learn everything again?" No. Here is what the working day looks like afterwards, point by point.

Gutenberg stays Gutenberg – Posts and pages are still written in the editor your team knows, with the same blocks, the same categories, the same templates. Same login, same wp-admin address, same keyboard shortcuts.
The media library stays – Images are still uploaded to and managed in WordPress. Astro pulls them in as remote images, which means your WordPress domain gets authorised in the Astro configuration. From there they run through Astro's built-in image handling, which infers dimensions and avoids layout shift.
Roles and approvals stay – Author, editor, administrator: your permission structure carries over unchanged. Anyone who could not publish before still cannot. Backend approval workflows keep running exactly as configured.
The publish button does something new – It still writes to the database – and additionally fires a webhook that rebuilds and redeploys the site. Between click and visibility there are now minutes instead of seconds. That is the one difference people genuinely notice, and it belongs in the kickoff conversation, not in a footnote.
Preview looks different – The preview link no longer points at a theme but at a purpose-built preview route in the Astro project. This can be solved cleanly – but only if somebody builds it and it is in the budget. The honest detail is further down this page.
Front-end plugins stop applying – A plugin that used to write HTML into the page no longer has a front end to write into. Plugins that work in the back end only – custom fields, workflows, SEO metadata, translation management – keep running and hand their data over through the API.

What visitors get

Static HTML as the default delivery. Astro strips client-side JavaScript from components until something asks for it; interactive pieces arrive as individual islands, only where they are needed.

What you can lock down

WordPress no longer serves public traffic. That lets you put the instance behind access control, move it to smaller hosting, or place it inside an internal network. Updates remain mandatory – WordPress is not gone, only invisible.

Who owns the pipeline

The new moving part is a build and deploy process that somebody has to watch. Either your team or ours: Astro support and maintenance.

02 — Getting at the content

WP REST API, WPGraphQL – or leaving WordPress entirely.

There are two established ways to connect. The third column sits next to them on purpose: keeping WordPress is a decision, not a given. Read the last row first.

Headless WordPress is not automatically right just because WordPress happens to be in the building. The other CMS families are covered on Astro CMS.
Dimension	WP REST API	WPGraphQL	Leaving WordPress
Prerequisite	Part of WordPress core. Nothing to install – the endpoints under `/wp-json/` already serve posts, pages, media and taxonomies.	An additional plugin exposes a GraphQL endpoint. Custom fields and custom post types usually need further extensions on top.	No WordPress in operation at all. Content lives in the project as files: Markdown, MDX, JSON or YAML.
Shape of the query	Fixed resources per endpoint. Post, author, term and featured image are separate: either several requests, or one embedded response that returns more than the page needs.	One query describes exactly the fields the page needs, across relationships. Fewer requests, smaller responses, less reshaping inside the build.	No network access. `getCollection()` reads entries straight from the project at build time, with caching built in.
Type safety	The response shape is documented but not typed. We validate it on read, so an unexpectedly missing field breaks the build instead of quietly producing an empty page.	The schema is introspectable and types can be generated from it. In practice this is the main advantage over REST, especially with many content types.	A Zod schema in `src/content.config.ts`. Astro validates every file in a collection and derives TypeScript types automatically.
Custom fields	Have to be exposed or registered for REST output. Anything not exposed is simply missing from the response – a classic first-day surprise.	Also need registering in the GraphQL schema, usually through an add-on to the field plugin.	Are just fields in the schema. No exposure step, no second model to keep in sync.
Draft preview	Possible, but bespoke: an authenticated fetch of the draft plus a server-rendered preview route in the Astro project.	Equally bespoke, at comparable effort. GraphQL does not solve preview for you – this cost is independent of the API choice.	Handled by the deploy previews of your host or by the interface of a Git-based CMS.
Operational load	WordPress plus the Astro build. Two systems, one interface, two update cycles.	WordPress plus a plugin plus the Astro build. One more plugin to update, test and occasionally migrate.	Only the Astro project. One system less to run – in exchange for an editing route that has to suit the team.
Fits when …	The content model is manageable, the standard types largely cover it, and you would rather not add plugins.	Many content types, many relationships and many fields come together – and a team exists that wants to maintain the queries.	The editorial team is small and technical and you want one system less: WordPress to Astro.

03 — Process

How the move to an Astro front end runs.

Six steps. The order is deliberate: the uncomfortable decisions sit at the front, not two weeks before launch.

Take inventory

We count what is actually there: content types, custom fields, active plugins, templates, languages, URLs. The result is a list in which every plugin gets a decision – rebuild in the front end, replace with a service, retire, or leave running in the back end only. That list is the most honest part of the proposal, because it makes the real effort visible.

Pick the API and cut the content model

REST API or WPGraphQL, which fields get exposed, how responses are validated on read. We wrap the access in a data layer of its own, so a later change of API – or even of CMS – hits that layer instead of every single page.

Build the front end in Astro

Layouts, components and page templates are built fresh. Interactive pieces become islands and load only when required: immediately, when the browser is idle, or once they enter the viewport. Images from the WordPress media library run through Astro's image pipeline via the authorised domain. More on that on Astro web development.

Decide rendering per route

Static is the default: everything is prerendered. For routes that must be fresh at request time – preview, search, personalised areas – we set export const prerender = false and add the adapter for the target runtime. Plus the webhook that triggers a build on publish.

Solve the edge cases

Preview, forms, search, comments, metadata from your SEO plugin, sitemap and feeds. This is the part proposals like to omit and projects like to escalate over. We work through it before launch, not after.

Switch over and measure

The URL structure comes from WordPress and usually stays identical; where it changes, a redirect plan comes with it. We measure your Core Web Vitals before and after the switch, with field data from your own visitors rather than third-party benchmarks. Then we either take over maintenance or hand over to your team. For larger rollouts with several parties involved we can run the IT project management.

04 — Timeline

How long this takes – and what moves the range.

We quote prices only after the inventory, because before that they would be guesses. Timelines we can give you upfront. The ranges below are our own experience for our way of working, counted from kickoff, with one person on your side who is allowed to decide.

Inventory and decisions: 1–2 weeks – Counting content types, listing fields, assessing plugins, choosing the API, counting templates. It ends with a plugin list carrying one decision per line and a scope you can argue with before anything is built. These two weeks save more time later than they cost.
Manageable content model: 4–6 weeks in total – Posts, pages, one or two custom post types, mostly standard fields, one language, five to eight unique templates, forms and a working draft preview. This is the most common shape for company sites under roughly a hundred pages.
Typical company website: 7–11 weeks in total – Several content types with custom fields, twelve to twenty unique templates, search, downloads, a careers area, metadata from your SEO plugin, an editorial team with approval stages. The bulk of the work sits in the templates, not in the API connection.
Large or multilingual model: 12 weeks and up – Two or more languages with their own URL logic, many relationships between content types, connections to CRM, newsletter or inventory systems, several approval stages. Multilingual is the single most reliable way to stretch a range – it touches content model, routing, preview and redirects at the same time.
Not included in the range: plugins with their own front end – Membership areas, course platforms, booking systems, a shop checkout. That is no longer a front-end swap but a rebuild, and it gets estimated separately. If something like that is in play, we say so during the inventory, not during acceptance.
Switchover day itself: one morning – Cut over, check redirects, submit the sitemap, ping IndexNow, watch Search Console. Your existing site stays online until then, and the switch happens only once the new build has completed without errors.

What stretches the range

Every additional unique template. Every additional language. Content that gets rewritten rather than carried over. Every outbound integration. And custom fields that still have to be exposed to the API.

What shortens it

An existing design system, a small number of genuinely distinct templates, a content model that has already been tidied up – and a willingness to retire plugins instead of rebuilding them.

Approvals are the usual delay

Not the engineering, but waiting time: design sign-off, copy approval, feedback from the editorial team. We schedule fixed approval points. If one sits for a week, everything behind it moves by a week – that is scheduling, not a threat.

After the switch

We watch indexing, error pages and Core Web Vitals for the first four to eight weeks. Because a headless rebuild usually keeps the URL structure identical, the risk is smaller than in a real platform change. It is still not a promise.

05 — Decision

When headless WordPress holds up – and when it does not.

We also build projects with no WordPress at all, and we work in Webflow just as happily. So we have no stake in where you land. Read both columns and count where more points apply to you.

Headless WordPress fits when …

The more of these apply, the clearer the case for a decoupled front end.

Your editorial team knows and likes WordPress – and retraining would be the real source of resistance in the project.
The site is large enough that load time, attack surface and plugin maintenance are producing genuine cost.
There are several editors, approval stages or languages – exactly what an editorial system exists for.
The front end needs to be more ambitious than a theme sensibly allows: custom interactions, a real design system, your own components.
Content will be reused across channels – website, app, partner portal, newsletter, screen in a showroom.
Somebody owns the build pipeline: your team, a service provider, or us.
You want to harden WordPress by removing it from the public internet.

Headless WordPress does not fit when …

Then decoupling costs more than it returns. We would rather say so before the proposal than during acceptance.

The site is ten pages and a blog. Headless doubles the moving parts here without anybody noticing a gain.
Your team builds layouts with a page builder – Elementor, Divi, WPBakery and relatives. That is precisely the capability headless removes: layouts now come from code, not from the back end.
Nobody owns the pipeline. A build that no one watches is the outage waiting to happen.
The real functionality lives in plugins with their own front end: membership areas, course platforms, booking systems, a shop checkout. That is no longer a front-end swap, it is a rebuild – and has to be priced as one.
You expect it to be cheaper. Running costs can drop; the migration itself is an investment.
You publish several times an hour and every change must appear instantly – with no budget allocated for server-rendered routes.
What you actually want is one system less. Then the honest route is to leave WordPress altogether.

06 — The hard part

Preview and publishing: the part most proposals skip.

Connecting WordPress to Astro is routine engineering. What headless projects actually fail on is the editorial experience after launch. That is why this section sits here and not in the small print.

Why preview breaks

In classic WordPress, preview is almost free. The theme renders the draft with the same code that produces the live page, and because editor and front end live in the same system, WordPress already knows the editor session. Headless takes all three of those apart. The draft exists only in the WordPress database. The front end is a different program running on a different domain. And the draft is not publicly readable through the API, because otherwise anyone could pull unpublished content.

The result is familiar to anyone who has inherited a badly built headless project: the preview button in wp-admin points at nothing, at the ruins of a theme, or at the last build of the live page. Editors stop previewing, publish straight away and fix afterwards. That is exactly how headless earns its reputation for being awkward.

How we put it back

The approach is the same whether content arrives over the REST API or over WPGraphQL. In the Astro project we build a server-rendered preview route: a route with export const prerender = false that renders fresh on every request and therefore needs an adapter for the target runtime. That route fetches the draft from WordPress with authentication – an application password or a token that only ever exists server-side and never reaches the browser. It then renders the draft through the same components the build uses. That last point is the one that matters: a preview built from its own templates shows something other than the eventual result, which is worse than no preview at all.

Two smaller pieces of work come with it. First, the preview link in wp-admin has to be redirected to that route, so the button does what it says. Second, the route needs access protection so unpublished content is not reachable by guessing a URL. Neither is dramatic – but both are work, and they belong in the proposal as a line item.

Publishing: seconds become minutes

In normal operation, publishing in WordPress fires a webhook that starts a new build. The build fetches content, renders the affected pages and gets deployed. For a typical company website that takes minutes. The previous version stays online until the new build has completed without errors, so build time is not downtime.

Two things we say up front. First, changes that touch many pages – a renamed category, a new footer line, a replaced author photo – create a correspondingly large amount of work in the build. Second, if your team genuinely cannot live with a price change taking a few minutes to appear, that is not an argument against headless. It is an argument for server-rendering the specific routes where it matters. Mixing the two is expected practice: most of the site static and fast, the volatile parts rendered on demand. What that means for load times is covered on Astro performance optimization.

Forms, search, comments, metadata

Forms are the most common blind spot. Until now a form plugin produced the markup, accepted the submission, filtered spam and sent the confirmation email. Without a theme front end, the first part disappears. There are three clean routes: rebuild the form in Astro and post to the plugin endpoint, hand it to a form service, or build a server-rendered route that handles validation, spam protection and delivery itself. Which one fits depends on where submissions need to land and which data-protection rules apply – and that is a decision, not a detail.

The same shape of question applies elsewhere. Search used to come from WordPress; headless, it becomes either an index generated at build time, a server-rendered route querying WordPress, or an external search service. Comments can be read and written through the API or moved to a service. Metadata from your SEO plugin is normally available through the API, but it has to be read and set in the Astro layout, otherwise you quietly lose your titles and descriptions on switchover day. Sitemap and feeds are generated by Astro from then on, not by WordPress.

Hosting: WordPress moves backstage

Once WordPress serves no public traffic, the operating picture changes fundamentally. The instance no longer has to absorb traffic spikes, because visitors receive static HTML from a CDN. It can move to smaller hosting, sit behind basic authentication or an IP restriction, or go into an internal network entirely. For many operators this is the real win: the most frequently attacked surface of a WordPress installation is the publicly reachable front end.

We still draw the limit clearly. WordPress is not gone afterwards. It still needs updates, backups and somebody who feels responsible – just without the time pressure that a publicly reachable installation carries. If what you really want is to be rid of WordPress, do not go headless; move off it properly.

Editing by chat – the AI stack on top

We do not only build with Astro; we put a modern AI stack on top of it. In practice that means your website can be edited by chat, for example through a Telegram bot. Change a paragraph, add a blog post, swap an image, correct a price – as a message rather than a CMS session. It works because the content sits in a machine-addressable model: either your headless WordPress with its API, or typed content collections validated with Zod. In both cases an agent knows which fields exist and which formats are valid. It can only write what the model allows; a bad edit fails validation or the build, not the live page.

With headless WordPress such a change lands where your editors expect it – as a draft or a post in wp-admin, with the history WordPress keeps anyway, and then through the same webhook into the build. With content collections it lands as a reviewable commit with history and rollback. The point is the same either way: if you can send a voice message, you can maintain your website. That helps a large organisation with an editorial team just as much as the sole trader who will never open a CMS.

And the limits, so this does not turn into marketing noise. The chat route does not replace an editorial system with multi-stage approvals; it complements one. Editorial responsibility stays with you – an agent proposes and writes, it does not decide. Structural changes such as new page types, navigation or layout remain development work. And scope is defined per project: which content types, which fields, which approval stage. That chat agents are day-to-day work here rather than slideware is something you can check: we run a WhatsApp AI agent in real use. What the whole thing looks like for a website is on edit your website by chat.

Preview is scope

We price it as its own line item. A headless proposal without a preview position is either incomplete or betting that your editors will not miss it.

Build time is not downtime

While a new build runs, the current version stays online. The switch happens only once the build completes without errors.

Evidence, not promises

We measure your Core Web Vitals before and after the switch, using field data from your own visitors. Third-party benchmarks say nothing about your site.

Cost drivers

Effort follows three things: the number of content types, the number of plugins producing front-end output, and the depth of editorial features. There is a framing on Astro development cost.

07 — At a glance

Headless WordPress on Astro at a glance.

The short version of this page. If you read one row, read the last one.

Two comparisons alongside: Astro vs WordPress weighs the platforms, Astro CMS weighs the CMS families.
Dimension	How it looks with an Astro front end
Editing system	WordPress stays. wp-admin, Gutenberg, media library, categories, roles and approvals unchanged. The only new thing is the path between “Publish” and the visible page.
API connection	WP REST API from core, or WPGraphQL as an additional plugin. We keep the access in a data layer of its own, so a later change of API hits one file instead of every page.
Delivery	Static HTML by default, with no PHP and no database query per visitor. Individual routes are server-rendered through `export const prerender = false` plus an adapter, wherever content has to be correct at request time.
Publishing	A webhook triggers the build: minutes rather than seconds until a change is visible. The previous version stays online until the new build completes without errors. Build time is not downtime.
Draft preview	Does not work on its own. It needs a server-rendered preview route using the same components as the build, an authenticated fetch, a redirected preview link in wp-admin and access protection. With us it is a separate line item in the proposal.
Plugins	Back-end plugins keep running and expose their data through the API – custom fields, workflows, SEO metadata, translations. Anything producing front-end output needs a decision: rebuild, replace or retire.
Operations and security	Two systems instead of one – in exchange for no publicly reachable WordPress. The instance can sit behind access control, on smaller hosting, or inside an internal network. Updates and backups stay mandatory.
Timeline and cost drivers	4–6 weeks for a manageable content model, 7–11 for a typical company website, 12 and up when multilingual or large (details). Cost follows the same variables: content types, unique templates, plugins with front-end output, languages, editorial features. Framing on Astro development cost.
Our take	Headless pays off when WordPress stays because your editors want it – not because it happens to be there. With several editors, approval stages or languages we recommend the route. With ten pages, with page-builder layouts, or when nobody will own the build pipeline, we advise against it. And if preview gets cut from the budget, this is the wrong project: then stay on WordPress or leave it entirely. We build both, so we have no reason to push you either way.

08 — FAQ

Frequent questions about WordPress as a headless CMS.

What does "WordPress as a headless CMS" mean?

Headless means WordPress still manages the content but no longer produces the public website. Instead of a theme, a separate front end – here Astro – fetches the content through the API and builds the pages from it. The head, meaning presentation, is separated from the body. Astro documents this route in a dedicated CMS guide for headless WordPress, so it is a supported path.

Does anything change for our editors?

Almost nothing in daily work: same login, same wp-admin, same Gutenberg editor, same media library, same roles and approvals. Two things do change noticeably. First, after publishing it takes minutes rather than seconds for a change to be live. Second, draft preview points at a purpose-built preview route, which has to be set up beforehand.

WP REST API or WPGraphQL – which should we use?

The REST API ships with WordPress core and needs no installation; it is enough for a manageable content model. WPGraphQL is an additional plugin that fetches nested data in a single query and exposes an introspectable schema you can generate types from. With many content types and relationships that saves a lot of reshaping in the build. In exchange it is one more plugin to maintain.

Does draft preview still work?

Yes – but only if it gets built. We set up a server-rendered preview route in the Astro project that fetches the draft from WordPress with authentication and renders it through the same components the build uses. Add a redirected preview link in wp-admin and access protection for the route. This is the single most involved piece of a headless project, and we quote it separately.

What happens to our plugins?

It depends where they work. Plugins that act in the back end only – custom fields, workflows, SEO metadata, translation management – keep running unchanged and expose their data through the API. Plugins that render front-end output – page builders, sliders, forms, cookie banners, popups – stop applying, because there is no theme front end left. Each one gets an explicit decision from us: rebuild, replace or retire.

Does the site have to rebuild on every publish?

In the static default case, yes: a webhook triggers a build on publish, it takes minutes and runs in the background, and the previous version stays online meanwhile. Where that is not good enough – prices, availability, appointments, preview – we render individual routes on demand with export const prerender = false and a suitable adapter. Both approaches mix inside one project.

Will we lose rankings in the switch?

Not if the work is done properly. The URL structure comes from WordPress and normally stays identical; where it changes, a redirect plan is part of the job. Titles, descriptions and structured data from your SEO plugin are read through the API and set in the Astro layout, and sitemap and feeds are produced by Astro afterwards. We measure Core Web Vitals before and after with your own field data.

When should we stay fully on WordPress – or leave it entirely?

Stay if the site is small, if your team builds layouts with a page builder, or if nobody will look after the build pipeline. Leave WordPress entirely if the editorial team is small and technical and you want one system less – then content collections are simpler than any API. Both routes are covered on Astro vs WordPress and WordPress to Astro.

“Does the preview really show the final result – or only an approximation?”

The final result, if it is built properly. Our preview route renders the draft through the same Astro components the build uses: same layouts, same blocks, same CSS. The only difference is the data source – the unpublished draft instead of the last build. A preview made from its own templates would be worse than none, because it creates trust it cannot honour.

“Does preview also work for scheduled posts and for edits to already published pages?”

Yes, both are in scope – and both are what proposals tend to forget. Scheduled posts sit in WordPress with their own status and are reachable through the same authenticated fetch. For edits to published pages WordPress works with revisions: the preview has to request the latest revision explicitly rather than the published version, otherwise your editors cannot see their own change. We test both cases before handover.

“We have 4,000 posts. Will the build not become unusably slow – and what happens if it fails?”

Four-digit post counts are normal operation, but they need planning. We fetch content page by page rather than in one enormous response, and we test early against your real data instead of ten sample posts. How long a build actually takes we measure in the project rather than promise beforehand. If a build fails, nothing is deployed: the previous version stays online, we get an alert, and we fix the cause. No downtime is created by that.

“We use ACF. Do our custom fields come along?”

Yes, but not by themselves. Fields from ACF and similar plugins have to be exposed for output: for the REST API through the corresponding setting or field registration, for WPGraphQL through an add-on that lifts the fields into the schema. Anything not exposed is silently missing from the response. That is why our inventory lists every field group individually – including repeaters and flexible content, which are genuine rebuild work in the front end.

“What happens to our Gutenberg blocks?”

Your editors keep working with the same blocks; they simply get rendered somewhere else. The API returns either the finished HTML of a post or, more cleanly, the block structure with its attributes. We rebuild the block types you actually use as Astro components and map them across. The effort follows the number of block types in use, not the number of posts. Custom and reusable blocks work too, but each needs a decision.

“Our metadata lives in Yoast or Rank Math. Do we lose it at switchover?”

Not if it gets read. Both plugins work in the back end and keep running headless; titles, descriptions, canonicals, robots directives and Open Graph fields are reachable through the API, in WPGraphQL through the matching extension. Those fields have to be set in the Astro layout, otherwise defaults take over and you quietly lose metadata you maintained for years. Sitemap and feeds are produced by Astro afterwards. We check this in staging page by page against the old state.

“Once WordPress has no public front end – how do we lock the instance down?”

In stages, depending on how your editors work. Common measures: wp-admin restricted to known networks, VPN or an upstream basic authentication; write access to the API only with an application password or token; anonymous reads restricted; XML-RPC off; two-factor sign-in for all editorial accounts; a separate subdomain away from the public one. What remains: updates and backups. An invisible WordPress installation is not yet a maintained one.

“Can we take this in-house later? We have WordPress developers but nobody with Astro experience.”

Yes, and the step is smaller than it sounds. An Astro component is essentially HTML with a script section above it; anyone who has built PHP templates finds their footing quickly. For interactive pieces your team can use the UI framework it already knows – React, Preact, Svelte, Vue, SolidJS and Alpine.js are supported as official integrations. We hand over repository, documentation and an onboarding session, and stay available as a fallback: Astro support and maintenance.

“What happens if you disappear, or if we part ways?”

Then you carry on without us. Repository, hosting accounts, domains and the WordPress instance run in your name, not ours – we receive access, we do not grant it. The project is an ordinary Git repository with standard tooling: Astro, Node, a host of your choosing. There is no proprietary layer in between that only we can operate. Handover includes documentation of the content model, the preview route and the deploy path.

“Who is liable if something breaks after launch?”

For what we built, we are – within the warranty period agreed in the contract, and in the first weeks after switchover we are watching closely anyway. Clearly separate from that is what sits outside our work: a WordPress or plugin update that changes an API, a change made on your side, an outage at your host. We fix those under a maintenance agreement, but they are not warranty cases. That is stated in the proposal, not in the small print.

Is Astro free?

Yes. Astro is free and open-source software under the MIT licence, so there are no licence fees for the framework itself. Costs come from development, hosting and operation – and in the headless case additionally from the WordPress instance that keeps running.

Can WordPress be used headless?

Yes. The REST API is part of WordPress core, and the endpoints under /wp-json/ are there without installing anything. Astro lists headless WordPress as a CMS guide of its own. For typed queries, WPGraphQL comes in as an additional plugin.

What is WPGraphQL?

A plugin that gives WordPress a GraphQL endpoint. Instead of several REST calls, a single query describes exactly the fields a page needs – across post, author, taxonomies and custom fields. The schema is introspectable, and types can be generated from it.

Does headless WordPress need two hosting environments?

Usually yes: WordPress stays on PHP hosting, while the Astro front end is delivered statically through a host or a CDN. In exchange the WordPress hosting can be smaller – it no longer serves visitors, only editors and the build.

Is headless WordPress more secure?

The attack surface gets smaller, because the publicly reachable front end disappears and visitors receive static HTML. It only becomes more secure once the instance is genuinely shielded and still updated. Without updates, an invisible installation is vulnerable too.

How long does a headless migration take?

For a manageable content model we plan 4–6 weeks, for a typical company website 7–11 weeks, and from 12 weeks upwards with several languages or a large content model. Plugins with their own front end are estimated separately. The variables are in the timeline section.

09 — Go deeper

WordPress as a headless CMS: wp-admin stays, Astro builds the front end.