DEV Community

Daniel Max
Daniel Max

Posted on AI-assisted

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

#cloudflare #webdev #seo #astro

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: /
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

I also check for redirect chains such as:

A -> B -> C
Enter fullscreen mode Exit fullscreen mode

and replace them with:

A -> C
Enter fullscreen mode Exit fullscreen mode

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:

  1. Remove staging noindex restrictions.
  2. Confirm robots.txt.
  3. Confirm sitemap URLs.
  4. Test important 301 redirects.
  5. Test intended 404 and 410 responses.
  6. Verify canonical tags.
  7. Verify structured data.
  8. Connect the production domain.
  9. Crawl the live site again.
  10. 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.

Top comments (0)