The SEO Migration Checklist: Move Your Site Without Losing Rankings

Migrations Do Not Fail Randomly

There is a version of this story that most business owners have either lived through or heard from someone who did. The new site launches. It looks better. Everyone is pleased for about eleven days. Then someone notices the phone is quieter, pulls up analytics, and finds that organic traffic fell by half the week the site went live and has not come back.

That outcome is common. It is also almost entirely avoidable, and the reason is worth stating plainly: migrations do not lose traffic randomly. They lose traffic through a short list of specific, identifiable mistakes, and every one of them can be prevented by work done before launch rather than repaired afterward.

The awkward part is that repair is much harder than prevention. Once the old site is gone, the data you needed to diagnose the drop is gone with it. You are left guessing at which of two hundred simultaneous changes caused the problem.

This checklist is the process we run on replatforming projects. It applies whether you are moving from Squarespace to WordPress, Wix to WordPress, Webflow to WordPress, one WordPress host to another, or a legacy custom build to anything at all.

What Counts as a Migration

The word covers more ground than most people realize, and the risk profile is different for each type. It is worth naming which one you are actually doing, because a project often turns out to be four of these at once.

Platform or CMS migration. The content management system changes. Templates, URL patterns, markup, and hosting all change with it. This is the highest risk category because almost everything moves at once.

Domain migration. The address changes, usually through a rebrand or a merger. Every URL on the site changes by definition.

Protocol migration. HTTP to HTTPS. Increasingly rare now, but still shows up on older sites, and it is technically a full URL change.

URL structure change. Same platform, different paths. Someone flattens the folder structure, or removes dates from blog URLs, or reorganizes a service section.

Redesign. The platform and URLs stay the same but templates and content change. Lower risk than it looks on paper, and higher risk than people expect in practice, because redesigns quietly delete content.

Consolidation. Two or more sites merge into one. This carries all the risk of a domain migration plus the added problem of deciding which of two competing pages survives.

If your project is more than one of these, the checklist does not change, but the URL mapping work multiplies and the argument for phasing the release gets stronger.

Phase One: Benchmark Everything Before You Touch Anything

This is the phase people skip, and skipping it is what turns a recoverable problem into an unsolvable one.

You are building two things here. The first is a complete inventory of what exists, so nothing gets left behind. The second is a performance baseline, so that when someone asks in six weeks whether traffic is down, you can answer with numbers instead of impressions.

Crawl the entire existing site. Every URL, with its title tag, meta description, H1, word count, status code, and canonical tag. Screaming Frog or Sitebulb will do this. Export it to a spreadsheet and keep it somewhere that is not the website.

Export Search Console performance data. Sixteen months, by page and by query, with clicks, impressions, and average position. This is the single most valuable file you will produce, because it tells you which URLs are actually earning traffic rather than which ones someone assumes are important.

Export GA4 data. Sessions, conversions, and revenue by landing page for at least the last twelve months. Search Console tells you what ranks. GA4 tells you what pays.

Take a ranking snapshot. Current positions for every keyword you track, dated. Screenshots are fine. What matters is having a fixed point of comparison that nobody can argue with later.

Export your backlinks. Which external sites link to which specific URLs on your domain. Any of the major SEO tools will give you this. These URLs are non-negotiable redirect targets, and a page with fifty inbound links matters even if it gets four visits a month.

Save the current XML sitemap and robots.txt. Both as files. They are the fastest way to spot what changed.

Note your Core Web Vitals baseline. So that when the new site is slower, you find out from your own testing rather than from a ranking drop two months later.

Do all of this before a single page of the new site is built. It takes a day and it is the difference between a migration you can manage and one you can only apologize for.

Phase Two: Build the URL Map

The URL map is the spine of the whole project. It is a spreadsheet with one row per old URL and one column for its new destination.

