Migrations

WordPress to Astro Migration (and Headless WordPress with WPGraphQL)

A slow WordPress site has two honest fixes, not one. Rebuild it fully in Astro and leave WordPress behind, or keep WordPress as the editing backend and swap only the part that renders pages to visitors. Both are real migrations with real tradeoffs, and we'll tell you which one your site actually needs.

Book a Technical Audit ($795)

Should You Migrate Off WordPress, or Go Headless With It?

A slow WordPress site has two honest fixes. Path A is a full WordPress to Astro migration: content moves into Astro content collections and WordPress goes away. Path B is headless WordPress with WPGraphQL: WordPress stays as the CMS, and WPGraphQL feeds an Astro or Next.js frontend while editors keep their same dashboard. We run path B ourselves.

What are the two paths off a slow WordPress site?

A slow WordPress site has two honest fixes: a full migration to Astro, or a headless setup that keeps WordPress and swaps only the render layer feeding Astro or Next.js. The choice isn't which framework wins; it's whether your editorial team's relationship with WordPress is worth keeping. If writers, the SEO plugin, and approvals already work fine in wp-admin, path B fixes only the slow part. If WordPress itself is the burden, path A removes it.

Full migration to Astro compared with headless WordPress with WPGraphQL
Dimension	Path A: Full migration	Path B: Headless WordPress
What stays	Nothing of WordPress	wp-admin, editors, SEO plugin, revisions
What changes	Content moves to Astro content collections; WordPress retired	Only the render layer; WPGraphQL feeds Astro/Next.js
Effort	Higher: content migration, redirect map, rebuild dynamic features	Lower: add WPGraphQL, build a new frontend, WordPress untouched
Who it's for	Sites where WordPress itself (plugins, patching, theme) is the problem	Sites where editorial workflow works and only speed is the problem

What actually moves, and what breaks, in a full Astro migration?

Posts, pages, and SEO metadata move cleanly into Astro content collections or Markdown/MDX. What breaks is anything WordPress rendered dynamically at request time.

Comment sections

Need a hosted comments widget or get dropped.

Live search

Needs a search-as-a-service index.

Member areas and logged-in content

Need a separate service, often a custom application once roles and permissions get involved.

WooCommerce carts

Can't run in a static build; carved out separately.

Shortcodes and page-builder markup

Elementor, Divi, and similar get rebuilt as Astro components, not copy-pasted.

Every existing URL

Needs a one-to-one redirect map before cutover, same discipline as any platform migration.

Tradeoff: you gain a static site with no server-side attack surface and a low performance ceiling, and give up in-browser editing, WordPress's plugin ecosystem, and anything that needed a live server.

How does headless WordPress with WPGraphQL actually work?

WPGraphQL adds a GraphQL API to your existing WordPress install; nothing about the wp-admin editing experience changes. Astro or Next.js queries that API at build time, or request time for anything that needs to stay current, and renders the frontend independently of WordPress's PHP templates. This is the architecture this site runs on.

WordPress still needs its own maintenance and patching; the team takes on a second codebase, the frontend, alongside it. In exchange, the rendered site is as fast as any static build regardless of how bloated the WordPress backend gets.

Editors keep writing in wp-admin

Yoast/RankMath, revisions, and user roles all work as usual.
WPGraphQL exposes the API

That content becomes a typed GraphQL API.
Astro or Next.js queries it

Renders the frontend separately from WordPress.
Speed depends on the frontend

Not the WordPress theme or plugin stack.

What Core Web Vitals gains are realistic, and when is this migration not worth it?

Moving off server-rendered WordPress PHP to a static or edge-rendered Astro/Next.js frontend typically removes the biggest Largest Contentful Paint and Time to First Byte costs. Sites moving from a heavily plugin-loaded WordPress theme to Astro commonly see LCP and TTFB improve by more than half, though the exact number depends on your current stack; the Core Web Vitals audit measures your baseline before anyone promises a figure.

No PHP execution per request

No database query per page load

No render-blocking plugin CSS/JS stacked by page builders

