Protect Rankings: Site Migration SEO Checklist for Marketing Managers

Yes, you can move, replatform or rebuild a website without losing your search rankings, but only if SEO sits inside the project from day one, not bolted on the week before launch. The three actions that decide the outcome are a complete URL mapping and 301 redirect plan, a clean sweep for staging leftovers like noindex tags and blocked robots.txt files, and disciplined monitoring in the days after launch. Domain changes and heavy content rewrites carry more risk than a simple replatform, so treat those with extra care.

TL;DR:

• Proper SEO during migration requires establishing a complete URL inventory and a detailed 301 redirect plan before development begins.
• Domain changes pose the highest risk, often requiring several weeks to months for rankings to recover after a thorough, correct migration.
• Staggering multiple changes, like domain, URL structure, and platform, helps isolate variables and reduces the risk of ranking drops.
• Post-launch monitoring should focus on index coverage, redirect errors, crawl activity, and traffic trends over at least six weeks.
• Common mistakes that cause prolonged ranking issues include incorrect redirects, leftover noindex tags, and redirects chains longer than one hop.

What is site migration SEO and why do rankings move?

Site migration SEO is the discipline of protecting search visibility while you change something fundamental about how your website is built, hosted, or structured. That could mean moving from Wix to WordPress, switching hosting providers, changing your domain name, restructuring your URLs, or moving to HTTPS. Each of these changes something Google uses to understand and rank your pages, which is why rankings wobble even when nothing about your content or offer has changed.

Search engines build their understanding of your site around URLs. Every ranking signal, from backlinks to click history to topical relevance, gets attached to a specific address. When you change that address without telling Google clearly, the signal doesn’t automatically follow. A 301 redirect is effectively you saying “this page has permanently moved here, please transfer everything you know about the old one.” Skip that step, or get it wrong, and the search engine has to work it out for itself, which it does slowly and imperfectly.

Crawl budget matters here too. Google allocates a finite amount of crawling attention to your site based on its size, authority and server responsiveness. During a migration, that budget gets spent re-verifying URLs, following redirects, and re-indexing pages it had already catalogued. A messy redirect chain or a bloated URL structure eats into that budget and slows down how quickly your new site gets properly understood.

The riskiest migrations combine multiple changes at once. Moving domains while also rewriting all your content, restructuring your navigation, and changing your CMS is common, particularly for a CMS migration to WordPress from a locked-in platform. But every simultaneous change is another variable that makes it harder to diagnose what caused a ranking drop if one appears. Whenever the project allows it, separate the technical migration from the content overhaul. Migrate the site first, stabilise it, then redesign the content on top of a platform that’s already proven stable. This single decision does more to reduce migration risk than almost any technical fix.

Which type of migration carries the most SEO risk?

Domain changes carry a high risk of any migration type, because you’re asking Google to transfer trust from one address to an entirely different one. Replatforming (say, migrating from Squarespace to WordPress) without changing URLs sits at the lower end of the risk scale, provided the underlying structure stays intact.

Here’s how the common migration types stack up against each other:

• Domain change (old-domain.co.uk to new-domain.co.uk): highest risk. You’re transferring backlink equity, brand signals and historical trust to a domain Google has no history with. Recovery, when done well, often takes several weeks to a few months; the timeline depends on the quality of the migration.
• Replatform without URL changes (e.g. moving CMS but keeping the same URL structure): lower risk. If the URLs stay identical, Google barely notices anything happened beyond a server change, provided the new platform doesn’t introduce technical faults.
• URL structure change (changing folder paths, removing dates from blog URLs, restructuring categories): moderate to high risk, entirely dependent on redirect accuracy. Every single URL needs a corresponding 301, and missing even a small percentage of high-traffic pages causes disproportionate damage.
• HTTP to HTTPS migration: low risk when implemented correctly, since Google has handled this transition for years and treats it as a like-for-like move when redirects are clean.
• Content consolidation (merging thin pages, removing duplicates): moderate risk, because you’re not just changing addresses, you’re changing what exists. Old rankings for consolidated pages need to transfer to the surviving URL.