Start from the union of three sources: your crawl, your Search Console export, and your backlink export. The crawl finds every page the site links to. Search Console finds pages that earn traffic even when nothing links to them. The backlink export finds pages that other sites point at, including ones that were orphaned years ago. Any of these alone will miss URLs. Together they rarely do.

Then apply four rules.

Rule one: keep the URL if you possibly can. An identical URL needs no redirect, breaks no link, and carries no risk. If the new platform can reproduce your existing structure, reproduce it. Vanity improvements to URL structure are the most expensive cosmetic change in web development, and they almost never earn back what they cost.

Rule two: map one to one, to the closest equivalent page. The old services page goes to the new services page. Not to the homepage. Not to a category listing. When a search engine follows a redirect and finds a page unrelated to the one it requested, it treats the result as a soft 404 and drops the original page from the index. Mass redirects to the homepage are the most reliable way to destroy a site's rankings while believing you handled redirects properly.

Rule three: no chains and no loops. If the site has redirects from a previous migration, resolve them. Old URL A should point directly at final URL C, not at intermediate URL B which then points to C. Chains dilute value, slow crawling, and break entirely once they get long enough.

Rule four: use 301, permanently. A 301 signals a permanent move. A 302 signals a temporary one and tells search engines to keep the old URL indexed. Use 302 only when the move genuinely is temporary, which on a migration it is not. And leave the redirects in place for good. They cost nothing to keep and the inbound links pointing at your old URLs will never be updated by the people who made them.

For pages you genuinely intend to remove, decide deliberately. If it has traffic or links, redirect it to the nearest relevant page. If it has neither and never will, let it return a 410 and move on. A deliberate 410 is fine. An accidental 404 is not.

Phase Three: Preserve What Is On the Page

A redesign is where content quietly evaporates. The new template is cleaner, the copy gets tightened, a paragraph is cut for balance, and a page that ranked because it answered a question thoroughly now answers it in half the words.

Search engines noticed the thoroughness. Removing it removes the reason the page ranked.

Work through this for every page that earns traffic:

• Title tags. Carried over exactly, unless you have a specific reason to change one. Do not let a new theme append a site name to every title and blow past the display limit.
• Meta descriptions. Carried over. New platforms often regenerate these from the first paragraph, which is rarely an improvement.
• H1 and heading structure. One H1 per page, matching the old one. Many themes wrap the logo in an H1 by default, which quietly removes the real H1 from every page on the site.
• Body copy. Same content or more, not less. If you are rewriting, rewrite to be more complete rather than more concise.
• Internal links. Rebuilt in the new structure and pointing at new URLs directly, not through redirects. Internal links are how search engines understand which pages matter, and they are the most common casualty of a template change.
• Structured data. Schema markup rarely survives a platform change, because it was usually generated by a plugin the new platform does not have. Rebuild it. This matters more every year as AI answer engines lean on it, which we cover in our guide to AI search optimization.
• Images and alt text. Same images, same filenames where possible, alt text preserved. Image search traffic is real, and it disappears silently.

Phase Four: Reach Technical Parity

Before launch, the new site needs to be at least as technically sound as the old one. Not better. Better is a separate project. Equal is the bar.

robots.txt. Written for production, not copied from staging. This one line has ended more migrations than any other.

XML sitemap. Generated from the new URL structure, containing only canonical, indexable, 200-status URLs. No redirects in the sitemap, no 404s, no noindex pages.

Canonical tags. Self-referencing on every page. Check that the new platform is not canonicalizing everything to the homepage, which some themes do out of the box.

Pagination and faceted URLs. Any parameter-based URLs the old site handled need to be handled the same way, or they will generate thousands of duplicate pages the moment the crawler finds them.

Hreflang, if you run more than one language or region. It rarely survives a platform change intact.

Site speed and Core Web Vitals. Test the new site against your recorded baseline. A rebuild that ships uncompressed hero images and four font families will be slower than the site it replaced, and you will feel it.

Mobile rendering. Indexing is mobile first. Whatever the mobile version does not show does not exist.