Not worth it for a small, low-traffic brochure site on a lean theme with few plugins that already loads fast. Worth it for content-heavy, traffic-driving sites where speed and uptime carry commercial weight.

What's the actual migration risk, and how do you keep the editorial workflow intact?

The redirect map is the single highest-risk item in path A, built from a full URL inventory, not a wildcard rule; skipped redirects lose rankings, not the platform change itself. Path B carries almost none of that risk because URLs and content ownership don't move.

Migration risk by path
Item	Detail
Path A rollback	WordPress stays live and untouched until the new build is verified end to end, including the redirect map, search, and forms
Path B risk	Near zero; only the render layer changes, and WordPress's own preview/draft workflow keeps working for editors
WooCommerce, either path	Carved out and planned separately, since a static frontend can't run a live cart; it stays on WordPress's checkout, moves to a hosted commerce platform, or becomes a discrete headless service, scoped explicitly by the audit

Should the recommendation ever be audit first, not migrate first?

Yes. Neither path should be the default answer before someone has actually looked at the site. "Migrate to Astro" is a solution being sold before the problem is diagnosed, and the diagnosis usually changes the recommendation.

What the audit actually checks before recommending a path:

How many editors publish, and how often, through wp-admin
How many custom post types and ACF field groups the content model depends on
Current page and post count, not an estimate
Whether the slowness is measured (real Core Web Vitals field data) or assumed
Whether WooCommerce, memberships, or another live-server feature is in play

A site that turns out to be a fast, well-maintained WordPress build with a real but narrow speed problem sometimes gets a Core Web Vitals fix as the recommendation, not a migration at all. The technical audit is built to reach that conclusion when it is the honest one.

A developer writing frontend code during a WordPress to Astro migration audit

When does headless WordPress with Astro beat a full migration outright?

When the site is content-heavy, edited by more than one person, and built on custom post types. At that point, full migration stops being the efficient answer, because it means hand-rebuilding every content type and every page in Astro content collections before launch, and the editorial team loses wp-admin the same day.

Multiple editors publishing regularly

Not one technical owner.

Custom post types and custom fields

Built with Advanced Custom Fields or similar, driving the content model.

Hundreds to thousands of pages

Already existing, not a greenfield build.

Ongoing content operations

That can't pause for a rebuild.

Every one of those signals points at path B, headless WordPress with WPGraphQL, over path A. The content team keeps publishing in wp-admin with zero retraining, and the frontend gets rebuilt once, not per page.

How do you handle thousands of pages without migrating each one by hand?

By building a small number of Astro templates instead of a page count's worth of one-off pages. The pattern: one dynamic route resolves any WordPress URL to its content type at request or build time, then hands it to the matching template.

This is what makes headless WordPress practical at hundreds or thousands of pages: the engineering cost is a handful of templates and a WPGraphQL layer, not a per-page migration effort that scales linearly with content volume.

Build a handful of templates

One page template, one post template, one per custom post type, not one file per URL.
Catch-all route resolves any URL

Queries WPGraphQL's getNodeByUri for the incoming path and its content type.
The route picks the matching template

Renders it with that content.
ACF fields stay queryable

Exposed through WPGraphQL for ACF, no frontend code change required.
Large sites render incrementally

Most-trafficked pages build ahead of time; the long tail renders on demand.

How does this actually move your Core Web Vitals numbers?

Each part of this architecture maps to a specific Core Web Vitals gain, not a general "it'll be faster" claim.

How headless WordPress with Astro templates affects each Core Web Vitals metric
Practice	What it does for Core Web Vitals
Static or incrementally rendered pages, not PHP-per-request	Removes server-side render time from Time to First Byte, which is the floor every other metric builds on
Astro's islands architecture	Ships zero JavaScript by default, so Interaction to Next Paint has almost nothing blocking the main thread
A handful of shared templates instead of per-page custom builds	Keeps layout and image dimensions consistent, which is what actually prevents Cumulative Layout Shift
Incremental or on-demand rendering for the long tail	Keeps Largest Contentful Paint fast on high-traffic pages without paying to pre-build every low-traffic one

