The migration in five stages
- Record the baseline
- Map every old URL
- Check staging
- Launch and submit
- Monitor for a year
What is a B2B site migration?
A site migration is any change that alters the addresses or structure search engines rely on. Common examples are a new domain, a new CMS, a move to HTTPS, a new URL structure or a merged subdomain. Some are small. Any of them can break rankings if old pages stop resolving to the right new pages.
B2B sites carry extra risk. Service pages and resource pages often rank for specific, high-value queries, and enquiry forms often sit on pages that change during a rebuild. A ranking loss on one service page can cut off a whole channel of enquiries. For the crawling and indexing side of the same work, see technical SEO for B2B sites.
Which moves need a Change of Address request?
Google's Change of Address tool is for one case: moving from one domain or subdomain to another. Google says "You only need this tool when moving from one domain or subdomain to another". It is not needed for HTTP to HTTPS, switching between www and non-www, or moving paths within the same domain.
How early should you start, and how long does it take?
Reflect Digital says a small website migration takes "a matter of weeks", and a larger one takes "months", plus extra planning time. Plan the baseline first, because it has to be recorded before anything changes.
The redirect map cannot be finished until the new URLs are fixed, so the build and the map run in parallel. This is a planning point, not a Google rule, and it is the reason the staging checks come last.
Phase 1: Record the baseline before you move
The baseline is your record of how the old site performs. Without it, you cannot tell a migration problem from normal movement in rankings and traffic.
Export Search Console data and rankings
Export your performance data from Google Search Console before the old site changes. Record rankings for your most important pages and search terms at the same time. Keep the export outside the tool, so you can compare against it after launch.
Crawl every URL and record its SEO fields
Crawl the live site and export every URL with its title, meta data, canonical tag, robots directives and any structured data. Reflect Digital's pre-launch checks include meta data and internal linking, so include both. This list is the source for the redirect map, so a missing URL here becomes a broken link after launch.
Phase 2: Map every old URL to a new one
The redirect map pairs each old URL with one new URL. Three of the four top-ranked agencies put redirect mapping at the centre of their migration work, and Bigfork's nine steps include 301 redirects. The map is the core deliverable.
Use permanent redirects for permanent moves
Use a permanent redirect when a page has moved for good. Google's guidance says "Use permanent redirects when you're sure that the redirect won't be reverted". Google also says "Use server side permanent redirects if technically possible", so set the redirect on the server, not in the page.
Send each old page to the closest equivalent. Do not send every page to the homepage. Where a page has no equivalent, a removal status tells search engines the page is gone on purpose.
Keep redirects for at least a year
Google's site-move guidance says "Keep the redirects for as long as possible, generally at least 1 year." Keeping them longer costs little, and removing them early is the simplest way to create broken links from other sites.
Keep redirect chains short
A redirect chain is an old URL that passes through a second redirect before it reaches the final page. Map each old URL straight to its final destination. The 301 documentation Google publishes gives no hop limit, so test your own chains rather than relying on a number from a blog post.
Phase 2 (test): Check staging before launch
Staging is where most migration mistakes are caught. Check these before the switch.
Check robots.txt, meta data and canonicals
Google's site-move guidance includes preparing robots.txt for the new site. A staging file that blocks crawling must not reach the live site. Check meta data and canonical tags on the staging pages, so each one points at the new URL. Reflect Digital's pre-launch checks also include redirect mapping and analytics tags, so test both.
Confirm lead forms reach the CRM
Proctor + Stevenson lists forms and integrations among the things a website migration covers. For a B2B site, enquiries are the outcome that matters, so submit every lead form on staging and confirm each record reaches the CRM with the correct source and owner. Run the same test on launch day. Google's guidance does not cover this, so treat it as a B2B check you add yourself.
Launch day: sitemaps and Search Console
On launch day, run these checks while the team is still available.
- Submit the new sitemap in Search Console. Google's guidance says to "Submit a sitemap in Search Console", and the sitemap should list the canonical URLs.
- Submit a Change of Address only if the domain or subdomain changed. Google's guidance says to submit it "for all verified variants" of the old domain.
- Check your top pages return the right status and the correct redirect. Bigfork's steps include the sitemap as a separate check, so confirm the new sitemap and the old redirects in the same pass.
- Confirm Google Analytics and Tag Manager fire on the live site, so traffic and enquiries are measured from the first day.
After launch: monitoring for at least a year
Post-launch monitoring is the step that most guides name and least describe. Ink Digital and Reflect Digital both list it, and Reflect's post-launch checks sit in their own section. Keep watching for longer than the first few weeks, because the redirects themselves need to stay in place for at least a year.
Check Search Console's indexing reports for pages that are not being indexed. Re-test the top pages for site speed, since slow templates are a common side effect of a rebuild. Ink Digital lists site speed among the metrics a migration should protect. Reflect Digital also lists AI visibility among its post-migration services. None of the guides checked gives a method for measuring it, so treat it as an open question rather than a launch check.
Judge the results against the baseline
No source checked for this article gives a drop threshold that a checklist can rely on. Google's documentation gives none. Compare against your own baseline and against the same period in the previous year, not against a single percentage from a vendor.
Track enquiries as well as traffic. A stable enquiry count with lower traffic can mean the rankings moved to the right pages, and a rise in traffic with no enquiries is not a result.
A go/no-go gate for launch day
Use this gate before you switch the domain. Each row needs an owner and a pass result. The second column shows whether a Google page backs the check or whether it is good practice.
| Check | Pass condition | Basis | Owner | If it fails |
|---|---|---|---|---|
| Baseline exported | Search Console data and rankings saved outside the tool | Good practice | SEO lead | Hold launch |
| Redirect map | Every crawled old URL has one destination | Good practice; Google: permanent redirects | SEO lead | Hold launch |
| Redirect type | Permanent moves use a permanent redirect, set on the server | Google 301 guidance | Developer | Fix before launch |
| Staging noindex and robots | No staging block remains on the live site; robots.txt allows the new site | Google site-move guidance | Developer | Hold launch |
| Canonicals and meta data | Top pages point to new URLs | Good practice; Reflect pre-launch checks | Developer | Fix before launch |
| Lead forms | Each test submission reaches the CRM with the correct source | Good practice (B2B) | Sales operations | Hold launch |
| Sitemap | New sitemap ready to submit | Google sitemap guidance | SEO lead | Submit after fix |
| Tracking | Google Analytics and Tag Manager verified on staging | Reflect pre-launch checks; Proctor migration topics | Analytics owner | Hold launch |
Launch only when every row passes, or when the owner of a failing row has accepted the risk in writing.
What the guides say and what Google documents
The top four pages make claims that are hard to check. The table sets each claim against its source, so you can see what a checklist can rely on.
| Claim | Who makes it | Type of source | Does Google's documentation back it? |
|---|---|---|---|
| "Up to 65% of organic traffic lost" in a bad migration | Ink Digital (blog excerpt) | Vendor | No |
| 13% visibility increase; 49% increase in organic users | Reflect Digital (client case studies) | Vendor case study | No. Specific to those clients |
| 13.61% and 34% increase (Gamma Communications) | Ink Digital | Vendor case study | No. Specific to that client |
| A small migration takes weeks; a larger one takes months | Reflect Digital | Vendor | No. Not a Google timeline |
| Redirects and the sitemap are steps in a migration | Bigfork (nine numbered steps) | Guide | Yes: Google documents both |
| Keep redirects at least one year | Google site-move guidance | Yes | |
| Change of Address is for domain moves only | Google site-move guidance | Yes | |
| Lead forms and integrations are part of a migration | Proctor + Stevenson (FAQ) | Agency | No. Google is silent on forms |
The useful part is the last two rows. The claims a checklist can rely on are the ones Google documents, and the rest are good practice you can justify on your own terms.
Common migration mistakes
- Broken links and 404 errors after the old URLs stop resolving. Bigfork lists broken links and 404s among its migration risks.
- Redirects set up wrongly, including redirects to the homepage. Bigfork's risks list includes redirect setup.
- Lost metadata and duplicate content from page templates that change during the build. Ink Digital lists metadata and page templates among the dangers of skipping SEO.
- Losing data from the old site. Bigfork lists data loss as a risk, so back up files and databases before the switch.
- Removing redirects early. Keep them for at least a year.
Migration is a good moment to check your SEO, but a big migration is a poor time to test a new strategy. If you want a second pair of eyes on your redirect map before launch, book a free B2B SEO audit.
Who should own each task?
A migration fails when nobody owns a task. Reflect Digital's migration kick-off includes "Task allocation" and splits the work between an SEO department and a development department. Give each task one named owner: the SEO lead for the baseline and redirect map, the developer for staging and launch, the analytics owner for tracking, and sales operations for the CRM form tests.
Name the person who signs off the go/no-go gate. It should not be the person who built the site.