wordpress-to-astro-migration.html

WordPress to Astro migration in 2026 — zero default JS, full SEO continuity.

Astro ships zero client-side JavaScript by default. For content-led WordPress sites, that means the lowest baseline weight of any modern stack. Content collections or headless via WPGraphQL — both transport Yoast, schema, redirects byte-identical.

12,000+ WordPress sites shipped Astro 5 + content collections Redirect map from GSC + Ahrefs Yoast / Rank Math transport

KEY FACTS · 2026

  • Astro ships zero default client-side JavaScript — every page is server-rendered HTML, with interactive islands opt-in per component.
  • A 30-100 page WordPress to Astro migration runs 6-10 weeks and 15,000-40,000 USD — typically 30-40% cheaper and faster than the Next.js equivalent for content sites.
  • Two valid paths: full migration to Astro content collections (Markdown / MDX), or headless WordPress with Astro front-end via WPGraphQL.
  • Astro is the right choice when most pages are content; Next.js is the right choice when most pages are application-shaped.
  • Yoast and Rank Math metadata transports byte-identical either way — into Markdown frontmatter (full migration) or via WPGraphQL (headless).

HOW THE MIGRATION RUNS

  1. Audit indexed URLs. Pull every URL from Search Console, Ahrefs, and the WordPress sitemap into a single deduplicated CSV.
  2. Build the redirect map. Map each WordPress URL to its Astro destination. Ship as 301s in vercel.json or netlify.toml. Retired pages get 410.
  3. Pick the content path. Full migration to Astro content collections (Markdown / MDX) for technical teams. Headless WordPress with Astro front-end (via WPGraphQL or REST) for non-technical teams.
  4. Export content from WordPress. Use the WordPress REST API or WP-CLI to extract every post, page, and ACF field. Script the conversion to Markdown frontmatter (full path) or query into Astro at build time (headless path).
  5. Bridge Yoast or Rank Math. Transport metadata field-by-field into Astro layout. Title, description, canonical, OG image stay byte-identical to the WordPress source.
  6. Re-emit schema. Hand-write Article, BreadcrumbList, FAQ, Product, Review schema in Astro components. Better than plugin-emitted JSON-LD by default.
  7. Build the Astro site. Astro content collections, MDX for rich content, islands for any interactivity. Static generation for every public route; Vercel or Netlify hosting.
  8. Run parallel staging. WordPress stays live. Astro site builds to a staging domain. QA both side by side for 1-2 weeks before cutover.
  9. Cut over with redirects. Point production DNS at the new host. Activate the redirect map. SEO linter fails the deploy if any indexed URL is missing.
  10. Monitor for 60-90 days. Search Console, GA4, Ahrefs daily for the first two weeks then weekly. Expect a 2-6 week dip then recovery.

ASTRO VS NEXT.JS FOR A WORDPRESS MIGRATION

Both clear 95+ Lighthouse out of the box. The right choice depends on what shape your site is.

Astro is right when most of your pages are content — blog posts, documentation, marketing pages, brochure pages. Astro ships zero client-side JS by default; interactive islands opt in only where needed. Production bundles tend to be 30-50% smaller than the equivalent Next.js build for content sites.

Next.js is right when most pages are application-shaped — dashboards, configurators, member areas, complex forms, anything with deep client-side state. Next.js handles app routes, server actions, and dynamic SSR more naturally than Astro.

Full comparison: Astro vs Next.js — when each is the right choice in 2026.

FREQUENTLY ASKED QUESTIONS