This is the current industry direction for large content sites, not a Breezy-specific opinion: hybrid rendering (some pages static, some generated on demand) has become the standard answer to "static sites don't scale," and pairing it with a decoupled CMS is exactly how Astro and Next.js sites are typically operated at this size today. The Core Web Vitals audit measures where your specific site sits against these four before any of this gets built.

A real WPGraphQL query, title, content, and SEO fields

As run against a live WPGraphQL-enabled WordPress install feeding an Astro or Next.js frontend:

graphql

query PageBySlug($slug: ID!) {
  page(id: $slug, idType: URI) {
    title
    content
    seo {
      title
      metaDesc
      opengraphImage {
        sourceUrl
      }
    }
  }
}

WordPress to Astro Migration, Inside the Full Migration Playbook

Leave your platform, keep your rankings: full 301 redirect mapping, staged cutover, and 90-day post-migration rank monitoring, plus zero-data-loss AWS server and database migrations.

Deciding Between Full Migration and Headless WordPress

An hour with an engineer to walk through your editorial workflow, plugin stack, and traffic before either build starts.

Core Web Vitals Monitoring After the New Build Ships

Manual engineering against real-user field data, not another caching plugin. Fixed-fee diagnostic and remediation sprints measured against 28-day CrUX data.

Not Sure This Move Is Worth It Yet?

WordPress vs Astro/Next.js, Compared Before You Migrate Anything

WordPress and Astro/Next.js compared directly on speed, editing workflow, and cost, without assuming either migration path.

Ongoing Support Once You're Running Astro or Next.js

Updates, monitoring, and new features once the new frontend is live, not a one-time handoff.

Going deeper

WordPress to Astro migration questions

Should I fully migrate off WordPress, or go headless instead?

Go headless if your editorial workflow in WordPress already works and only speed is the problem; migrate fully if WordPress itself, its plugins, or its patching burden is the problem. Comparing WordPress against Astro/Next.js directly can help narrow that down before the audit does.

Does headless WordPress mean my editors have to learn a new tool?

No. WPGraphQL sits on top of your existing WordPress install; the wp-admin editor, your SEO plugin, drafts, and revisions all work exactly as they do now. The only thing that changes is what renders the public-facing pages.

What happens to WooCommerce in either migration path?

WooCommerce gets carved out and planned separately, because a static frontend can't run a live shopping cart. Depending on the audit's findings, commerce either stays on WordPress's own checkout behind the new frontend, moves to a dedicated commerce platform, or becomes its own headless service.

Will I lose my Yoast or RankMath SEO data?

No, in either path. In a full migration, SEO fields are extracted and carried into the new build's frontmatter or content collection schema. In a headless setup, WPGraphQL exposes those same fields directly, as shown in the snippet above.

How do you keep my search rankings through the move?

Every existing URL gets a one-to-one redirect map into its new route before cutover, the same discipline used on any migration. In a headless setup this risk mostly disappears, since URLs and content don't move.

Can I preview draft content before it goes live?

Yes, in a headless setup: WordPress's own draft and preview workflow keeps working, since the CMS side is untouched. In a full migration off WordPress, the new frontend's own build or preview environment takes over that role.

Why would I keep WordPress at all instead of migrating fully?

Keep WordPress if your team likes the editor, your plugin stack is thin, and the pain point is purely page speed. Ongoing WordPress support handles that case well; a full migration only pays for itself when WordPress itself, not just its rendering speed, is the problem.

Is this migration worth it for a small business website?

Usually not, if the site is a small, low-traffic brochure site on a lean theme with few plugins. This migration earns its cost on content-heavy or traffic-driving sites where speed and uptime carry real commercial weight.

How is this different from just installing a caching plugin?

A caching plugin masks slow rendering for repeat or cached requests; it doesn't remove the PHP execution, database queries, and plugin-stacked CSS/JS that make the first render slow. Both migration paths here remove that rendering cost structurally rather than caching around it.

Do you build on Astro, Next.js, or both?

Both, and the choice is platform-agnostic: it depends on your team's existing stack, hosting preferences, and whether you need Next.js-specific features like incremental static regeneration at scale. Ongoing Next.js and Astro support covers either choice the same way.