WordPress to Astro migration

WordPress to Astro, without the plugin stack

A fast, code-based site you own, with content in files or a headless CMS. Every URL kept, every redirect a real 301.

Typical timeline
Scoped after the URL inventory
Cost
Quoted after the URL inventory
SEO risk
Medium: URL patterns change unless routes are matched exactly
Moves cleanly
Posts, pages, custom fields and taxonomies (as Markdown or CMS entries)
Must be rebuilt
Theme, plugin features, forms, search, editing workflow

In short

Checked against WordPress and Astro docs

A WordPress to Astro migration replaces the theme and plugins with an Astro site in code. Content comes out of the WordPress XML export and lands in Astro content collections as Markdown, or in a headless CMS if editors need a UI; WordPress can also stay on as the headless backend. Pages ship as plain HTML, and redirects live in the host’s redirect file so they are real 301s.

Why teams move

Why teams move from WordPress to Astro

  1. Editors wait on developers for layouts

    When the content model is squeezed into posts and pages, every new page type is a developer job. In Astro the model is defined in code once and reused.

  2. Plugin upkeep eats real hours

    Updates and security patches take time every month, and a bad update has broken the site before. Astro has no plugin layer at runtime.

  3. Content has to go to more places

    Structured content can feed the site, docs, a newsletter and AI tools, and structured pages are easier for answer engines to read.

  4. Performance or design that themes can’t meet

    Astro ships plain HTML and adds JavaScript only where a component needs it, so the design isn’t limited by a theme and pages stay light.

Old vs new

WordPress vs Astro, for this move

CriteriaWordPressAstro
What you runWordPress:PHP, a database, a theme and pluginsAstro:Static HTML from a repository, hosted on a CDN
EditingWordPress:wp-adminAstro:Markdown and data files, or a headless CMS
UpkeepWordPress:Core, theme and plugin updatesAstro:Dependency updates in code, no plugin surface
SpeedWordPress:Depends on theme, plugins and cachingAstro:Ships very little JavaScript by default
RedirectsWordPress:Plugin or server configAstro:Host redirect file, each line marked 301

What moves, what doesn’t

What comes across from WordPress

The writing moves. The theme, plugins and admin don’t; they’re replaced on purpose.

  • Content

    Moves over: The XML export includes posts, pages, custom post types, comments, custom fields and taxonomies. We convert it to Markdown with frontmatter, or into a headless CMS.

  • CMS

    Replaced: wp-admin is replaced by content collections with a schema checked at build time, or a headless CMS (or WordPress itself, kept as a headless backend).

  • SEO

    Rebuilt: Titles, descriptions and canonicals become frontmatter fields; the sitemap and structured data are generated from the content.

  • Forms

    Replaced: Form plugins are replaced with a form service, your CRM’s embed or a small serverless function.

  • Integrations

    Replaced: Analytics, tag managers and embeds are added in the layout and loaded lazily. Search, comments and memberships need a decision each.

  • Animations

    Rebuilt: Rebuilt in CSS or a small motion library, and only shipped on pages that use them.

  • Media

    Partly: The export links to media files rather than containing them; self-hosted sites copy wp-content/uploads, and images go through Astro’s image pipeline.

Moves over
Exported, imported, then checked by hand
Partly
Some of it imports, the rest is redone
Rebuilt
Nothing to import, we rebuild it
Replaced
Swapped for the new platform’s equivalent

Content model