HTTPS and mixed content. Valid certificate, no assets loading over HTTP, no redirect loop between the www and non-www versions.

Phase Five: Staging QA

Two things happen on staging, and the second one is where people get hurt.

Block staging from being indexed. Use HTTP authentication rather than a noindex tag. Authentication cannot be forgotten at launch, because if it is still on, nobody can reach the site and you will know within a minute. A forgotten noindex tag, by contrast, is invisible. The site looks perfect and disappears from search over the following two weeks.

Test the redirect map on staging. Take the full list of old URLs, run them through the redirect rules, and confirm every single one returns a 301 to the intended destination in one hop. Not a sample. All of them. This is a scripted check that takes minutes and catches the failure that costs the most.

Then walk the rest: forms submit and the submissions arrive somewhere a human reads, tracking fires, the ecommerce checkout completes a real transaction, search works, every template renders on a phone.

Phase Six: Launch Day, In Order

Sequence matters more than speed.

1. Confirm you have a rollback plan and a current backup of the old site, files and database.
2. Push the new site live with the redirect rules already active, not added afterward.
3. Remove staging protections. Verify robots.txt and check the live source for stray noindex tags before doing anything else.
4. Crawl the live site immediately. You are looking for 404s, redirect chains, missing titles, and unexpected noindex directives.
5. Spot check thirty of your highest traffic old URLs by hand. Confirm each lands on the right page.
6. Submit the new XML sitemap in Search Console.
7. If the domain changed, use the Change of Address tool in Search Console and keep the old property verified.
8. Confirm analytics and conversion tracking are recording on the live site.

Launch on a Tuesday morning. Not Friday afternoon. The problems you find on day one are easy to fix if the people who built the site are at their desks.

Phase Seven: The First Seventy Two Hours

Watch four things, and no others.

Search Console coverage. Errors will appear. Rising 404s means URLs you missed in the map, and each one is a fixable gap.

Server logs or crawl stats. Crawler activity should spike as the new structure gets discovered. A crawl rate that goes flat is a signal that something is blocking access.

GA4 real time. Traffic present and tracking firing. A silent analytics property usually means a missing tag rather than an empty site, but you need to know which within the hour.

Manual spot checks. Search your brand name. Search three head terms. Look at what actually appears.

Resist the urge to change anything else during this window. Every additional change makes the next diagnosis harder.

Phase Eight: Weeks One Through Eight

Here is the part nobody tells clients, so it is worth being direct about it: a dip is normal.

Search engines need to recrawl every redirected URL, follow it, process the destination, and reassign the signals. That takes time proportional to your site's size and crawl budget. During that window, rankings fluctuate.

What normal looks like:

• Week one. Fluctuation. Some queries move noticeably. Do not react.
• Weeks two to three. Traffic within roughly ten percent of baseline for small sites. Larger sites are still in motion.
• Weeks four to six. Recovery to baseline. Pages that were improved start to gain.
• Weeks six to eight. Stable, and typically ahead of the old site if the new one is genuinely faster and better structured.

What is not normal: a drop of thirty percent or more that has not begun recovering by week three. That is not the migration settling. That is a specific defect, and the first four places to look are the redirect map, the robots.txt file, the live source for a stray noindex, and whether page content was shortened during the rebuild.

Keep the old site's backup for at least ninety days. If something is genuinely wrong, being able to compare the old page against the new one answers the question in minutes.

What Actually Goes Wrong

Across the migrations we have cleaned up after other people, the same six failures account for nearly all of the damage.

The redirect map was built from the sitemap only. It missed every orphaned page that still earned traffic and every page with inbound links that was not linked internally.

Everything was redirected to the homepage. Handled in bulk, felt complete, and functioned as a mass delete.

The staging noindex tag shipped to production. The site looked perfect and vanished from search over about two weeks.

Content was trimmed during the redesign. Pages that ranked for being thorough became pages that were merely tidy.

