How I’m Planning a WordPress to Astro Migration Without Losing SEO

Daniel Max — Fri, 11 Sep 2026 11:36:53 +0000

I’m currently rebuilding one of my existing WordPress sites with Astro and planning to move the final build to Cloudflare Pages.

The main challenge is not rebuilding the design. It is migrating an already indexed site without unnecessarily changing URLs, losing search visibility, or creating technical SEO problems during the switch.

One project where I’m applying this process is Nulls Brawl. The current site remains live on WordPress while the Astro version is prepared separately.

Here is the migration process I’m following.

1. Keep the Existing Site Live During Development

I do not want the unfinished Astro version indexed while the WordPress site is still serving users.

The staging build therefore stays blocked from search engines until the domain migration is ready.

For example:

User-agent: *
Disallow: /

I also keep staging pages out of the production sitemap.

The important part is removing these restrictions before the final production launch.

2. Map Every Existing URL Before Changing Anything

Before rebuilding routes, I create a list of all important existing URLs and decide what should happen to each one.

Each old URL normally falls into one of these groups:

Keep the same URL
Redirect to a replacement page
Return 410 because the content has intentionally been removed

Keeping the same URLs wherever possible reduces unnecessary migration risk.

For URLs that genuinely move, I use permanent redirects.

A Cloudflare Pages _redirects file can be as simple as:

/old-page/ /new-page/ 301
/old-guide/ /updated-guide/ 301

I avoid redirecting unrelated deleted pages to the homepage just to prevent a 404. If content has no real replacement, a proper 404 or 410 is cleaner.

3. Rebuild SEO Elements Instead of Copying Only the Visible Page

A migration is more than copying HTML and CSS.

For every important page I check:

title tag
meta description
canonical URL
H1 and heading structure
internal links
image alt text
Open Graph data
structured data
indexability

Astro makes it fairly easy to create reusable SEO components, but the values still need to match the intent of each page.

4. Generate the Sitemap From Real Routes

I do not want old, redirected, noindex, or removed URLs appearing in the new sitemap.

The production sitemap should contain only canonical pages that are intended to be indexed.

The same applies to alternate-language URLs. Each language version needs to point to the correct canonical page and, where appropriate, have consistent hreflang relationships.

5. Handle Structured Data Carefully

Schema from the WordPress site should not simply be copied without checking whether it still describes the new page correctly.

For a typical site I may use combinations of:

WebSite
Organization
BreadcrumbList
Article
FAQPage when the visible page genuinely contains FAQs

I prefer generating schema from the same page data used by the Astro templates instead of maintaining unrelated hardcoded values in several places.

6. Test Redirects Before Connecting the Domain

This is one of the most important steps.

Before launch I check:

Old URL -> expected new URL
Old removed URL -> expected 404 or 410
Current URL -> 200
Canonical URL -> correct final domain

I also check for redirect chains such as:

A -> B -> C

and replace them with:

A -> C

where possible.

7. Performance Is Part of the Migration

One reason I like Astro for content-heavy sites is that pages can ship very little client-side JavaScript.

But simply using Astro does not automatically make a site fast.

I still optimize:

image dimensions and formats
font loading
third-party scripts
layout shifts
unused JavaScript
caching
above-the-fold assets

I test real pages rather than relying only on the framework choice.

8. Launch Only After the Technical Checks Pass

My final launch checklist looks roughly like this:

Remove staging noindex restrictions.
Confirm robots.txt.
Confirm sitemap URLs.
Test important 301 redirects.
Test intended 404 and 410 responses.
Verify canonical tags.
Verify structured data.
Connect the production domain.
Crawl the live site again.
Monitor Google Search Console after migration.

I also keep the old URL map after launch because Search Console or crawl data can reveal a missed redirect later.

What I’m Trying to Avoid

The mistakes I am specifically trying to prevent are:

changing URLs without a reason
publishing staging URLs
redirecting every removed page to the homepage
leaving old WordPress URLs in the sitemap
accidentally shipping noindex to production
creating redirect chains
copying outdated schema
rebuilding the design while forgetting internal links

A framework migration should ideally be boring from a search engine’s perspective. The implementation can change completely while the meaning, URLs, and relationships between important pages remain stable.

That is the approach I’m following while moving this project from WordPress to Astro and Cloudflare Pages.

DEV Community: Daniel Max