How to migrate from WordPress to Astro without losing SEO rankings

WordPress is a perfectly good tool — until your site grows to 200 posts, 30 plugins, two custom post types and a hosting bill that doubled last year. At some point the Lighthouse score becomes unfixable, the editor becomes intolerable, and you start thinking about a rewrite.

Astro is a tempting target: zero JavaScript by default, Lighthouse 95+ out of the box, Markdown content that lives in Git, and a build pipeline you actually understand. The fear, though, is real: what happens to my SEO rankings if I switch?

The short answer: nothing, if you do the migration right. I’ve moved sites from WordPress to Astro with zero ranking loss — and in most cases small ranking gains within 4–8 weeks of launch because Core Web Vitals improve so much.

Here’s the checklist I follow, in order.

1. Inventory the WordPress site BEFORE you touch anything

Before you write a single line of Astro, you need to know exactly what you have. Skip this and you’ll discover orphaned URLs three months after launch, when they’ve already 404’d and Google has dropped them.

I export:

• The full URL list via Screaming Frog or wp-cli (wp post list --post_type=any --format=csv). You want every post, page, custom post type, category, tag, and attachment URL.
• All redirects already in place — usually from a redirects plugin or in .htaccess. These often encode years of past URL changes you absolutely don’t want to lose.
• The current Google Search Console performance — which queries you rank for, which URLs get traffic, which keywords are climbing vs falling.
• The current schema markup — if you have a Rank Math or Yoast install, you have schema. Audit it on Schema.org Validator so you know what to replicate.

Save all of this to a spreadsheet. It will be the source of truth for the migration.

2. Pick your slug strategy: keep them, or accept the redirect cost

This is the single most important SEO decision in the whole migration.

Option A — keep slugs identical. Every /2024/03/15/my-post-slug/ becomes /blog/my-post-slug/ (or vice versa). You implement 301 redirects from the old structure to the new, and Google passes 90%+ of the link equity through the redirect within 4–8 weeks.

Option B — restructure URLs. Tempting, but every restructured URL is one Google has to re-discover, re-evaluate, and decide whether to keep ranking. If your URLs are already short and clean, don’t restructure. If they’re terrible (/?p=482), restructure once, do it right, and never touch them again.

I default to Option A unless the URL structure is actively hurting (e.g. has dates that age out content artificially, or has the WordPress ?p= query strings).

3. Export content in a format Astro understands

WordPress stores posts in the database as HTML with shortcodes. Astro wants Markdown files with YAML frontmatter. The migration tool I use is wp2md (a small Node script I keep in my ~/bin) but you can do this with:

• The official wp export XML and the wpxml2md npm tool, or
• A custom PHP script that hits wp_get_post_data() and serializes each post to Markdown.

What matters is that the frontmatter ends up with:

---
title: "Original post title"
description: "The meta description Yoast/Rank Math was emitting"
pubDate: 2023-08-15
updatedDate: 2025-02-01      # if WP had a 'modified' date
slug: "original-wp-slug"
locale: "en"
tags: ["wp-category-1", "wp-tag-1"]
readingMinutes: 7
canonical: "/blog/original-wp-slug/"
---

Every field above is something Google or your readers see. Lose any of them and the migration leaks SEO signals.

4. Map the WP schema to Astro JSON-LD

This is where most migrations go wrong. Yoast emits about a dozen application/ld+json blocks per page: Article, Person, Organization, BreadcrumbList, FAQPage, WebSite with SearchAction, WebPage. Astro doesn’t emit any of that by default — you have to.

My base layout includes a jsonLd prop that takes an array of objects:

<Layout
  jsonLd={[articleLd, breadcrumbLd, faqLd]}
>

Each schema gets a separate <script type="application/ld+json"> tag. I always emit:

• Article (or BlogPosting) with headline, image, author, publisher.logo, datePublished, dateModified, inLanguage, keywords and mainEntityOfPage.
• BreadcrumbList for any non-home page.
• Person + Organization on the home page.
• FAQPage if the post or page has a Q&A section.