Why migrate from WordPress to Astro instead of Next.js?Astro ships zero default client-side JavaScript. Every page is server-rendered HTML by default; islands of interactivity opt in. For content-led sites — blogs, documentation, brochure sites, marketing sites where most pages are static — that is the lowest-baseline-weight architecture in 2026. Next.js is the better choice when most pages are application-shaped (dashboards, configurators, member areas, complex forms). For a WordPress content site, Astro typically delivers a 30-50% smaller production bundle than the equivalent Next.js build.
Should I use Astro content collections or keep WordPress as a headless back-end?Two valid paths. Path one: full migration. Export WordPress content to Markdown or MDX, put it in Astro content collections, edit content in Git. Best for technical teams that already work in pull requests — engineering, developer-tool companies, open source projects. Path two: headless WordPress with Astro front-end. Keep wp-admin, query content via WPGraphQL or REST, render in Astro. Best for marketing teams that need a non-technical editor and the WordPress workflow they already know.
How do you convert Gutenberg blocks to Astro components?Three patterns. Stock blocks (paragraph, heading, list, image, quote) get parsed from the WordPress REST response and rendered as Astro components — straightforward, mostly automatable. Custom blocks built with ACF Blocks get a manual mapping table — each block_name maps to an Astro component. Visual builder pages (Elementor, WPBakery) usually get rewritten by hand or replaced with new layouts; the migration is the right moment to leave page-builder lock-in. Most projects ship a content rewrite as part of the project so the new components are clean, not bug-compatible.
Will my SEO survive the migration to Astro?Yes if the migration is done correctly. Three rules. Preserve every URL or 301 it — sourced from Search Console, Ahrefs, and the WordPress sitemap, shipped as 301s in vercel.json or netlify.toml. Bridge Yoast or Rank Math metadata via WPGraphQL (if going headless) or transport it field-by-field into Astro frontmatter (if going full Markdown). Re-emit schema markup on every page from hand-written Astro components — typically better and cleaner than plugin-emitted JSON-LD. Build-time SEO linter fails the deploy if any pre-migration URL is missing from the redirect map.
How long does a WordPress to Astro migration take?A 30-100 page marketing site migration runs 6-10 weeks (Astro is faster to build out than Next.js for content sites because there is less framework to wire up). A 500-page content site with custom post types runs 10-14 weeks. Discovery is 1-2 weeks regardless of size; cutover is 1-2 weeks; post-launch monitoring is 60-90 days.
How do you handle ACF fields and custom post types?Two approaches depending on the migration path. Going headless: install WPGraphQL for ACF, expose every ACF field group as a typed GraphQL field, query into Astro pages at build time. Going full Markdown: write a one-off Node script that pulls every post via the WordPress REST API, flattens ACF fields into Markdown frontmatter, and writes one .md / .mdx file per post into Astro content collections. The Markdown path is simpler to maintain long-term; the headless path is simpler if your editorial team will not learn Git.
What about Yoast or Rank Math metadata?It transports both ways. Going headless: Yoast SEO for WPGraphQL or RankMath SEO Schema and Meta exposes every field — title, description, canonical, OG image, focus keyword — which Astro reads at build time and renders into the layout. Going full Markdown: the same plugin endpoints feed the migration script, which writes the metadata into frontmatter (title, description, canonical, og_image fields). Either way, editors keep editing in the same plugin UI when on the headless path, or in Markdown frontmatter when on the full migration path.
What does it cost?A 30-100 page WordPress to Astro migration: 15,000-40,000 USD (cheaper than the Next.js equivalent because Astro builds are leaner). A 500-page content site: 35,000-75,000 USD. The biggest variables are ACF complexity, the number of custom post types, and how much of the existing content needs rewriting for the new component library. Discovery is 1,500-5,000 USD; the fixed-price build follows.
When is Astro the wrong choice for a WordPress migration?Three cases. Heavy interactive applications — dashboards, member areas with real-time data, configurators, anything where most pages are app-shaped — fit Next.js better. WooCommerce migrations rarely fit Astro because the cart, checkout, and account flows are app-shaped; Astro can do them but Next.js + a commerce platform (Shopify Hydrogen, Medusa, Saleor) is more battle-tested. Teams that need server-side dynamic rendering on most routes (auth-gated dashboards, SSR-heavy SaaS) fit Next.js or Nuxt better.
How does Astro compare to other static site generators?In 2026 Astro is the clear leader for content-led migrations. Hugo is faster to build but harder to template if you want components. Eleventy is comparable but the ecosystem is smaller. Gatsby is essentially deprecated for new builds. Next.js static export works but ships more JS than Astro. The Astro Islands architecture — server-rendered HTML with opt-in client components — is the right shape for most WordPress content sites in 2026. Comparison: see Astro vs Next.js.

WHAT THE FIRST 48 HOURS LOOK LIKE

Book a 30-minute call. Bring your current WordPress URL, your active plugin list, and the proportion of your site that is content (blog, marketing, brochure) versus application (member area, dashboard, configurator). By the end of the call you will know whether Astro or Next.js is the right destination, what the migration looks like for your specific stack, and a price range.

RELATED — IF YOU'RE LEAVING WORDPRESS