A site migration can be good for your business, but only if SEO is treated as part of the project from the start. A new website, cleaner design, better CMS, faster templates or stronger UX can all help growth. But if search engines lose track of your pages during the move, you can quickly lose rankings, traffic and enquiries.
That is why a site migration SEO audit matters. It gives you a clear process before launch, during launch and after go-live, so you are not relying on luck when the new site is pushed live.
The practical answer is simple. Plan properly. Map your URLs. Test your redirects. Check the site again after launch. Then keep watching the data until performance settles.
What counts as a site migration?
A site migration is any major change that affects how users and search engines access your website. A full domain move is only one kind.
You may be migrating if you are:
- Moving from one CMS to another
- Changing your URL structure
- Redesigning your website
- Moving from HTTP to HTTPS
- Combining 2 or more websites
- Moving to a new domain
- Relaunching major templates
- Replatforming an ecommerce site
- Changing navigation or site architecture
- Moving content into new folders or subfolders
Some migrations are small. Others touch thousands of URLs. Either way, Google has to understand what changed, where old content moved, and which new pages should be indexed.
Why migrations go wrong
Most migration issues come from moving too fast and checking too late.
A redesign may look finished from a brand or design point of view, but SEO can still be exposed. Old URLs may not redirect. Important pages may be missing. Internal links may still point to staging URLs. Metadata may be duplicated. Canonicals may point to the wrong version. Tracking may be broken. A robots.txt rule used during development may accidentally block the live site.
These are not rare problems. They are common.
The risk is higher when SEO is added at the end of the project instead of being built into planning, design and development. By then, it is harder and more expensive to fix structural issues.
A good migration process should involve SEO, content, development, UX, analytics and commercial teams. The point is to avoid launching a site that looks better and performs worse.
If your migration is part of a wider rebuild, it is worth connecting SEO with website design and development from the beginning rather than treating it as a final QA task.
Build SEO into a rebuild before design sign-off
Most migration damage is decided before anyone writes a redirect. When a migration is part of a redesign or rebuild, settle these in the design and build phases:
Information architecture and URLs
- Group pages around the commercial themes that drive enquiries, with a hub page for each and supporting pages beneath it
- Keep key pages within a few clicks of the homepage
- Keep existing URLs wherever you can, especially the ones with traffic, rankings or links
- Where a URL must change, decide the new URL and its redirect now, not at launch
- Set naming conventions for services, locations, insights and case studies
Templates
- A clear H1 that matches the page’s intent
- Space for real introductory copy, even on design led pages
- Internal link modules built into components (related services, guides, case studies, next steps), so linking does not depend on editors remembering
- Title, meta description, canonical and structured data fields for every template
- Core Web Vitals targets agreed for each key template before build
Build
- Core content and internal links present in the HTML without user interaction; see our JavaScript SEO guide
- Correct status codes for live, moved and removed pages (200, 301, 404, 410)
- Indexation rules that are deliberate, with no development noindex or robots.txt block carried into production
- An XML sitemap that updates as content changes
- Rules for filters, internal search and parameters so they do not create crawlable duplicates
- Analytics events and conversions defined before build, not reconstructed after launch
Start with a pre-launch SEO audit
The pre-launch audit is where you build your safety net.
Before anything goes live, you need to understand the current site. Which pages get traffic? Which pages rank? Which URLs have backlinks? Which pages drive leads or sales? Which pages are important because they support user journeys, even if they do not get huge traffic?
A crawl on its own will miss pages that matter. Combine it with data from:
- Google Analytics
- Google Search Console
- Current XML sitemaps
- Backlink tools
- Server logs where available
- PPC landing page reports
- CRM or lead tracking data
- Current website crawl data
- Internal business knowledge
This gives you a full picture of what must be protected.
A page with only 200 visits a month may still matter if those visits convert into £20,000 of pipeline. A blog post may not convert directly, but it might attract links that support the wider domain. A service page may not have the highest traffic, but it may rank for a priority commercial keyword.
This is where an organic marketing view helps. Each page has a role in search and conversion, and that role needs protecting as well as the URL.
Create a migration benchmark before launch
You need a benchmark so you can spot problems after launch.
Before migration, record your current performance. This should include:
- Organic sessions
- Organic enquiries or sales
- Top landing pages
- Top ranking keywords
- Indexed pages
- Crawl errors
- Core Web Vitals
- Backlinked pages
- Conversion rate by landing page
- Revenue or lead value where available
For ecommerce, also record product and category performance. For lead generation websites, record form submissions, phone clicks, booked calls, downloads and other key events.
As a simple example, imagine your organic traffic brings 8,000 visits per month, converts at 3%, and each qualified enquiry is worth around £500 in potential revenue. A 25% migration drop could mean around 60 fewer enquiries in a month. That is a commercial problem as much as an SEO one.
Build a proper redirect map
Redirect mapping is one of the most important parts of a migration.
Your redirect map tells browsers and search engines where each old URL has moved. If a page has a new URL, the old URL should usually point to the most relevant new URL using a 301 redirect.
A strong redirect map should include:
- Old URL
- New URL
- Page type
- Status code
- Priority
- Traffic level
- Backlink value
- Notes for developers
- QA status
Do not redirect everything to the homepage. That may feel easy, but it is poor for users and weak for SEO. If someone lands on an old product, service or guide URL, they should be taken to the closest equivalent page.
If there is no equivalent page, choose the most useful alternative. If there is no relevant replacement at all, a 404 or 410 may be cleaner than sending users to an unrelated page.
Redirects should also avoid chains. A redirect chain happens when URL A redirects to URL B, and URL B redirects to URL C. This slows things down and makes crawling less efficient. The old URL should point directly to the final destination.
Stacked redirect layers cause most chains. If the CMS, the application and the CDN each hold redirect rules, consolidate them into one layer and test the combined result.
What Google’s site move guidance adds
- Give each new URL a self referencing canonical
- Submit an XML sitemap of the new URLs in Search Console
- For a domain change, use the Change of Address tool in Search Console for the old domain (it is not needed for a move from HTTP to HTTPS)
- Keep redirects in place for as long as possible; Google suggests at least a year
- Test redirects in bulk, including old blog paths, PDFs, trailing slash and uppercase variants
Protect your highest-value URLs first
Not every URL has the same value. Your first priority should be the pages that contribute most to visibility, authority and revenue.
Focus on:
- Pages with strong organic traffic
- Pages with high-quality backlinks
- Pages ranking for commercial keywords
- Pages used in paid campaigns
- Pages that convert well
- Pages linked from key navigation
- Pages included in important user journeys
- Pages with strong internal link equity
Pull the backlinked URLs from a backlink tool rather than relying on the current crawl. Old URLs that no longer appear in your navigation often hold links from other sites, and they are the easiest ones to miss in a redirect map.
This is especially important for B2B websites, where the buying journey is often longer. A guide or insight page may support a future lead even if it does not create an enquiry immediately.
If you are working in a complex buying cycle, a B2B SEO strategy can help you decide which pages matter most commercially, rather than ranking pages by traffic alone.
Check your staging site before launch
Your staging site should be reviewed properly before launch. This is your chance to catch issues before users and search engines find them.
Check the staging site for:
- Missing pages
- Wrong templates
- Broken internal links
- Missing metadata
- Duplicated titles
- Missing H1 headings
- Incorrect canonicals
- Incorrect noindex tags
- Blocked resources
- Slow page templates
- Missing schema
- Broken forms
- Incorrect tracking
- Staging URLs in links
- Image issues
- Mobile usability problems
Pay close attention to robots.txt and noindex settings. During development, it is normal to block staging from search engines. But those settings must not be carried across to the live website.
You should also compare the old and new crawl. If your old site had 1,200 indexable URLs and the new crawl shows 600, you need to know why. Some removals may be deliberate. Others may be mistakes.
Review content before you migrate it
A migration is a good time to clean up content, but you need to be careful.
Do not delete pages just because they feel old. Check whether they rank, attract links, support internal linking or help users understand your services. If content is thin, outdated or duplicated, decide whether to update it, merge it or redirect it.
A content inventory should include:
- Keep
- Improve
- Merge
- Redirect
- Remove
For each key page, check the title tag, meta description, H1, subheadings, body content, internal links and calls to action. Make sure the new version still targets the right intent.
If you are changing content heavily during the migration, benchmark performance carefully. If rankings move after launch, you need to know whether the cause was the technical migration, the content change or both.
Do not forget internal links
Redirects are important, but they should not be used as a substitute for clean internal links.
After migration, internal links should point directly to the new URLs. This includes:
- Main navigation
- Footer links
- Breadcrumbs
- Blog links
- Service page links
- Related content modules
- Product or category links
- XML sitemap links
- HTML sitemap links
- CTA buttons
Internal links help users and crawlers understand your site structure. If all your internal links still point to old URLs, you are creating unnecessary redirects across your own website.
This can slow crawling, weaken user experience and make the migration messier than it needs to be.
It is also a good time to review anchor text. Use descriptive, natural anchors. Do not force keywords everywhere, but do make sure links explain where they go.
Make analytics and tracking part of QA
Tracking belongs in migration QA alongside tags and redirects.
You need to know whether users are still finding the right pages, completing forms, clicking calls to action and moving through the website as expected.
Before launch, check:
- GA4 configuration
- Google Tag Manager setup
- Conversion events
- Form tracking
- Phone click tracking
- Ecommerce tracking
- Consent mode
- CRM integrations
- Paid media pixels
- Dashboard filters
- Cross-domain tracking where relevant
If a migration breaks tracking, your data may look worse or better than reality. Neither is helpful.
For cleaner measurement, review your Google Tag Manager setup before launch and make sure event tracking works on the new templates. You should also connect this with wider data and analytics reporting, so stakeholders can see what changed after go-live.
Launch day SEO checklist
Launch day should not be chaotic. You should have a clear checklist and named owners for each task.
Here is a practical launch day structure:
| Area | What to check | Why it matters |
|---|---|---|
| Redirects | Test old URLs against the redirect map | Protects rankings, users and link equity |
| Indexation | Check robots.txt, noindex tags and canonicals | Prevents accidental blocking |
| Tracking | Test GA4, GTM and conversions | Keeps reporting reliable |
| Forms | Submit test enquiries | Protects lead generation |
| Navigation | Check menus, footers and breadcrumbs | Supports users and crawlers |
| XML sitemap | Submit the new sitemap in Search Console | Helps search engines discover new URLs |
| Speed | Test key templates | Protects UX and conversion rates |
| Mobile | Check priority pages on mobile devices | Reflects real user behaviour |
| Paid media | Check all paid landing page URLs | Prevents wasted ad spend |
| Search Console | Monitor coverage and crawl issues | Helps spot problems early |
Do not rely on 5 manual checks and hope everything is fine. Test a sample of priority URLs, templates and edge cases.
On large sites, test in bulk. Redirects have to work across the whole site, and checking the homepage and 3 service pages will not tell you that.
Post-go-live QA: the first 24 hours
The first 24 hours are about catching obvious problems quickly.
Check whether the site is live, accessible and indexable. Crawl the live site. Test redirects. Submit the new sitemap. Inspect priority URLs in Google Search Console. Check that GA4 is collecting data. Test forms, calls to action and checkout flows if relevant.
You should also compare the live crawl against the staging crawl. Any unexpected differences need to be reviewed.
In the first day, focus on:
- 404 errors
- 500 server errors
- Redirect failures
- Incorrect canonicals
- Accidental noindex tags
- Broken navigation
- Missing metadata
- Missing tracking
- Form failures
- Slow key pages
This is not the time for panic over small ranking movements. Some fluctuation is normal. The priority is to make sure search engines and users can access the right pages.
Post-go-live QA: the first 2 to 4 weeks
The first few weeks are where deeper migration issues usually appear.
You should monitor:
- Organic clicks
- Organic impressions
- Ranking changes
- Indexed URLs
- Crawl errors
- Redirect hits
- Landing page performance
- Conversion changes
- Core Web Vitals
- Backlinked URLs
- Sitemap coverage
- Server logs if available
Compare performance against your pre-launch benchmark. If traffic drops, check whether the decline is sitewide or limited to certain sections. A sitewide drop may suggest technical issues. A section-specific drop may point to redirect, content, template or internal linking problems.
Do not look only at traffic. Look at enquiries, sales, revenue and lead quality too. A small traffic drop may be acceptable if low-value pages were removed and conversions are stable. A small traffic increase may still be a problem if key commercial pages have lost visibility.
For a wider view of how poor planning can affect visibility, Totally.Digital’s article on SEO migration failures is a useful reminder of why this work matters.
Common migration mistakes to avoid
Most migration mistakes are avoidable if the right checks happen at the right time.
The common ones include:
- Launching without a complete redirect map
- Redirecting too many pages to the homepage
- Forgetting PDFs, images or old campaign URLs
- Blocking the live site with robots.txt
- Leaving noindex tags on key pages
- Changing URLs without a clear reason
- Removing pages that had backlinks
- Forgetting to update internal links
- Launching with staging URLs
- Breaking GA4 or conversion tracking
- Losing metadata during template changes
- Ignoring mobile layout problems
- Not checking Search Console after launch
The biggest mistake is assuming that a migration is finished when the site goes live. In reality, go-live is the start of the monitoring phase.
How to prioritise fixes after launch
After launch, you may find a long list of issues. Do not treat every issue as equal.
Prioritise fixes based on impact and urgency.
High priority issues include:
- Important pages returning 404 errors
- Commercial pages blocked from indexing
- Redirects failing on high-traffic URLs
- Broken forms or checkout steps
- Tracking failures on key conversions
- Canonicals pointing to the wrong domain
- Large sections missing from the sitemap
Medium priority issues include:
- Missing meta descriptions
- Minor internal link issues
- Non-critical image alt text gaps
- Template-level heading issues
- Slower but usable page templates
Low priority issues include small cosmetic problems that do not affect crawling, indexing, conversions or trust.
This is where a calm process helps. You do not need to fix everything in 1 day. You need to fix the things that can damage traffic, revenue and user experience first.
Aim for a boring launch
The best migrations are usually the boring ones. The launch happens, redirects work, tracking records clean data, users find what they need and search engines understand where everything moved.
That does not happen by accident.
It helps to have someone on the project who can connect each technical check to the pages that bring in revenue.
If you are planning a redesign, CMS move or domain change, talk to Totally.Digital before the URL structure is signed off.