Internal links were never rebuilt. The new navigation covered the top level and every contextual in-body link from the old site was dropped, taking the internal link structure with it.

Nobody benchmarked first. Traffic dropped, nobody could prove by how much or from which pages, and the diagnosis turned into an argument.

A Migration Is an SEO Project With a Design Component

This is the honest framing. The visual design is the visible part and the part everyone discusses in meetings. The part that determines whether the business still gets leads in October is the URL map, the redirect rules, and the content parity check.

If your site earns meaningful revenue from search, the person running the migration should be someone who thinks in redirects. A designer who has not done this before will build you a better looking site and, with no ill intent, hand you a traffic problem that takes six months to unwind.

For the platform decision itself, we have written the comparisons in detail: Wix vs WordPress, Webflow vs WordPress, and Squarespace vs WordPress. If you are still weighing options, we have also worked through Wix alternatives, Squarespace alternatives, and Webflow alternatives.

If you have already decided, the platform-specific routes are covered step by step: Squarespace to WordPress, Webflow to WordPress, and Wix to WordPress. For a CRM move where the website is also in play, see HubSpot to GoHighLevel.

Frequently Asked Questions

Will I lose rankings when I migrate my website?

A short dip is normal and a permanent loss is not. On a well-executed migration you should expect organic traffic to move within roughly ten percent of baseline for two to four weeks while search engines recrawl and reprocess the site, then return to baseline or better. Permanent losses of thirty percent or more almost always trace back to a specific, preventable mistake: missing redirects, redirect chains, a staging noindex tag left in place, or page content that was quietly shortened during the rebuild.

What is the most common cause of traffic loss after a website migration?

Incomplete URL mapping. The new platform generates different URLs, only the pages someone remembered get redirected, and everything else returns a 404. The second most common cause is redirecting large numbers of old URLs to the homepage instead of to the closest matching page, which search engines treat as a soft 404 and which drops the page entirely. Third is a noindex directive or a robots.txt disallow that was correct on staging and never removed at launch.

How long does it take for a site to recover after a migration?

For a small site of under two hundred pages, most of the recrawl happens within two to three weeks. For sites in the thousands of pages, expect six to eight weeks before the picture is stable, and longer for very large sites. Recovery speed is driven mostly by how quickly search engines can recrawl the redirected URLs, which is why submitting a clean sitemap and keeping the old sitemap available for a period both help.

Should I redesign and replatform at the same time?

You can, and most businesses do because doing it twice costs more. The tradeoff is diagnostic. When you change the platform, the URLs, the design, and the content in one release and traffic drops, you cannot tell which change caused it. If the site carries meaningful organic revenue, the safer sequence is to replatform first with URLs and page content held constant, confirm stability for two to three weeks, then ship the design and content changes.

Do I need to keep my old URLs after migrating?

If you can keep the URL structure identical, do it, because it removes the single largest source of migration risk. When the new platform will not allow it, every old URL that had traffic, rankings, or inbound links needs a 301 redirect to the closest equivalent page. Keep those redirects in place permanently rather than for a few months. They continue to pass value from links pointing at the old addresses, and those links rarely get updated.

What should I benchmark before a website migration?

At minimum: a full crawl of the existing site with URLs, titles, meta descriptions, and headings; a sixteen month export of Search Console performance data by page and query; GA4 sessions and conversions by landing page; a current ranking snapshot for the keywords you care about; and a backlink export showing which URLs external sites link to. Capture all of it before anything changes. Once the old site is gone you cannot recreate this data, and without it you cannot prove what changed or diagnose why.

Planning a Move

If you are about to migrate, the most useful hour you can spend is the one before anything gets built, mapping what you have against what the new platform can reproduce.

Get a free Revenue Opportunity Analysis and we will show you which of your current pages are earning the traffic, which URLs carry inbound links you cannot afford to break, and what the redirect map needs to cover. See how we handle builds and rebuilds in WordPress development and SEO management, or read our process. Book a strategy call or call us at 321-401-7016.