A sensible way to reduce exposure across all of these is phasing. If you’re changing domain, platform and URL structure together, consider staggering the work: stabilise the new domain first with an identical structure, then restructure URLs in a second, separate phase once rankings have settled. It’s slower, but it isolates variables so you know exactly what to blame if something goes wrong.

Pre-migration checklist: what to do before anyone touches the code

Everything you do before development starts is about capturing a baseline and building the map that developers will follow. Skip this stage or rush it, and you’re building a house without a foundation survey.

1. Export your Search Console data. Pull performance reports for the last 16 months (the maximum Search Console retains), covering top pages, top queries, click-through rates and index coverage status. This is your before-and-after benchmark.
2. Pull analytics baselines. Record organic sessions, conversion rate by landing page, and revenue or lead volume attributable to organic traffic. You’ll need these numbers to prove, or disprove, that the migration caused any drop.
3. Audit your backlink profile. Identify which external domains link to which of your pages, prioritising by referring domain authority. These are the URLs that most need a flawless redirect, since a lost backlink to a 404 page is lost link equity you won’t easily win back.
4. Crawl the live site. Use a crawler such as Screaming Frog or Sitebulb to capture every indexable URL, its current status, title, meta description, and internal link count. This becomes your master URL inventory.
5. Build the URL inventory and prioritise it. Rank every URL by organic traffic and backlink count so developers know which redirects need triple-checking and which are lower stakes.
6. Create the 301 redirect map. This is a spreadsheet, not a vague instruction. Old URL, new URL, redirect type, priority. Hand it to developers as a literal build document, not a reference to consult if they remember.
7. Write a rollback plan. Decide in advance what conditions trigger reverting to the old site (a certain drop in indexed pages, a spike in server errors) and who has authority to make that call.
8. Lower your DNS TTL. Google recommends lowering TTL at least a week before a site move and scheduling the actual DNS switch during a period of low traffic, which reduces propagation delay and limits how many visitors hit an inconsistent state.
9. Block the staging environment properly. Use password protection or IP whitelisting rather than relying solely on robots.txt or noindex tags, since those can accidentally survive the move to production if nobody remembers to remove them.

Where your CMS export is missing historical titles or meta descriptions, particularly common when migrating from Squarespace to WordPress or off an ageing bespoke build, the Wayback Machine can often recover what the old pages actually said, which is invaluable for rebuilding an accurate redirect map.

Pro Tip: *Don’t rely on memory or “we know our top pages” when prioritising the redirect map. Cross-reference Search Console clicks against backlink authority.

Build and staging validation: what to test before launch

A staging environment is only useful if it behaves exactly like production will. The single most common failure at this stage is a staging site that looks right visually but has different server headers, different canonical logic, or hardcoded absolute URLs that will break the moment the domain changes. These differences are invisible until you specifically go looking for them.

Run these checks against staging before you even think about a launch date:

• Crawl staging with a proper SEO crawler to confirm robots.txt isn’t blocking anything it shouldn’t, and that no noindex tags have crept onto pages that need to remain indexable.
• Check canonical tags point to the correct final URLs, not to staging addresses or old URLs left over from a previous version of the site.
• Inspect X-Robots-Tag HTTP headers, since these can silently override what’s in your HTML and are easy to miss if you’re only checking on-page tags.
• Validate structured data using Validator to confirm schema markup for products, reviews, articles or FAQs migrated correctly and still generates rich results.
• Confirm sitemap generation is automatic and accurate, listing only canonical, indexable URLs, not staging URLs, redirected pages, or noindex pages.
• Test your redirects, both by sampling manually and by running an automated crawl of your entire redirect map, checking that each old URL returns a 301 (not a 302) and lands on the correct final destination in one hop with the help of automated SEO audits.
• Benchmark Core Web Vitals on staging before launch, so you have a genuine comparison point for post-launch performance rather than guessing whether a slowdown is real or perceived.
• Confirm your analytics and Search Console properties are correctly configured for the new environment, including a fresh property verification if the domain has changed.

Redirect chains and hops are worth eliminating at this stage rather than after launch, since Google’s own guidance is clear that server-side, single-hop 301s are preferable to anything that bounces through two or three intermediate URLs. Every additional hop adds latency and slightly increases the risk that a crawler gives up before reaching the final destination.

