Development

WordPress + Astro: The Headless CMS Setup That Actually Makes Sense

Rupam ·

Headless WordPress has been a buzzword for years. Most teams that try it bounce off because the real-world experience is more complicated than the marketing suggests — the WordPress admin doesn’t preview properly, the build pipeline is fragile, the editor experience suffers, and the supposed performance benefits don’t always materialize. That said, when the stack actually works, it produces sites that are dramatically faster, more secure, and more maintainable than monolithic WordPress.

WordPress as a CMS paired with Astro as the frontend is one of the rare headless stacks that’s actually pleasant to operate. This is what we use for content-heavy marketing sites at EtherLabz, and the trade-offs are easier to live with than most headless alternatives.

Key takeaways

  • WordPress is genuinely good at being a CMS. Editorial workflows, custom post types via ACF, the admin UI — the things content teams actually use — are mature and unmatched by most “headless-native” platforms.
  • Astro’s island architecture matches content sites perfectly. Static-by-default with hydration only where interactivity is needed produces the smallest possible JavaScript footprint. Marketing sites should ship near-zero JavaScript.
  • The integration is more boring than headless evangelists suggest. WordPress publishes content via REST or GraphQL, Astro fetches at build time, generates static HTML, deploys to a CDN. No Kubernetes, no microservices, no serverless complexity required.
  • Preview is the hard problem. The most painful part of any headless WordPress setup is making the WordPress admin’s “Preview” button work. Solutions exist; budget time for them.

Why WordPress + Astro specifically

The argument for keeping WordPress as the CMS:

  • The editorial UX is mature. Content teams know it. Custom fields via ACF cover most content modeling needs. Editorial workflows (drafts, scheduled posts, revisions, multi-author collaboration) work without engineering effort.
  • The plugin ecosystem covers integrations. SEO (Yoast, RankMath), forms (Gravity Forms, Fluent Forms), redirects, image management — all already exist. You don’t have to build any of this.
  • Self-hostable. Unlike SaaS-only headless CMSes, WordPress can run anywhere — important for cost control at scale and for data sovereignty.

The argument for Astro as the frontend:

  • Static output is the default. Astro pages compile to static HTML. JavaScript only ships for interactive components, hydrated as “islands.” The result: content sites with sub-second LCP and tiny bundle sizes.
  • The component model is flexible. Astro components by default, but you can use React, Vue, Svelte, or Solid components within the same project. Mix-and-match without paying the bundle cost of multiple frameworks for static content.
  • The build is fast. Astro’s build tooling is significantly faster than Next.js for static sites of equivalent size. For content sites with thousands of pages, this matters.
  • Content collections and TypeScript types. Astro 5’s content collections give you typed content from external sources. WordPress data fetched at build time becomes a typed content source the rest of your code can reason about.

The architecture

The setup we use:

  • WordPress backend on Atomic infrastructure or managed WordPress hosting (Kinsta, WP Engine, Pressable). Custom post types and ACF fields modeling the content. Yoast or RankMath for SEO metadata. The admin is private — only editors access it.
  • Astro frontend as a separate codebase. Fetches content from WordPress via REST API or WPGraphQL at build time. Generates static HTML for every page. Deploys to Vercel, Cloudflare Pages, or Netlify.
  • Build trigger when content changes. WordPress webhook fires to trigger a rebuild on the host. Most CMS content is published rarely enough that on-demand rebuilds are fine; for high-frequency content, incremental static regeneration via Astro’s hybrid mode handles it.
  • Forms and dynamic content handled via API routes or third-party services. Forms post to a Cloudflare Worker, Vercel Edge Function, or directly to a service like Formspark or Tally. Dynamic content (search, filters, personalization) ships as Astro islands hydrated client-side.
  • Preview via a separate preview mode in Astro that fetches from WordPress at request time rather than build time. The WordPress admin’s preview link points to the Astro preview URL.

The integration details that matter

REST or GraphQL

