The SEO migration checklist: how to move a website without losing rankings

Most businesses put off moving to a better website for one reason: they are afraid of losing the Google rankings they spent years earning. It is a fair fear. Plenty of migrations do tank traffic. But ranking loss is not a law of nature, it is the result of skipped steps. Do the work in the right order and a migration is one of the safest things you can do to a site.

Here is the checklist I run on every migration, whether it is moving off WordPress, changing platforms, or rebuilding from scratch. Work through it top to bottom and you keep what you have earned.

Why migrations lose rankings in the first place

Google ranks pages, not websites. Every page you rank for is an address (a URL) with content, links pointing at it, and signals attached. A migration goes wrong when those connections break:

• A URL changes and nothing tells Google where it went, so the ranking page 404s.
• The new page exists, but the title, headings, or content that earned the ranking got "cleaned up" and watered down.
• Page speed or mobile usability gets worse, and the ranking slips.
• Redirects are sloppy (chains, loops, or the wrong type), so authority leaks instead of passing through.

Notice that none of these are bad luck. They are all preventable. The checklist below is just the prevention, in order.

Phase 1: Inventory everything before you touch anything

You cannot preserve what you have not written down. Before any rebuild starts:

• Crawl the entire current site (Screaming Frog, Sitebulk, or similar) and export every URL.
• Pull your top pages from Google Search Console and analytics. Know which URLs actually bring traffic and what they rank for. These are the pages you protect with your life.
• Export the current title tags, meta descriptions, and H1s for every page.
• List your backlinks (the external sites linking to you). Those links point at specific URLs, and you want every one of them to keep landing somewhere real.
• Save your existing XML sitemap and robots.txt so you have a reference point.

The output of this phase is a spreadsheet of every URL on the site, ranked by how much traffic and authority it holds.

Phase 2: Map every old URL to a new one

This is the single most important step, and the one most people rush.

• For every URL in your inventory, decide its fate: it stays the same, it moves to a new address, or it is being removed.
• Keep URLs identical wherever you can. The safest migration changes the platform underneath and leaves the addresses alone. If you do not need to change a URL, do not.
• For anything that does move, write a 301 (permanent) redirect from the old URL to the closest matching new one. Not a 302, not a JavaScript redirect, a clean server-side 301.
• Redirect to the most relevant page, not lazily to the homepage. A blanket "redirect everything to home" is one of the fastest ways to lose rankings.
• Avoid redirect chains. Old URL should point straight to the final new URL, not hop through two or three stops.

Phase 3: Preserve the on-page SEO

The new page has to carry the same signals that earned the ranking:

• Bring over title tags and meta descriptions exactly, unless you have a deliberate reason to improve one.
• Keep the H1 and heading structure. The words in your headings are part of why you rank.
• Migrate the full content. Do not "trim" your best pages during a redesign. Thin content ranks worse. If a page is long because it is thorough, keep it long.
• Carry over structured data (schema markup). If the old page had Article, Product, FAQ, or LocalBusiness markup, the new one needs it too.
• Preserve image alt text and filenames where they matter for image search.

Phase 4: Keep the technical foundation intact (or better)

A migration is the moment to improve technical health, not break it:

• Match or beat the old page speed. Core Web Vitals are a ranking factor and a conversion factor. A modern build should be faster, that is half the point of moving.
• Confirm mobile usability. Most traffic and most ranking evaluation is mobile-first.
• Set canonical tags correctly so you do not create duplicate-content confusion.
• Generate a fresh XML sitemap of the new URLs.
• Check robots.txt is not accidentally blocking the new site (this happens constantly when a staging site goes live with its "block everything" rules still in place).

Phase 5: Build and QA on staging

• Build the new site in parallel on a private staging URL so the live site keeps running and earning the whole time.
• Block staging from being indexed (password or noindex) so Google never sees a duplicate.
• Test the redirect map on staging before launch. Every old URL should resolve to the right new page.
• Review every important page against your inventory. Title, headings, content, schema, all present and correct.

Phase 6: Launch day

• Push the new site live on the same domain.
• Activate the redirects at the server level.
• Remove the noindex / password from the new site (and double-check robots.txt).
• Submit the new XML sitemap in Google Search Console and request indexing of your top pages.
• Crawl the live site immediately to catch any broken redirect, 404, or stray noindex before Google does.

Phase 7: Monitor for the next few weeks

Rankings can wobble briefly after a move while Google re-crawls. That is normal. Sustained loss is not. So watch:

• Search Console coverage and 404 reports for anything that slipped through the redirect map.
• Rankings and organic traffic for your top pages, daily at first.
• Crawl stats, to confirm Google is finding and processing the new site.

Fix issues the moment they appear and the wobble settles. Skip the monitoring and small problems compound into real loss.

The mistakes that cause almost all the damage

If a migration loses rankings, it is almost always one of these:

• No redirect map, or a lazy one that dumps everything on the homepage.
• Content "cleaned up" and shortened during the redesign.
• Staging site launched with its noindex or robots block still on.
• A slower, heavier new site than the one it replaced.
• Nobody watching Search Console afterward, so problems sat for weeks.

Every one is avoidable with the checklist above.

Do you have to do all this yourself?

No. This is exactly the work I do on every migration, and it is why I can move a site off slow, dated WordPress onto a fast modern build without losing rankings. Same domain, every URL preserved, content and structured data carried over, staged for your approval, then monitored through the move.

If you would rather not run this checklist yourself, send me your site for a free WordPress audit and I will map out exactly what a migration would preserve, and what it would improve.