It’s also worth checking that internal links across the new site point directly to final URLs rather than routing through the redirect map. Updating internal links to their final destination avoids wasting crawl budget on unnecessary redirect hops, something that’s easy to overlook when a build has been done in a hurry.

Launch day: the first 24 to 72 hours

Launch day itself is short, intense, and unforgiving of missed steps. Work through this sequence methodically rather than checking things at random, because the order in which problems surface often tells you exactly where to look.

1. Confirm robots.txt is the production version, not a staging file that blocks crawling, and check there’s no stray sitewide noindex tag anywhere in the template.
2. Spot-check critical pages return a 200 status, prioritising your highest-traffic and highest-converting URLs first.
3. Verify redirects return 301, not 302, and that each one resolves in a single hop to its correct destination.
4. Use URL Inspection in Search Console on your priority pages to check how Google is currently rendering and indexing them, and request indexing manually for anything urgent.
5. Submit your new sitemap(s) to Search Console, and if you’ve changed domain, run the Change of Address tool, which notifies Google directly and keeps that notification active for 180 days while you maintain redirects.
6. Watch server logs for Googlebot activity, confirming it’s actually crawling the new URLs and not repeatedly hitting old ones that should be redirecting.
7. Check for spikes in 4xx or 5xx errors in Search Console’s coverage report and your server monitoring, since a sudden jump usually points to a redirect gap or a server misconfiguration.
8. Validate that analytics data is flowing correctly, comparing session counts against your pre-migration baseline to catch tracking code issues immediately rather than a week later.
9. Reinstate your normal DNS TTL once propagation has settled and the new site is stable, since the lowered TTL from the pre-migration phase was only ever meant to be temporary.

None of these checks take long individually, but skipping even one, particularly the redirect status codes or the robots.txt check, is how a technically sound migration turns into a weeks-long recovery project.

Post-launch monitoring: what to watch and how to fix it

The days immediately after launch are when problems surface, but the weeks that follow are when you find out whether you’ve actually protected your rankings. Watch these signals closely:

• Impressions and clicks by landing page in Search Console, compared week-on-week against your pre-migration baseline, broken down by your highest-value URLs first.
• Index coverage status, checking specifically for pages marked “Discovered, not indexed” or “Crawled, not indexed”, which often signal a canonical or content issue rather than a simple crawl delay.
• Crawl errors and 404s, which point directly to gaps in your redirect map that nobody caught during testing.
• Redirect chains, since these sometimes only appear once real user traffic and real crawler behaviour interact with the live site in ways staging never quite replicated.

Triage in a specific order rather than tackling whatever feels most urgent. Fix staging leftovers and redirect gaps first, because these are usually the highest-impact, fastest-to-fix issues. Only once those are clean should you move on to canonical inconsistencies and performance regressions, which tend to have a slower, more gradual effect on rankings rather than the sharp drop-offs caused by broken redirects.

If a priority page still isn’t indexed after a week despite everything looking correct, request indexing again through URL Inspection rather than waiting indefinitely. If you’re aware of external sites linking to your old URLs, particularly high-authority ones, it’s worth a polite email asking them to update the link directly rather than relying on the redirect indefinitely; direct backlinks to your final URL outperform link equity passed through a redirect, even a correctly configured one.

Keep your old redirects live for a minimum of twelve months, longer if you moved domain. Google’s guidance around the Change of Address tool specifically recommends maintaining redirects well beyond the 180-day notification window, since backlinks and bookmarks pointing to old URLs don’t disappear just because Google has processed the move.

Pro Tip: Set a recurring calendar reminder to re-check your redirect map three, six and twelve months after launch. Old external links surface slowly, and a redirect map that was complete on day one often needs small additions as forgotten pages get discovered.

Common mistakes that turn a migration into a hangover

A “migration hangover” is the industry term for a traffic drop that lingers far longer than the normal settling period a search engine needs to re-crawl and re-rank a changed site. In severe cases, a hangover caused by fundamental errors can persist for 12 to 18 months, which is an entirely avoidable outcome if the root causes are caught early.