WordPress’s built-in REST API works fine for most cases. WPGraphQL is the more powerful alternative, especially when you need nested relationships or want to fetch only specific fields. For sites with hundreds of pages, WPGraphQL’s fragment composition keeps the build fast; for smaller sites, REST is simpler.

Image handling

WordPress uploads images to wp-content/uploads. The Astro frontend can reference these directly via the WordPress URL, or download and re-host them through Astro’s image optimization pipeline. The latter is faster (your CDN serves them instead of WordPress) but requires handling at build time. For most sites, using Astro’s <Image> component with WordPress URLs as source is the right balance.

SEO metadata

Yoast and RankMath both expose SEO metadata via REST and GraphQL. Pull these into the Astro frontend and render them as <meta> tags. Don’t recreate the SEO logic in Astro — use what the SEO plugin already calculated.

Redirects

Redirect plugins in WordPress (Redirection, Yoast Premium) won’t fire if the public site is Astro. Either export the redirect rules to your CDN’s redirect configuration (Vercel, Cloudflare), or sync them at build time into Astro’s redirect map.

Custom blocks / Gutenberg

Gutenberg blocks in WordPress produce HTML in the post content. Astro can render this HTML directly, or parse the block JSON and render custom Astro components for known blocks. The latter gives you full design control; the former is simpler.

The hard parts

Preview

The WordPress admin’s “Preview” button is built around the assumption that WordPress renders the public site. With a headless setup, you need to either: route the preview URL to a special Astro route that fetches unpublished content from WordPress at request time, or build a custom preview workflow in WordPress that talks directly to your Astro deployment. Both are doable; both take more time than people expect.

Editorial review

If editors are used to seeing content rendered exactly as it’ll appear, headless can break that. The fix is making the preview environment as close to production as possible — same components, same styles — so what they see in preview matches what ships.

Build time

Sites with thousands of pages can have multi-minute build times. Mitigations: incremental builds, on-demand revalidation for changed content, hybrid rendering for high-cardinality content (e.g., individual blog posts can be fetched and rendered at request time, while index pages stay static).

Plugin compatibility

Some WordPress plugins assume they control the public site — they won’t work in a headless setup. Form plugins that render their own forms client-side, popup plugins, A/B test plugins, and anything that injects scripts into the public-facing pages all need replacement or workarounds.

FAQ

Is this faster than vanilla WordPress?

Significantly, on every metric that matters. Static HTML on a CDN responds in 50–100ms TTFB globally. Vanilla WordPress on managed hosting responds in 200–1000ms depending on plugin load. JavaScript bundle sizes drop dramatically because Astro ships nothing for static content. Core Web Vitals are usually green by default.

Is this more secure?

Yes. The public site is static HTML — no PHP execution, no database, no admin panel exposed. The WordPress admin is private and only your editors access it (often behind IP allowlist or VPN). The attack surface drops to nearly zero on the public side.

Can content editors still edit normally?

Yes. The WordPress admin works exactly as it does in monolithic WordPress. The only difference is preview — which can be made to work but requires setup.

What about WooCommerce in this setup?

Possible but more complex. WooCommerce includes a lot of dynamic functionality (cart, checkout, account) that doesn’t translate well to static. The pattern that works: marketing/content pages static via Astro, store/cart/checkout via headless WooCommerce APIs hydrated as Astro islands. We’ve shipped this for ecommerce stores; the build is more involved than content-only sites.

What hosting setup do you recommend?

WordPress on managed hosting (Kinsta, WP Engine, Pressable, Cloudways) for the admin/CMS layer. Astro on Vercel or Cloudflare Pages for the public site. Vercel’s incremental static regeneration and Cloudflare’s edge caching both work well. Total infrastructure cost for a typical content site: $50–$300/month including both layers.

Want help building a WordPress + Astro headless setup?

EtherLabz has shipped multiple WordPress + Astro headless sites — including the v2 build of etherlabz.com. We know the integration details, the preview gotchas, and the migration path from monolithic WordPress. Book a discovery call.

Written by Rupam, with input from the EtherLabz team.