# Headless CMS With Astro: When It Pays Off, and When Next.js or WordPress Fits Better

> When a headless CMS with Astro pays off, when Next.js or WordPress fits better, where Faust.js stands in 2026, and what AI agents mean for headless content.

- Source: https://choatecatalysts.com/canon/headless-cms-astro-nextjs/
- Author: Douglas Choate, Choate Catalysts (https://choatecatalysts.com/craft/douglas-choate/)
- Published: 2026-10-19
- Updated: 2026-10-22
- Collection: The Canon (https://choatecatalysts.com/canon/)

---

Should your marketing site run on a headless CMS with Astro in front, on Next.js, on Faust.js, or on plain WordPress? This guide answers that by situation: what headless costs, where each option is strong, what changed in 2026, and whether “headless” is still the right question to ask.

I’m not neutral here. We build and run WordPress platforms for clients, and this site runs on Astro with no CMS at all. Both choices are deliberate. The right one depends on three things: who edits, who patches, and where you host.

## What Headless Actually Changes

A headless CMS stores and edits your content, then hands it over an API (a defined way for one system to request data from another) to a separate website that draws the pages. WordPress does both jobs in one system. Headless splits them.

What you gain is freedom on the front end: static pages, your own templates, and a site that doesn’t run a database query on every visit.

What you take on:

- **Two systems.** Two bills, two sets of updates, two places for something to break.
- **A pipeline between them.** Publishing triggers a rebuild or a cache refresh, and someone owns that wiring.
- **Preview.** Editors want to see a draft before it goes live, and in a split system that has to be built.
- **Everything the plugins used to do.** Sitemaps, redirects, SEO tags, forms.

That last one is easy to underestimate. When we moved our articles off WordPress on August 15, 2026, we ported eight of them verbatim and checked each against the WordPress REST API. Then we rebuilt by hand what plugins had been doing: the sitemap, robots rules, RSS feed, canonical tags, structured data, a redirect for every retired category URL, and a contact form that now posts through a small Cloudflare Worker. None of it was hard. All of it is ours to maintain. The [project walkthrough](/work/choate-catalysts/) shows the result.

Some of that work survives a headless move. Yoast SEO, for example, [exposes its page metadata over the WordPress REST API](https://developer.yoast.com/customization/apis/rest-api/) so a separate front end can reuse it. Yoast’s documentation also says the API is read-only, and it doesn’t cover sitemaps or redirects.

Headless doesn’t remove work. It moves it to whoever owns the front end.

## Astro With a Headless CMS

Astro [prerenders the whole site to static HTML by default](https://docs.astro.build/en/guides/on-demand-rendering/), and lets you switch individual pages to server rendering when they need it. For a marketing site that is mostly words, that default is the right one.

Content arrives in two ways, according to [Astro’s documentation](https://docs.astro.build/en/guides/content-collections/):

- **Build-time collections** pull from your CMS (or from files) during the build. Fast, simple, and every change needs a rebuild.
- **Live collections** fetch on each request, so a change appears without a rebuild. They need a server adapter, and they give up MDX (Markdown with embedded components) and image optimization.

Live collections became stable in [Astro 6 on March 10, 2026](https://astro.build/blog/astro-6/). [Astro 7, on June 22](https://astro.build/blog/astro-7/), made route caching stable; its release post shows a CMS webhook clearing cached pages by tag, with no full rebuild. That combination closes most of the old “wait for the build” complaint.

Preview is still the weak spot. Sanity’s [Astro visual editing guide](https://www.sanity.io/docs/visual-editing/astro-visual-editing) says it requires server rendering “because draft mode depends on per-request cookie checking,” and that Astro has no equivalent of the Live Content API that Sanity’s Next.js integration uses, so each edit reloads the page. Storyblok’s [Astro preview guide](https://www.storyblok.com/docs/guides/astro/visual-preview) makes live preview opt-in, uses server output, and needs HTTPS even on a developer’s laptop.

None of that is a blocker. It is a budget line. The pattern I’d use is to keep the public site static and give editors a separate, server-rendered preview environment.

Two cautions. Astro shipped two major versions this year and gives [security fixes to only one previous major](https://docs.astro.build/en/upgrade-astro/), so plan upgrades. And since January 2026 the Astro team has been [part of Cloudflare](https://www.cloudflare.com/press/press-releases/2026/cloudflare-acquires-astro-to-accelerate-the-future-of-high-performance-web-development/), which says Astro will remain open source.

On our own site, articles are Markdown files in the repository, checked against a strict schema at build time. For one technical editor, that’s the lightest setup I know. For a team of marketers, it isn’t.

## Next.js: Built for Applications

Next.js is a full-stack React framework, and it has been moving further toward the server. [Next.js 16](https://nextjs.org/blog/next-16) introduced Cache Components, where developers mark which parts of a page may be cached, on October 21, 2025, and [Next.js 16.4](https://nextjs.org/blog/next-16-4), on October 6, 2026, recommends them “as the best choice for every Next.js app.” They are expected to become the default in Next.js 17.

That model earns its keep when pages differ by visitor: logins, personalization, dashboards, account areas. For a site that is mostly articles and landing pages, you carry a server you may not need.

Some popular headless tooling is built around it. Payload, a popular open-source CMS, [runs inside a Next.js app](https://payloadcms.com/), and Faust.js, below, is Next.js only.

On hosting, the Next.js team is clear: “To run Next.js, your platform needs a Node.js server. That’s it,” according to [its deployment guide](https://nextjs.org/docs/app/guides/deploying-to-platforms). Vercel, which makes Next.js, shipped a [stable Adapter API in March 2026](https://nextjs.org/blog/nextjs-across-platforms), designed with Netlify, Cloudflare, AWS Amplify, Google Cloud and the OpenNext project, so other hosts can support it properly. As of October 19, 2026, the [Next.js GitHub organization](https://github.com/nextjs), where verified adapters live, hosts them for Vercel, Bun and Kubernetes. Netlify [says its own](https://www.netlify.com/blog/the-next-js-adapter-api-just-shipped-here-s-what-comes-next) will ship later this year.

On Vercel itself, [the Pro plan](https://vercel.com/pricing) is $20 per developer seat per month, plus metered compute, data transfer and image optimization. The free Hobby plan is for “personal, non-commercial use.”

## Security Is a Question of Who Patches

Next.js, WordPress and Astro all shipped critical security fixes in the past year. The useful question isn’t which is safest. It’s who applies the fix, how fast, and whether your host absorbs any of it.

**React2Shell.** On December 3, 2025, the React team disclosed [CVE-2025-55182](https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components), rated 10.0 out of 10: remote code execution, meaning an attacker could run their own code on your server without logging in. It sat in React Server Components, which Next.js’s App Router uses. Amazon’s threat intelligence team saw [exploitation attempts “within hours”](https://aws.amazon.com/blogs/security/china-nexus-cyber-threat-groups-rapidly-exploit-react2shell-vulnerability-cve-2025-55182/). CISA added it to its [Known Exploited Vulnerabilities catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) on December 5 and records known use in ransomware campaigns. The [Next.js advisory](https://nextjs.org/blog/CVE-2025-66478) offered no workaround and told anyone unpatched as of December 4 to rotate their secrets.

**Where you host changes the exposure.** In March 2025, a [middleware bypass](https://vercel.com/blog/postmortem-on-next-js-middleware-bypass) let attackers get past authorization checks run in middleware on self-hosted Next.js. Vercel’s postmortem says sites on Vercel, Netlify and Cloudflare Workers were not affected, because their routing runs separately. The [September 30, 2026 release](https://nextjs.org/blog/september-2026-security-release) fixed a cache-poisoning flaw in self-hosted apps, and says plainly: “Applications deployed on Vercel are not affected.”

**But the host is not a shield.** For the [May 7, 2026 release](https://vercel.com/changelog/next-js-may-2026-security-release), which fixed 13 advisories, Vercel wrote that it “has not deployed new WAF rules,” meaning no firewall rules to block attacks while you upgrade; patching was the only complete fix. On [October 14, 2026](https://nextjs.org/blog/nextjs-security-update-october-14-2026), two more critical remote code execution fixes shipped, one with no known workaround.

One of September’s fixes matters for anyone running a headless CMS with previews. Under certain caching settings, a visitor whose request overlapped an editor’s preview could [receive unpublished content](https://github.com/vercel/next.js/security/advisories/GHSA-3w37-wq28-93x7), and that content could be saved into the page for later visitors.

**WordPress is not exempt, headless or not.** On July 17, 2026, [WordPress 7.0.2](https://wordpress.org/news/2026/07/wordpress-7-0-2-release/) fixed a chain of two flaws, a REST API flaw and a SQL injection (smuggling commands into the database), that led to remote code execution, and WordPress.org forced the update out automatically. CISA added both flaws to its catalog four days later, noting they could give an unauthenticated attacker code execution on default installations. A separate [page-template flaw](https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-7hp8-65ch-5whp), published September 22 and patched back to version 4.7, joined the catalog on September 25. A headless backend still runs WordPress core.

**Astro isn’t exempt either.** On August 27, 2026, Astro published a [critical remote code execution fix](https://github.com/withastro/astro/security/advisories/GHSA-26w7-cxv4-gfx2) for its image optimization, triggered when it processes an untrusted AVIF image. A static site removes most of what an attacker can reach at runtime, but the build still processes inputs. If editors upload images to a CMS, I treat those images as untrusted.

The operational lesson:

- A static Astro site on a CDN (a content delivery network) gives an attacker very little to talk to.
- A Next.js server or a WordPress install is always listening.
- Managed hosts sometimes absorb a flaw for you, and sometimes don’t.

None of that rules anything out. It tells you to name the person who ships the patch, and to decide your host before your framework.

## Faust.js in October 2026

Faust.js is WP Engine’s toolkit for headless WordPress. Its [README](https://github.com/wpengine/faustjs) describes “a toolkit for building Next.js applications” and requires the Pages Router, Next.js’s older routing system.

The newer App Router never landed. Faust’s experimental App Router package is [deprecated on npm](https://www.npmjs.com/package/@faustwp/experimental-app-router), with the notice that it “will not receive further bug fixes or security patches due to the lack of Apollo support for React Server Components and Next’s App Router.”

The roadmap changed this month. The [October 2025 version](https://raw.githubusercontent.com/wpengine/faustjs/c63cb6a753/ROADMAP.md) planned Astro and SvelteKit adapters for early 2026. The [version updated October 7, 2026](https://raw.githubusercontent.com/wpengine/faustjs/22025821cf/ROADMAP.md) calls that plan “a rewrite of Faust.js into framework adapters” and says: “That rewrite is no longer planned, and new work builds on the existing packages and APIs.” Its priorities were keeping existing Faust sites working as their dependencies move, an opt-in way to write content back to WordPress, and a proposed framework-agnostic authentication package for Node, Astro and SvelteKit. Developers on other frameworks are pointed to WP Engine’s [Headless WordPress Toolkit](https://github.com/wpengine/hwptoolkit).

Faust is still maintained: [`@faustwp/core`](https://www.npmjs.com/package/@faustwp/core) 3.5.2 was published on October 19, 2026. And WP Engine’s [Headless Platform](https://developers.wpengine.com/docs/headless-platform) hosts Astro, Nuxt and SvelteKit front ends, not only Next.js.

My read: if you run a Faust site today, there’s no emergency; keep it patched. If you’re starting an Astro build on WordPress, have Astro query WordPress directly, without Faust. Astro’s own [WordPress guide](https://docs.astro.build/en/guides/cms/wordpress/) uses the built-in REST API.

## Headless WordPress, and the Ground Around It

WordPress makes a credible headless backend. The REST API is in core. WPGraphQL, the plugin many headless builds use to query WordPress, released [version 2.24.2 on October 16, 2026](https://wordpress.org/plugins/wp-graphql/) and has more than 30,000 active installs. In October 2024 its creator [joined Automattic](https://www.wpgraphql.com/2024/10/07/wpgraphql-becomes-a-canonical-plugin-my-move-to-automattic) as the plugin began “becoming a canonical community plugin on WordPress.org.” Two years on, its listing still says it “is becoming” one.

Agents can reach it too. The Abilities API, a standard way for plugins to declare what a site can do, [landed in WordPress 6.9](https://wordpress.org/news/2025/12/gene/) in December 2025, and the official [MCP Adapter plugin](https://wordpress.org/plugins/mcp-adapter/), still labelled experimental, connects those abilities to AI tools. Its [announcement](https://developer.wordpress.org/news/2026/02/from-abilities-to-ai-agents-introducing-the-wordpress-mcp-adapter/) gives the right warning: “Because MCP clients act as logged-in WordPress users, always treat them as part of your application surface area.” Our [guide to WordPress and AI in 2026](/canon/wordpress-ai-2026/) covers what to switch on and what to lock down.

The ground around it is less settled. WP Engine’s lawsuit against Automattic and Matt Mullenweg, [filed October 2, 2024](https://www.courtlistener.com/docket/69221176/wpengine-inc-v-automattic-inc/), is still active; on September 24, 2026, the judge let WP Engine’s amended antitrust claims proceed, [according to Search Engine Journal](https://www.searchenginejournal.com/automattic-matt-mullenweg-fail-to-dismiss-wp-engine-antitrust-claims/591210/). The practical fallout for builders is a split: [Advanced Custom Fields](https://wordpress.org/plugins/advanced-custom-fields/) is back under WP Engine with over two million installs, while WordPress.org’s fork, [Secure Custom Fields](https://wordpress.org/plugins/secure-custom-fields/), continues separately. Pick your custom fields plugin deliberately; your content model depends on it.

## The Popular Headless Options at a Glance

Prices are from each vendor’s pricing page on October 19, 2026. Agent access means an official MCP server (the Model Context Protocol, the common way AI tools connect to other software).

| Option | Where your content lives | Entry pricing | Editor preview | Agent access | Worth knowing |
| --- | --- | --- | --- | --- | --- |
| [WordPress](https://wordpress.org/) | Your database | Hosting only | Must be wired into the front end | MCP Adapter plugin | ACF and Secure Custom Fields have split |
| [Sanity](https://www.sanity.io/pricing) | Sanity’s cloud; open-source editor | Free tier; $15 per seat a month | Click-to-edit; Astro needs server rendering | [Hosted MCP server](https://www.sanity.io/docs/ai/mcp-server) | Uses its own query language, GROQ |
| [Contentful](https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-contentful) | Contentful’s cloud | See vendor | [Live preview SDK](https://github.com/contentful/live-preview) | [Official MCP server](https://github.com/contentful/contentful-mcp-server) | Owned by Salesforce since September 1, 2026 |
| [Storyblok](https://www.storyblok.com/pricing) | Storyblok’s cloud | Free starter; $99 a month | Visual Editor; Astro live preview is opt-in | [Hosted MCP](https://www.storyblok.com/docs/tooling/mcp-server) | Ships its own Astro integration |
| [Payload](https://payloadcms.com/payload-has-joined-figma) | Your database, inside a Next.js app | Free to self-host | [Live preview in core](https://payloadcms.com/docs/live-preview/overview) | [MCP plugin](https://payloadcms.com/docs/plugins/mcp) | Owned by Figma; new Payload Cloud deployments paused |
| [Strapi](https://strapi.io/pricing-self-hosted) | Your database, or Strapi Cloud | Free community edition; Cloud from $29 a month billed yearly | [Live preview on paid plans](https://docs.strapi.io/cms/features/preview) | [Built in](https://strapi.io/blog/the-strapi-mcp-server-is-now-ga) | [Cloud free plan removed](https://strapi.io/blog/we-re-removing-the-free-plan-from-strapi-cloud) in 2026 |
| [Hygraph](https://hygraph.com/pricing) | Hygraph’s cloud (GraphQL) | Free tier; from $199 a month | Live preview on all plans | [Hosted MCP](https://hygraph.com/docs/hygraph-ai/mcp-server) | Queried with standard GraphQL |
| [Prismic](https://prismic.io/pricing) | Prismic’s cloud | Free; from $10 a month per repository, billed yearly | Page builder and full-site previews | [Hosted MCP](https://prismic.io/docs/mcp) | [Slice Machine deprecated](https://prismic.io/docs/slice-machine) |
| [TinaCMS](https://tina.io/pricing) | Your Git repository | Free for 2 users; from $24 a month per project | Click-to-edit | None we found | Astro support still uses experimental APIs |
| [Keystatic](https://keystatic.com/docs/cloud) | Your Git repository | Free; optional cloud from $10 a month | Admin screens, no visual editing | None we found | [Calls itself experimental](https://github.com/Thinkmill/keystatic) |
| [Decap](https://decapcms.org/) | Your Git repository | Free | Form editor with preview pane | None we found | Seeking a strategic partner |
| Files in Git, no CMS | Your Git repository | Nothing extra | Pull request previews | Coding agents edit files directly | No editing screens for non-developers |

The hosted options make preview easy and leaving harder. The Git-based ones make leaving trivial and assume your editors can live with simpler screens. Self-hosted Payload, Strapi and WordPress keep the database on your side, and leave the patching there too.

## Does Headless Have a Future?

Headless as a label is fading. Structured content that people and agents can reach through an API is not.

The label is under pressure from developer-led teams. In December 2025, Lee Robinson [moved cursor.com](https://leerob.com/agents) from a headless CMS into code in three days, for $260.32 in AI tokens. His reasons: separate CMS logins, previews that needed extra accounts, and an abstraction his coding agents couldn’t search. Prefect [did the same](https://www.prefect.io/blog/rebuilding-our-website-for-the-agent-era): “Your AI assistant can see the code but not the content.” Even Sanity, in a post arguing teams should keep their CMS, [conceded](https://www.sanity.io/blog/you-should-never-build-a-cms) that “The headless CMS industry built complexity that didn’t deliver proportional value for many” and that “Preview workflows are clunky.”

Integrated platforms are moving the same way. Webflow’s CEO, launching a product built around code, [said](https://www.cmswire.com/digital-experience/why-webflow-faces-a-pivotal-moment-in-its-digital-experience-evolution/) “The source of truth of it is code.” Cloudflare’s [EmDash](https://blog.cloudflare.com/emdash-cms-plugin-registry/), which reached 1.0 in September 2026, is a full CMS built on Astro with an MCP server in every install. It isn’t headless at all.

Meanwhile, the structured-content side is getting bigger, not smaller. Salesforce [completed its purchase of Contentful](https://www.salesforce.com/news/stories/salesforce-signs-definitive-agreement-to-acquire-contentful) on September 1, 2026, to add “a native, headless, composable content layer” to its customer platform. Strapi’s MCP server [reached general availability](https://strapi.io/blog/the-strapi-mcp-server-is-now-ga) on September 3, limited to the permissions of the person who issued its token. WordPress has the Abilities API and its MCP Adapter.

Robinson himself adds the caveat that matters: “For many teams, the cost of the CMS abstraction is worth it,” especially where non-developers need a login to edit.

Nobody can tell you how many sites are headless. [W3Techs](https://w3techs.com/technologies/overview/content_management) shows Sanity, Strapi and Storyblok each on under 0.1% of websites and doesn’t list Contentful, which says more about detection than adoption. It also shows WordPress on 39.6% of websites on October 19, 2026, down from 43.3% a year earlier, while sites with no detectable CMS [rose from 28.6% to 32.1%](https://w3techs.com/technologies/history_overview/content_management/all). Nobody I found has shown why.

So I’d stop asking whether to go headless. Ask whether a person and an agent can both find, change and publish your content, with permissions you set. A headless CMS can do that. So can WordPress. So can a folder of Markdown files. Which one fits depends on who does the editing.

## How I’d Decide

- **One or two technical editors, a content site:** Astro with Markdown in Git. It’s what we run.
- **Several marketers who need to see drafts before publishing:** Astro with a headless CMS, plus a server-rendered preview environment. Budget for the preview work up front.
- **Logins, workflows, commerce or plugin-driven marketing operations:** WordPress. Go headless only if a developer owns the front end week to week. Run any platform through the [five CODES tests](/canon/why-wordpress-is-uniquely-positioned-to-thrive-in-the-ai-era/) first.
- **An app-like site with accounts, personalization or dashboards:** Next.js, with a named owner for security releases. Choose the host before the framework.
- **An existing Faust.js site:** keep it patched, and plan the next rebuild without assuming App Router or Astro support from Faust.
- **Any move between them:** map every old URL to its new home before launch.

Whichever way you’re moving, start with the URL map and dependency checklist in our [WordPress migration guide](/wordpress-migration/).