• Missing or incorrect 301 redirects. The most damaging version of this is redirecting every old URL to the homepage rather than its true equivalent. It looks like a redirect exists, so it passes a casual check, but Google treats a homepage catch-all as a poor signal and rankings for that specific page rarely transfer.
• Robots.txt or noindex tags left over from staging. This is quietly one of the most common causes of a stalled migration, because everything else about the page looks correct. The content’s there, the redirect works, but Google simply won’t index it.
• Canonical tags pointing to old URLs. If your canonical tag still references the pre-migration address, you’re actively telling Google to ignore the new URL in favour of one that may no longer exist.
• Redirect chains of two or more hops. Individually survivable, but at scale across thousands of URLs they slow indexing significantly and waste crawl budget that could be spent discovering new content.
• Analytics tracking gaps. If your tracking code didn’t migrate correctly, you’ll misread a data problem as a traffic problem, wasting time investigating a drop that never actually happened.

How do you tell normal post-migration volatility from a genuine hangover? Some fluctuation in the first two to four weeks is expected and usually self-corrects. What demands escalation is a coverage report full of “Discovered, not indexed” pages after three weeks, a 404 error count that isn’t shrinking, or organic traffic still down by a significant margin after six weeks with no clear recovery trend. At that point, stop waiting and start auditing the redirect map and staging leftovers line by line.

How migration projects can be approached

We’ve handled enough replatforms and redesigns to know that the projects which go smoothly are the ones where SEO is in the room from the first planning conversation, not brought in once development is already underway. Our SEO team works alongside our development team from the audit stage, which means the redirect map gets built at the same time as the site architecture, rather than reverse-engineered afterwards.

A typical sequence for prioritising redirects during a client migration looks something like this:

One recent website project, Kinetik Wellbeing, involved exactly this kind of staged approach, separating the technical rebuild from a full content refresh so that any ranking movement could be attributed to one change at a time rather than guessed at. For businesses weighing up an efficient workflow for a web redesign, that separation between “move it safely” and “make it better” tends to be the difference between a calm launch and a stressful one.

An editorial perspective drawing on migration and SEO project experience is used to advise clients on realistic timelines and trade-offs.

Get migration support that protects your rankings, not just your look

Plenty of agencies will happily redesign your site and leave the redirect map as an afterthought. Building the SEO plan and technical migration side by side ensures that redirect mapping, staging checks, and launch monitoring are handled cohesively by the team designing and developing the new site, avoiding handoffs between multiple suppliers.

If you’re planning a move away from Wix, a switch from Squarespace, or a full website development project that happens to involve changing platforms, we’ll talk you through exactly what a migration will involve for your specific site before any commitment is made, including realistic scope and cost expectations rather than a vague quote. Our SEO service can also run ongoing monitoring once you’re live, catching coverage issues and crawl errors before they become a lingering hangover. For charities and sports clubs weighing up a rebuild, we also offer dedicated charity website design and sports club website design packages that factor migration risk in from the outset. Get in touch and tell us what you’re planning. We’ll give you an honest view of what it’ll take.

Where to check the official guidance

The checklist above draws on established, publicly available guidance rather than agency guesswork, and it’s worth bookmarking these sources directly:

• Google Search Central’s site moves and migrations guide covers DNS timing and crawling behaviour in full technical detail.
• The Change of Address tool in Search Console is the official mechanism for notifying Google of a domain move.
• validator.schema.org confirms your structured data is still valid after a rebuild.
• The Wayback Machine is genuinely useful for recovering old page content and metadata when records are incomplete.
• Screaming Frog and Sitebulb remain the standard crawlers for building URL inventories and auditing redirects at scale, and Search Console itself is your primary tool for verifying indexing after launch.

Sources

• Site moves and migrations | Google Search Central
• Change of Address tool – Search Console Help

FAQ

Recommended

• Essential Website Maintenance Steps for Better SEO
• SEO trends 2026: Strategies for South East success
• 50 SEO Marketing Techniques – Part 1
• Mobile Optimised Pages & Mobile First Indexing