How WordPress content maps to Astro

  1. Posts

    Blog posts kept in the WordPress database, written in the block editor and exported as one XML file.

    On WordPress:

    A blog content collection

    One Markdown file per post in the repo, with the post’s details kept as frontmatter at the top.

    On Astro:

    What you get src/content/blog/*.md

    Frontmatter holds title, date, author, categories and SEO fields.

  2. Custom post types

    Extra content types such as case studies or resources, registered by the theme or a plugin.

    On WordPress:

    A collection each

    Each type gets its own content collection, with a schema that lists every field it needs.

    On Astro:

    What you get src/content/case-studies/

  3. ACF and custom fields

    Extra fields on posts and pages, added by Advanced Custom Fields or by the theme’s own code.

    On WordPress:

    Typed fields or data files

    Typed frontmatter fields or data files, so a missing or malformed value shows up as a build error.

    On Astro:

    What you get src/content.config.ts

  4. Categories and tags

    Taxonomies that group posts, each with an archive page that WordPress generates by itself.

    On WordPress:

    Fields plus archive pages

    Fields on each post, plus generated archive pages only where they already earn search traffic.

    On Astro:

    What you get src/pages/blog/tag/[tag].astro

  5. Pages

    Pages built in the block editor or a page builder, often carrying shortcodes and inline styles.

    On WordPress:

    .astro pages

    Page files built from shared section components, with their SEO tags set from the same data.

    On Astro:

    What you get src/pages/pricing.astro

Process and timeline

How we move a WordPress site to Astro

  1. Audit and URL inventory

    Before any code

    Crawl every URL, export rankings and backlinks, and record on-page SEO. Decide whether editors work in files or a headless CMS.

  2. Content model and redirect map

    Before any code

    Map every post type and field to a collection schema, and every URL to its new route or a 301.

  3. Design system and templates

    Build

    Tokens and components first, then page and collection templates.

  4. Content conversion

    Build

    Convert the XML export to Markdown or CMS entries, copy media, and validate every item against the schema.

  5. SEO parity and redirects

    Before launch

    Titles, descriptions, canonicals and schema checked page by page; 301s written into the host’s redirect file.

  6. Launch and watch

    Launch and after

    Switch the domain early in the week, submit the sitemap and watch 404s and indexing daily.

Full step-by-step guideWordPress to Headless CMS Migration: When Sanity, Next.js, and Vercel Make Sense

SEO safety

The pre-launch checklist for WordPress to Astro

Rankings are lost in three ways: broken URLs, missing on-page signals and crawl problems. 4 stages, from the first crawl to the weeks after launch, close all three. Tick the checks as you go; your progress stays in this browser.

Stage 1 of 4

Before the build

Know every URL and where it goes before anything is designed.

Stage 1: Before the build

Stage 2 of 4

During the build

Carry every on-page signal across, page by page.

Stage 2: During the build

Stage 3 of 4

Before launch

Real redirects and a clean path for crawlers, ready for the switch.

Stage 3: Before launch

Stage 4 of 4

After launch

Watch what Google sees in the first weeks and fix it fast.

Stage 4: After launch

What people worry about

What WordPress teams worry about

  1. Our editors don’t write Markdown

    Then they don’t have to. A headless CMS gives them a visual editor and previews, or WordPress stays on as the backend while Astro serves the site.

  2. We’ll lose rankings with the URL change

    Astro lets us choose every route, so most URLs don’t change at all. The ones that do get a one-to-one 301 at the host.

  3. Only a developer can change the site now

    Content edits stay with editors. Layout changes become code changes, which developers and coding agents make through reviewed pull requests.

When not to migrate

When to stay on WordPress

  • The site is a few dozen pages and a plugin or two covers what you need. Better hosting and caching are the cheaper fix.

  • WooCommerce is at the centre of the business.

  • A large editing team lives in Gutenberg and needs to keep it.

  • You depend on WordPress user management, multisite or a membership plugin.

Not sure which side you’re on?

If one of these is you, staying on WordPress is probably the better call. We’ll say so on the first call.

Book a call

FAQ

WordPress to Astro questions

Adrian

Moving from WordPress to Astro?

Every URL mapped, the CMS rebuilt, SEO kept. We scope it on a 30-minute call.

Can we keep WordPress as the CMS?

Yes. Headless WordPress keeps editors in wp-admin while Astro builds the site from its content. It’s the lower-risk path for editors; the cost is two systems to maintain.

Astro or Next.js?

Astro for content-led marketing sites with little interactivity, since it ships very little JavaScript by default. Next.js when the site shares components or logic with a React app.

Do media files come with the export?

No. The WordPress export links to media rather than including it. On self-hosted WordPress we copy the uploads folder; WordPress.com has its own media export.

How do redirects work on Astro?

We put them in the host’s redirect file (Cloudflare Pages, Netlify and similar) so they’re real server-side 301s, which is what Google recommends for site moves.

Platform facts checked on . Platforms change their exports and limits; we recheck at the start of every project.

You've reached the end, so now…

Tell us what you’re building.

We’ll help you map the right scope, team, timeline, and next steps.

Book a call