Run every URL through the Schema.org Validator after launch. If you see fewer schemas than the WP site had, you’ll lose rich-results visibility.

5. Build the 301 redirect map BEFORE going live

This is non-negotiable. Every URL that existed on the WordPress site needs to either:

1. Resolve at the same path on the Astro site (200 OK), or
2. 301 redirect to the new path that has equivalent content.

I write the redirect map as a flat _redirects file (Netlify / Cloudflare Pages syntax):

/2024/03/15/my-post   /blog/my-post   301
/category/news        /blog/tag/news   301
/feed                 /rss.xml         301
/sitemap.xml          /sitemap-index.xml 301

Test every line with curl -I before launch. A redirect that returns 200 instead of 301 is a self-inflicted SEO wound.

6. Run the dual-environment QA pass

Before flipping DNS, host the Astro build on a preview URL and crawl it with Screaming Frog. Compare to the WordPress crawl. You’re looking for:

• Same number of indexable URLs (within 2% — small drift is fine, 10% drift means something’s broken).
• All canonical tags pointing to absolute production URLs.
• All hreflang tags emitted correctly for multilingual sites.
• All meta descriptions present and unique.
• All H1s present and unique per page.

If any of those fail, fix before launch. After launch is too late — Google will recrawl your new mistakes.

7. Submit fresh sitemaps the day of launch

The hour you flip DNS:

1. Re-submit the new sitemap-index.xml in Google Search Console.
2. Re-submit in Bing Webmaster Tools.
3. Use the “URL Inspection” tool in GSC to request indexing on your top 10 traffic pages.
4. Watch the GSC “Coverage” report for the next 7 days — you want to see WordPress URLs flip from Indexed to Page with redirect and the new Astro URLs flip to Indexed.

If you see a spike in Not found (404) errors, you missed a redirect. Find it in the GSC export and add the 301.

8. The first 90 days: don’t panic

Rankings will wobble. This is normal. Google has to re-crawl, re-evaluate the new URLs, and decide they deserve the same rankings. Expected timeline:

• Week 1–2: GSC shows mixed signals. WordPress URLs and Astro URLs both appearing.
• Week 3–4: Most WordPress URLs flip to “Page with redirect” and drop from search results. Astro URLs replace them.
• Week 5–8: Rankings stabilize. Pages may temporarily move up or down by 2–5 positions for their target keywords.
• Week 9–12: New stable state. If your Core Web Vitals are now green where WP was red, you’ll often see small ranking GAINS as Google rewards the better page experience.

Don’t make changes during this window. No URL tweaks, no schema changes, no internal-linking experiments. Let the dust settle, then optimize.

Common migration mistakes I’ve seen (and fixed for clients)

• Forgetting the RSS feed. WordPress emits one at /feed/. Subscribers (and Feedly, and Google News) need a 301 to your new /rss.xml.
• Losing the XML sitemap path. WordPress emits /sitemap_index.xml; Astro emits /sitemap-index.xml by default. 301 the old to the new.
• Skipping the author archive pages. If you ranked for /author/yourname/, redirect it to /about (don’t 404).
• Forgetting to disable WP’s wp-json API. It will keep responding from the WP origin if you didn’t shut it down, and bots will keep crawling it.
• Letting WordPress redirect to login when accessing old URLs. If you keep the WP install running for fallback, set every URL to 301 to the new site — not redirect to /wp-login.php.

When NOT to migrate

WordPress is the right answer if:

• Your content team is large and committed to the Gutenberg editor (Astro requires Markdown or a headless CMS).
• You depend on plugins for forms, e-commerce, membership, or LMS, and replacing them is more work than it’s worth.
• Your traffic is paid (ads), and SEO doesn’t matter — there’s no migration upside.

If none of those describe you, and Lighthouse is consistently below 80, the migration pays for itself in 6–12 months in conversion lift and SEO momentum.

---

If you’re thinking about migrating from WordPress and want a fixed quote on the whole thing (export, redirects, schema, content rewrite, deploy, 30 days of post-launch support), send me a brief — I do these end-to-end, typically in 3–5 weeks for a site of 50–200 posts.