WordPress to Astro Migration Without Losing Rankings

The Export File Nobody Reads

The owner sent me the WordPress export the way most people do: a single XML file, dragged into an email, with the note “everything’s in here, when can we go live.”

I opened it before I answered. Two thousand one hundred entries. Posts, pages, a custom post type for case studies someone built in 2019, four taxonomies, and a media library that referenced images on a CDN that had been cancelled. About sixty of those URLs carried almost all of the site’s organic traffic. The other two thousand were tag archives, paginated category pages, and attachment pages WordPress generates whether you want them or not.

He thought the migration was the rebuild. The rebuild was the easy part.

Astro Doesn’t Migrate WordPress — You Do

There is no button. The appeal of Astro is exactly what makes the move careful work: it doesn’t carry a database, a theme layer, or a plugin ecosystem across for you. You decide what each old URL becomes. That decision is the whole project.

WordPress invents URLs on your behalf. /?p=412, /category/news/page/3/, /tag/croatia/, /2021/04/, an attachment page for every uploaded image. Some of those rank. Most don’t. A few rank for things you’d never guess until you look. Astro gives you the opposite: nothing exists until you create a route for it. The gap between those two models is where rankings disappear.

So the work isn’t “rebuild the site in Astro.” The work is: take inventory of every address Google currently knows, decide its fate, and prove the decision held.

Inventory Before Design

Before anyone picks a color, you need three lists.

The first is what Google has indexed — pull it from Search Console’s Pages report, not from the WordPress admin. The admin shows what you published. Search Console shows what actually ranks, including the attachment and archive URLs you forgot existed.

The second is what earns links and traffic. Export the top pages by clicks and the top pages by referring domains. This is your protected set. Everything here must survive the move with its path intact or with a deliberate redirect.

The third is everything else — the long tail of thin archives and parameter URLs. Most of this should not be rebuilt. It should be redirected to its nearest meaningful parent or, where it never had value, allowed to 404 on purpose. A migration is also a pruning. You are not obligated to carry forward every URL WordPress generated. You are obligated to decide about each one.

Path Parity Is the Whole Game

Here is the rule that does the heavy lifting: keep the URL the same whenever you can.

If a post lived at /how-to-photograph-interiors/, it should live at /how-to-photograph-interiors/ in Astro. Not /blog/how-to-photograph-interiors/. Not /writing/how-to-photograph-interiors/. The same string. When the path doesn’t change, there is nothing to redirect, nothing to re-crawl, no authority to transfer. The ranking simply continues.

Astro lets you do this cleanly because routes are just files. A post at /how-to-photograph-interiors/ is a page that builds to that path — you control it directly, with none of WordPress’s permalink rewriting underneath. Match the old structure first. Improve it later, deliberately, one redirect at a time, after the dust has settled. Changing the design and the URLs in the same release is how a site loses two things at once and can’t tell you which one broke it.

The Redirect Map Is the Deliverable

For every URL that does change — and there will be some, because WordPress’s machine-generated paths are ugly and worth retiring — you write a permanent 301. Old path on the left, new path on the right. One row per URL, no chains, no guessing.

On Cloudflare Pages, where this kind of Astro site usually lands, that map lives in a _redirects file. It is plain text, it ships with the build, and it is the single most important artifact of the migration. Not the homepage. The redirect map. A photographer’s portfolio I moved last year had four hundred lines in that file and twelve pages in the actual site. That ratio is correct. The redirects are the bridge the old authority walks across.

Prove It, Then Cut Over

Build the whole thing on a preview URL first. Then crawl it. Run a crawler against your protected set and confirm every old URL either returns 200 at the same path or 301s to exactly one destination. No 404s in the protected set. No redirect pointing at another redirect. The structured data — the BlogPosting, the breadcrumbs, the author reference — present on every page that had it on WordPress.

Only when that crawl is clean do you point the domain. The night you cut over, you submit the new sitemap to Search Console and request indexing on the protected set. Then you watch, daily, for the first two weeks. Re-indexing takes Google two to six months regardless of how clean your work is. With path parity and a tight redirect map, the dip is shallow and short. Without them, you have rebuilt a site that Google can no longer find.

The fast pages are the reward. They are not the goal. The goal is that the move is invisible to everyone except the people watching the load time drop.

---

Related

• Article: How to Migrate a Website Without Losing SEO — The platform-agnostic systems checklist behind the WordPress-to-Astro mechanics above.
• Article: Static Sites vs WordPress: What Your Business Actually Needs — Whether you should make this move at all before you plan how.
• Article: Why WordPress Sites Get Slow — The performance problem that sends most teams looking at Astro in the first place.
• Service: Web Presence & Performance Sites — Astro migrations run as infrastructure work, with the redirect map treated as a deliverable.
• Deep Dive: Why “Digital Transformation” Mostly Fails for SMBs — Why a platform change that preserves outcomes beats one that just swaps the stack.

Planning a move off WordPress and worried about the rankings you’ve spent years earning? See how I approach it at ivanboban.com.