Website Migration SEO Guide: How to Protect Your Rankings

A website migration can create a faster, more useful and commercially effective digital platform, but it can also put years of search visibility at risk when SEO is treated as a final check rather than a core part of the project.

Every indexed page, internal link, backlink, piece of content and technical instruction helps search engines understand your website. When the site, URLs or domain changes, those signals need to be carried across carefully, so Google and other search engines can recognise what has moved, what has stayed the same and which new pages should replace the old ones.

That’s why a successful website migration is not simply a case of transferring content and switching domains. It is a coordinated process involving SEO, development, content, analytics, user experience and project management, with decisions made before, during and after launch.

In this guide, we explain how to plan and complete an SEO-friendly website migration, which risks to look out for and what your team should be checking at every stage.

What is a Website Migration?

A website migration is any substantial change to a site that could affect how users and search engines access, interpret or evaluate it.

Some migrations involve an obvious move, such as changing a domain name or transferring a website to a new content management system. Others happen during a redesign, when URLs, navigation, page templates or content are altered even though the domain stays the same.

Common website migrations include:

• Moving to a new domain
• Changing CMS or eCommerce platform
• Moving from HTTP to HTTPS
• Redesigning and rebuilding a website
• Changing URL structures
• Moving between subdomains and subfolders
• Merging several websites into one
• Consolidating overlapping pages or content
• Moving from a country-specific domain to a different top-level domain
• Introducing a headless or JavaScript-led website
• Changing hosting infrastructure

The scale of the SEO work should reflect the type of migration, but even a relatively small structural change can affect crawlability, indexation and rankings if high-value pages are moved or removed without a clear plan.

Why Website Migrations can Affect SEO

Search engines don’t see a website as one single asset, instead, they discover and assess individual URLs, then use the relationships between those pages to understand the site as a whole.

Those relationships are shaped by signals including (not limited to):

• URL structure
• Internal links
• Page content
• Title tags and headings
• Canonical tags
• Structured data
• XML sitemaps
• Backlinks
• Crawl depth
• Indexation instructions
• Page performance
• Mobile usability

During a website migration, many of these signals can change at once. Google then needs to crawl the new website, follow the redirects, process the updated pages and decide whether the new URLs should replace the old ones in its index.

Google’s own guidance recommends mapping old URLs to their new equivalents, using permanent server-side redirects and keeping redirects in place for as long as possible, generally at least one year. It also advises against redirecting large numbers of old pages to an irrelevant destination such as the homepage, because those redirects may be treated as soft 404s.

Some movement in rankings and traffic can be expected while search engines process a migration, particularly when the domain or URL structure changes. However, a significant or sustained loss is not something businesses should simply accept as inevitable. It often indicates that valuable signals have been lost, altered or made harder to access.

What SEO Value are You Trying to Protect?

SEO value is often seen by business owners or marketing leaders as though it is a single score or asset that can be transferred from an old site to a new one. In reality, it is the combined result of many signals built over time.

That value may include:

• Pages ranking for commercially important searches
• Backlinks from trusted and relevant websites
• Content that demonstrates experience and subject knowledge
• Strong internal links into priority pages
• Historical engagement and conversion data
• Established brand searches
• Local landing pages with regional visibility
• Product and category pages attracting buying intent
• Structured data supporting richer search results
• Content referenced by search engines, publishers or AI platforms

Protecting SEO value therefore requires more than a redirect spreadsheet. Redirects are essential, but they cannot compensate for a new page that is less useful, less relevant or stripped of the information that helped the old page perform.

For example, redirecting a detailed service page to a thin replacement may transfer users and some signals to the new URL, but the new page still needs to satisfy the original search intent. The same applies when several useful pages are consolidated into one. The destination page must contain enough relevant information to justify replacing them.

When Should SEO Become Part of the Migration?

SEO should be involved during discovery and planning, before the sitemap, navigation, templates and content requirements are finalised.

Waiting until development is almost complete limits what can be changed without creating delays or additional cost. By that stage, important pages may already have been removed, templates may lack space for useful content and URL structures may have been chosen without considering existing search performance.

Early SEO involvement helps the wider team make informed decisions about:

• Which pages must be retained
• Which content can be consolidated
• How the new information architecture should work
• Which URLs can change and which should remain stable
• What each page needs to rank and convert
• How internal links should support priority journeys
• Which technical requirements belong in the development scope
• How success will be measured after launch

This is where joined-up project delivery makes a real difference. When SEO specialists, developers, designers, content teams and decision-makers work from the same plan, fewer compromises are discovered at the last minute.

The SEO Website Migration Process

A reliable migration process can be divided into five stages:

1. Strategy and planning
2. Benchmarking and preparation
3. Build and pre-launch testing
4. Launch
5. Post-migration monitoring and improvement

Each stage supports the next, which means rushed preparation usually creates more work after launch.

Stage 1: Plan the migration around business goals

A successful website migration starts well before any URLs are redirected or content is moved into a new CMS. The strongest projects begin with a clear understanding of what the business is trying to achieve, which parts of the existing website already carry value and where the greatest risks sit.

This stage is less about ticking off technical tasks and more about creating the conditions for better decisions later. When the commercial goals, responsibilities and acceptable levels of risk are clear from the outset, the SEO strategy can support the wider project rather than becoming a last-minute layer added once the build is nearly complete.

1. Define why the migration is happening

Start by documenting what the business expects the new website to achieve and why the current platform, structure or design is no longer supporting those goals.

The reason may be to improve conversion rates, support a rebrand, introduce new products, simplify content management, enter new markets or replace a platform that has become difficult to maintain. In other cases, the website may have grown without a clear structure over time, leaving users with confusing journeys and internal teams with a system that is slow, inflexible or difficult to update. For more information on signs you’ve probably outgrown your website, read our detailed article here.

These objectives matter because they shape the migration strategy from the beginning. A domain change creates a different level of search risk from a straightforward CMS replatform, while an eCommerce migration involving thousands of products, filters and category pages needs a far more detailed approach to URL mapping, canonicalisation and crawl control than a smaller brochure website.

Your migration brief should clearly set out:

• What is changing and why the change is commercially necessary
• Which systems, platforms and integrations are involved
• Which business functions depend on the website continuing to perform
• Which audiences, locations and markets need to be supported
• How success will be measured after launch
• Which risks the business is not prepared to accept

For example, a professional services firm may be willing to tolerate some short-term ranking movement if the new website significantly improves lead quality and gives its team better control over content. An eCommerce business launching ahead of a peak sales period may have far less room for disruption, particularly if organic product and category pages account for a large share of revenue.

That is why SEO planning should not begin with a generic checklist. It should begin with the commercial context, because the right migration strategy depends on what the website needs to protect and what the business needs to achieve next.

2. Avoid unnecessary simultaneous changes

Website projects often become an opportunity to change everything at once, including the domain, CMS, design, navigation, content, URL structure, tracking and hosting. Sometimes that level of change is necessary, especially when an ageing platform is holding back development, performance and marketing activity across the board. However, every additional change introduces another variable, which makes any post-launch movement harder to diagnose.

If organic visibility falls after a migration involving a new domain, new platform, new page structure and heavily rewritten content, there may be several possible causes. Redirects may not be working as intended, important internal links may have disappeared, page relevance may have weakened or search engines may simply still be processing the move.

Where practical, retain the elements that do not need to change. That may mean:

• Keeping established URLs during a redesign
• Improving strong content rather than replacing it entirely
• Preserving high-performing page titles and headings
• Retaining useful internal links and navigation paths
• Avoiding a domain change unless there is a clear business reason

Google recommends separating major changes where possible, particularly when a domain move is being combined with a redesign or CMS change. This gives search engines a clearer set of signals to process and gives internal teams a more manageable picture when monitoring performance after launch.

A new URL structure may be justified because the current one is inconsistent or difficult to scale, while a full content rewrite may be necessary because the existing copy no longer reflects the business. At the same time, changing stable and high-performing elements without a clear reason creates risk without necessarily creating more value.

3. Choose the right time to launch

Launch timing can have a direct commercial impact, particularly when the website plays a major role in generating enquiries, bookings or online sales. Where possible, avoid launching during the busiest trading period of the year, immediately before a major campaign or at a time when key team members are unavailable. A migration may be thoroughly planned and tested, but issues can still emerge once the live website is being crawled, used and processed at scale.

Review several years of analytics, sales and campaign data where available, paying particular attention to:

• Seasonal peaks and quieter trading periods
• Major campaigns, launches or events
• Internal resource and annual leave
• Supplier and developer availability
• Reporting deadlines and board updates
• Operational periods where disruption would be especially costly

A quieter launch window reduces commercial exposure and gives developers, SEO specialists and decision-makers more space to investigate issues properly. It also means the team can monitor the first few days with the right people available, rather than discovering a problem late on a Friday afternoon with limited support in place.

There may still be valid reasons to launch within a busy period, especially where the current platform is unstable, insecure or actively limiting growth. In those cases, the additional risk should be managed through stronger testing, more detailed monitoring and clear escalation procedures.

4. Assign clear ownership

A website migration usually involves several teams, and clear ownership helps prevent important tasks from sitting between departments or suppliers.

Marketing may be focused on customer journeys and launch communications, while developers are managing the platform, templates and infrastructure. SEO specialists are likely to be reviewing redirects, crawlability and indexation, while content teams are rewriting pages and analytics teams are checking tracking.

Depending on the scale of the project, stakeholders may include:

• Marketing
• SEO
• Web development
• Design and UX
• Content
• Paid media
• IT and hosting
• Data and analytics
• Sales or eCommerce
• Legal and compliance
• External agencies or platform providers

One person should hold overall responsibility for launch readiness, with clear authority to bring decisions together and confirm whether the site is ready to go live. Specialist areas should then be approved by the people with the right experience and knowledge.

A redirect map, for example, should be reviewed against organic traffic, backlinks, content relevance, final staging URLs and the commercial role of each page. The same principle applies to tracking, structured data, content migration and technical testing.

Approval should mean that the work has been checked against agreed standards, with any known risks documented before launch. A clear responsibility matrix can help on larger projects, although the process does not need to become overcomplicated. Every critical task needs an owner, every approval needs a named decision-maker and every dependency needs to be understood by the wider team.

5. Create a rollback and recovery plan

Even well-managed migrations can encounter unexpected issues, which is why the team should understand how to respond before the website goes live. A rollback plan sets out what would justify restoring the previous site, who has the authority to make that decision and how the process would work in practice.

Before launch, confirm:

• Whether the previous website can be restored
• How long backups will be retained
• Who can reverse DNS, hosting or deployment changes
• How database updates and new transactions will be handled
• Which issues would stop or delay the launch
• Which issues could be corrected safely after launch
• Who has final authority to approve a rollback

The team should also agree what different levels of severity look like. A small number of missing meta descriptions would rarely justify rolling back an entire migration. A live site carrying a noindex directive across every page would be far more serious. The same applies to widespread redirect failures, broken checkout functionality or a tracking setup that makes revenue impossible to measure.

A recovery plan should also explain how issues will be investigated, communicated and prioritised after launch. That may include checking server logs, recrawling affected sections, reviewing Search Console data and comparing live templates with staging.

Stage 2: Benchmark and prepare the existing website

Once the commercial goals and responsibilities are clear, the next stage is to build an accurate picture of the website as it stands today. This gives the migration team a reliable baseline for measuring what changes after launch, while also revealing which pages, links and content assets need the most protection during the move.

The quality of this preparation has a direct impact on the quality of the migration. Incomplete data can lead to valuable pages being removed, important redirects being missed and performance issues going unnoticed until they begin affecting traffic, leads or revenue.

6. Record current performance

Pre-launch data provides the baseline for assessing whether the migration has achieved what the business expected. Without that benchmark, changes in rankings, traffic or conversions can be difficult to interpret. A decline may be caused by the migration, but it could also relate to seasonality, tracking changes, reduced demand or wider movement in the search results.

Your benchmark should include:

• Organic users and sessions
• Organic clicks and impressions
• Keyword rankings
• Leads, transactions and revenue
• Conversion rates
• Landing-page performance
• Branded and non-branded visibility
• Indexed URLs
• Backlinks and referring domains
• Core Web Vitals
• Crawl errors
• Mobile performance

Site-wide totals are useful, but they should be supported by more detailed reporting where possible. A website may appear stable overall while losing traffic across the service or product pages that generate the majority of commercial value. Segment the data by page type, directory, device, country and search intent where this helps explain performance more clearly. For larger sites, it can also be useful to separate product categories, service areas, locations and content sections.

Record several months of data as a minimum, then compare year on year where seasonality affects demand. This is particularly important for businesses operating around events, travel periods, retail peaks or weather-led services, where normal performance can vary significantly throughout the year.

7. Build a complete URL inventory

A migration plan is only as reliable as the URL data behind it. The current XML sitemap provides a useful starting point, although it may exclude orphaned pages, historic campaign URLs, redirected content and pages that continue to receive traffic or backlinks.

Build a master inventory using several sources:

• A full website crawl
• XML sitemaps
• Google Search Console
• Google Analytics
• Backlink tools
• Paid advertising accounts
• Internal databases
• Server log files
• Historic crawls
• Existing redirect rules

Combining these sources creates a fuller view of what currently exists and how each URL contributes to the site.

For example, analytics may reveal a landing page that no longer appears in the navigation, while backlink data may highlight an older resource that still attracts strong external links. Historic redirect rules can also reveal previous URL versions that need to continue working after the migration.

This master inventory becomes the foundation for redirect mapping, content decisions and post-launch monitoring, so it should be treated as a working project document rather than a one-off export.

8. Classify every URL

Each existing URL should have a defined outcome before launch.

Typical actions include:

• Keep the same URL
• Redirect to a close equivalent
• Consolidate into a stronger page
• Retain temporarily
• Remove with a 404 or 410 response
• Review manually
• Exclude because it is not relevant or indexable

This process helps the team understand which pages should be protected, which can be improved and which no longer support the website’s goals.

Removal decisions should be evidence-led. A page with limited recent traffic may still hold backlinks, support internal navigation, rank during seasonal peaks or contribute specialist information that strengthens a wider topic. At the same time, carrying duplicate, outdated or low-value content into the new site can make the structure harder to manage and weaken the overall user journey.

Each decision should therefore consider the page’s current performance, purpose and relationship with the rest of the website.

9. Identify your most valuable pages

Some URLs carry more commercial and SEO value than others, which means they need closer attention throughout the migration.

Flag pages that:

• Generate organic leads or revenue
• Rank for valuable non-branded searches
• Receive strong external links
• Attract substantial impressions
• Support paid advertising
• Earn local visibility
• Act as important internal-linking hubs
• Demonstrate expertise or first-hand experience
• Receive citations or referral traffic
• Support key customer journeys

These priority pages should be reviewed manually on staging and monitored individually after launch. Compare the old and new versions carefully, looking at the page purpose, content, metadata, internal links and conversion path. Where changes are being made, the team should understand how they may affect visibility or user behaviour.

A page that ranks well and converts consistently deserves more than a quick visual check. It should be treated as a business asset and protected accordingly.

10. Audit the backlink profile

Backlinks remain attached to specific URLs, so any linked pages that move need accurate redirects.

Identify the old URLs with the strongest and most relevant links, then make sure each one points to the closest new equivalent. This helps maintain the journey for users arriving through external websites and gives search engines a clearer connection between the original page and its replacement. The quality and relevance of the link matter as much as the quantity. A single link from a trusted industry publication, supplier or professional body may carry more value than a larger number of weaker references.

After launch, consider contacting the owners of the most important backlinks and asking them to update the destination, particularly where the domain has changed. Updating every external link is unlikely, but correcting the most commercially and editorially valuable ones reduces long-term reliance on redirects.

11. Plan the new site architecture

The new structure should reflect how users search, compare and move towards action, while making priority content straightforward for search engines to discover.

Review:

• Main navigation
• Service or product hierarchies
• Category and subcategory relationships
• Breadcrumbs
• Footer navigation
• Contextual internal links
• Blog and resource taxonomies
• Location pages
• Faceted navigation
• Pagination
• Multilingual structure

Important pages should remain easy to reach within the new architecture. Moving a commercially valuable service or category page several levels deeper can reduce the internal links pointing to it, which may affect how often it is crawled and how clearly its importance is understood.

The new structure should also support future growth. If new services, products or locations are likely to be added, the architecture needs enough flexibility to accommodate them without creating another major restructure later. This is one of the areas where SEO, UX and content planning need to work together closely. The structure should make sense to customers, support commercial journeys and provide search engines with clear relationships between related pages.

12. Create the redirect map

The redirect map connects every changing legacy URL with the most relevant destination on the new site.

Use permanent 301 redirects for pages that have moved permanently, and point each old URL directly to its final destination wherever possible.

Avoid chains such as:

Old URL > temporary URL > current URL

Redirect chains add unnecessary crawl steps, slow the journey and create more maintenance work over time.

Good redirect mapping is based on the meaning and intent of the old page.

For example:

/commercial-solar-panels/

should redirect to:

/solar-panels-for-businesses/

Sending that URL to a general services page or the homepage would create a weaker experience because the destination does not closely match what the user expected to find.

Where no relevant replacement exists, a genuine 404 or 410 response may be more appropriate than an unrelated redirect. This gives both users and search engines a clearer signal that the page has been removed.

The redirect map should also be reviewed against traffic, backlinks and page purpose before launch, then tested in the staging or development environment wherever possible.

13. Preserve important on-page signals

Each priority page on staging should be compared with its current live version so the team can see exactly what is changing.

Review:

• Page purpose and search intent
• Main copy
• Title tag and meta description
• H1 and subheadings
• Images and alt text
• Internal links
• FAQs
• Reviews and testimonials
• Author information
• Structured data
• Product or service details
• Local information
• Downloadable resources
• Calls to action

There may be good reasons to improve the content, restructure the page or change the way information is presented. The new version still needs to satisfy the same user need and retain the signals that helped the original page perform.

For example, shortening a service page may improve the visual layout, but removing useful detail, proof or internal links can reduce its relevance and make it less convincing to potential customers. This is also where E-E-A-T considerations become important. First-hand examples, author details, reviews, case studies and specialist information all help demonstrate experience and trust, so they should be carried across thoughtfully rather than treated as secondary content.

The migration should leave each priority page stronger, clearer and better aligned with the business, while preserving the value it has already built.

Stage 3: Build and test the new website

Once the migration plan, URL inventory and redirect strategy are in place, attention turns to the new website itself, where technical SEO needs to sit alongside development rather than being added as a final check shortly before launch.

A staging site can appear complete from a design perspective while still containing issues that affect crawling, indexation, page relationships or tracking, which is why the new platform needs to be tested in the same way a search engine will experience it, as well as from the perspective of users and internal teams.

The earlier these problems are identified, the easier they are to resolve properly, without creating unnecessary pressure during the final stages of the project.

14. Keep staging environments out of search

The staging website needs to remain accessible to the people and tools carrying out testing, while also being protected from public indexation throughout the build.

Depending on the setup, that protection may come from authentication, IP restrictions, noindex directives, robots controls or a non-public hosting environment, although each safeguard still needs to be checked carefully rather than assumed to be working.

Staging websites can appear in search when access controls have been configured incorrectly, particularly when temporary links are shared externally or crawlers discover the environment through scripts, feeds or internal references.

The launch process should therefore include a specific check for removing any temporary restrictions, because a site-wide noindex directive, blocked robots rule or authentication layer carried into production can prevent the live website from being crawled and indexed correctly. These controls should have clear ownership, with sign-off built into the final deployment process before the site is opened to search engines.

15. Crawl the staging website

Crawl the new website with software like Screaming Frog before launch using the same approach and settings applied to the current site, as this gives the team a consistent comparison and makes it easier to identify pages, templates or instructions that have changed unexpectedly.

The staging crawl should review:

• Status codes and indexability
• Canonical tags and robots directives
• Internal links and redirects
• Page titles, meta descriptions and H1 headings
• Image references and alt attributes
• XML sitemaps
• Pagination and hreflang
• Structured data
• Orphaned pages
• Crawl depth
• Duplicate content

Compare the results against the old-site inventory and investigate any missing or unexpected URLs, because a priority page may be absent from the crawl if it is no longer linked internally, while a new filter or template could be generating hundreds of duplicate pages without anyone noticing through visual testing alone.

The crawl should also be repeated after any major development change that affects templates, navigation or routing logic, so the team is not relying on outdated checks as the site moves closer to launch.

16. Test redirect rules before launch

Where the technical setup allows it, redirect logic should be tested in a safe environment before the migration goes live. This matters because a redirect rule can look correct in a spreadsheet but behave differently once it interacts with server configuration, CMS routing, caching and older redirect rules already in place.

Testing should cover both individual redirects and wider patterns, including differences in capitalisation, trailing slashes, parameters and protocol variations, while historic redirects also need to be considered where the site has moved before and several generations of URLs may still receive visits or backlinks.

Pay particular attention to:

• One-to-one redirects
• Pattern-based rules
• HTTP and HTTPS versions
• WWW and non-WWW versions
• Redirect chains and loops
• Product variants
• Filter and faceted URLs
• Existing legacy redirects

The aim is to make sure users and crawlers move directly from the old URL to the intended live destination, without unnecessary intermediate steps or conflicting rules creating a weaker journey.

17. Review canonical tags

Canonical tags help search engines understand which version of a page should be treated as the primary one, so they need careful attention during migrations involving duplicate content, product variants, filters or changed URL structures.

On the new website, canonical tags should use the final live domain and align with the agreed indexation strategy, with indexable pages generally referencing themselves and duplicate or consolidated versions pointing to the preferred URL.

Staging references, HTTP URLs and outdated domain paths should all be removed, while product and filter templates should be checked for consistency across the site.

Canonical tags also need to support the wider technical setup, because a page that redirects to one destination while declaring another as canonical sends mixed signals, just as a noindexed page should not usually be presented as the preferred version of a live indexable page. As canonicals are often generated through templates, testing should cover a representative sample of every page type rather than relying on a few manually selected URLs.

18. Check internal links

Internal links on the new website should point directly to final live URLs, without relying on redirects to complete the journey, as this keeps the structure cleaner and makes it easier for both users and search engines to move through the site.

Review links across:

• Main navigation
• Body content
• Buttons and calls to action
• Breadcrumbs
• Footer menus
• Related content
• Product recommendations
• Images
• Structured data
• XML and HTML sitemaps

Internal linking also helps search engines understand which pages matter most and how different sections of the website connect, so priority service, product, category and location pages need enough relevant links to remain easy to discover.

A redesigned navigation can weaken those relationships when links are removed or supporting modules disappear, which is why internal-link coverage should be reviewed against the agreed site architecture rather than judged on appearance alone.

19. Retain and validate structured data

Structured data helps search engines interpret important page elements, including products, organisations, articles, reviews, local businesses and events, which means it needs to be carried across carefully during the migration.

Valid existing markup should be transferred with all URLs, entity details and template references updated to match the new site, while unsupported, duplicated or misleading properties should be removed. The remaining markup should reflect information that users can genuinely see on the page, with testing carried out on the rendered version of the code and across each relevant template.

This is especially important for eCommerce platforms, recruitment sites, publishers, event businesses and multi-location organisations, where schema is often generated dynamically and a single template-level issue can affect hundreds or thousands of pages.

20. Test JavaScript rendering

Modern websites often rely on JavaScript to load content, navigation, products, filters and other important elements, which can affect how consistently the site is crawled, understood and surfaced across search engines and AI-led platforms.

Googlebot and Bingbot can render JavaScript, although that rendering requires additional processing and may not happen as quickly or reliably as crawling content delivered in the initial HTML. Many AI crawlers and LLM retrieval systems have more limited rendering capabilities, which means they may not execute client-side JavaScript before assessing the page.

For that reason, commercially important content should be available in the initial HTML wherever possible, using server-side rendering, static generation or another approach that does not depend entirely on a browser running JavaScript.

Check that crawlers can access:

• Main body copy
• Product or service information
• Navigation and crawlable links
• Pagination
• Canonical tags
• Structured data
• Internal links
• Status messages
• Faceted navigation controls

A page may look complete to a user while presenting far less information to a crawler, particularly when content depends on delayed scripts, user interaction or third-party services. Rendered testing should therefore be carried out alongside checks of the raw HTML, so the team can confirm that the information needed for search visibility and AI discovery is available without relying on client-side rendering alone.

21. Test mobile usability and page performance

A new website should create a smoother experience, although redesigns and platform changes can also introduce larger images, heavier templates and additional scripts that affect performance.

Testing should cover a representative range of pages across mobile and desktop devices, different browsers, connection speeds and logged-in or logged-out states, while product, service, category and content templates all need to be reviewed alongside the journeys that lead to an enquiry, booking or purchase.

Core Web Vitals provide useful performance signals, but they should be considered alongside the practical experience of using the site, because forms, menus, search functions, filters, checkout steps and calls to action all need to work reliably.

A technically fast page can still underperform when the journey is confusing, while a visually strong template can create friction if it loads slowly or behaves inconsistently on mobile, so testing should consider both measurable performance and the ease with which users can complete important actions.

22. Confirm analytics and conversion tracking

Tracking needs to be validated before launch so the team can measure performance accurately from the first day, as a broken event, missing tag or altered conversion path can make a migration appear to have lost traffic, enquiries or revenue when the underlying issue is measurement.

Review the full setup, including:

• Google Analytics
• Google Tag Manager
• Google Search Console
• Consent management
• Form submissions
• Phone tracking
• eCommerce events
• Transaction values
• Cross-domain tracking
• Advertising pixels
• CRM integrations
• Thank-you pages
• Custom events

Forms, transactions and other key actions should be tested from start to finish, while cross-domain tracking needs particularly close attention where users move between booking engines, payment platforms, subdomains or third-party systems.

The new implementation should also be compared with the existing setup, with any intentional changes to event names, attribution rules or reporting definitions recorded clearly, so the first post-launch reports can be understood with confidence.

Stage 4: Launch the website

Launch day brings every part of the migration together, which means the final checks need to be controlled, clearly owned and based on the work already completed during planning and testing.

The aim is to move from staging to production without introducing new problems, while making sure the team can quickly identify and respond to anything that behaves differently once the site is live.

23. Complete final pre-launch checks

Before approving the launch, the team should complete a final review across SEO, development, tracking and infrastructure, with each area signed off by the person responsible.

Confirm that:

• The redirect map is final and ready to implement
• Priority pages have been reviewed against the existing site
• Analytics and conversion tracking have been tested
• Current backups are available
• DNS, hosting and deployment access has been confirmed
• Staging restrictions will not carry into production
• Live robots.txt rules are prepared
• XML sitemaps contain the final URLs
• Canonical tags reference the live domain
• Paid campaign URLs and product feeds are ready
• Key stakeholders are available during and after launch
• Monitoring dashboards are prepared
• The rollback and recovery process is understood

This final review should bring together the technical checks carried out throughout the project, rather than introducing new decisions at the last minute. A launch checklist should be formally approved, with any known risks recorded and accepted before the website is made live.

24. Crawl the live site immediately

Once the migration is live, carry out a full crawl and compare the results with both the staging crawl and the original URL inventory.

Production environments can behave differently from staging because of hosting settings, caching, deployment rules or configuration changes, so the live site needs to be checked as soon as possible.

Look for:

• Unexpected 404 errors
• Redirect failures
• Redirect chains or loops
• Pages carrying noindex directives
• Blocked resources
• Incorrect canonical tags
• Missing or incomplete content
• Broken internal links
• Duplicate titles
• Missing structured data
• Staging URLs or references
• Incorrect status codes

Priority pages and commercial journeys should also be tested manually, including forms, checkout steps, account areas, booking systems and internal search.

These checks help confirm that the site is working for both users and search engines, while giving the team an early opportunity to correct issues before they begin affecting performance.

25. Submit the new XML sitemap

Once the live crawl has confirmed that the new URLs are accessible and indexable, submit the final XML sitemap through Google Search Console and any other relevant webmaster platforms.

The sitemap should include:

• Final canonical URLs
• Indexable pages only
• URLs returning a successful 200 status
• Accurate last-modified dates where supported

Keeping the old sitemap available temporarily can also help search engines discover the legacy URLs and process their redirects during the transition, particularly on larger sites.

Where the domain has changed, use Google Search Console’s Change of Address tool when the migration meets the required criteria, then continue monitoring both the old and new properties as search engines process the move.

Submitting the sitemap supports discovery, although it should sit alongside accurate redirects, internal links and crawlable page structures rather than being relied upon as the only signal.

26. Update connected marketing channels

Website migrations affect every channel that links users to the site, so URLs should be updated across the wider marketing and operational setup as soon as the new platform is live.

Review:

• Google Ads and Microsoft Advertising
• Social media profiles
• Email templates and automated campaigns
• Google Business Profile
• Merchant Center and product feeds
• Affiliate platforms
• Recruitment portals
• PR profiles
• Business directories
• CRM journeys
• Downloadable documents
• QR codes
• Partner websites
• App listings

Updating these links reduces unnecessary redirects, improves reporting accuracy and creates a more consistent journey across every touchpoint. It also helps prevent paid campaigns, product feeds or automated communications from sending users to outdated destinations, which is particularly important where those channels contribute directly to enquiries or revenue.

Stage 5: Monitor and improve performance

Once the new website is live, the migration enters a period where close monitoring matters just as much as the preparation that came before it.

Search engines need time to crawl the redirects, process the new URLs and update their indexes, while users begin interacting with the new structure, templates and journeys at scale. Some movement is expected, particularly after a domain or URL change, but performance should still be reviewed carefully so the team can identify where normal transition ends and a specific issue begins.

The strongest post-launch monitoring combines technical data, page-level analysis and commercial performance, which gives the business a much clearer view of whether the migration is working as intended.

27. Monitor crawling and indexation

Google Search Console should be reviewed frequently after launch, with attention given to how the new pages are being discovered, crawled and indexed.

Watch for:

• Increases in 404 errors
• Pages excluded from indexing
• Redirect errors
• Canonical conflicts
• Crawled but not indexed pages
• Blocked URLs
• Sitemap processing issues
• Mobile usability problems
• Structured data errors

The total number of indexed pages should be treated as one signal rather than the final measure of success. A smaller index can be positive where duplicate, low-value or outdated URLs have been removed as part of the migration, provided the pages that matter most remain accessible and indexable.

What matters is whether the right service, product, category, location and content pages are appearing in the index, while legacy URLs are being replaced cleanly by their new equivalents. Search Console data should be reviewed alongside crawl reports and server logs where available, as this can reveal whether search engines are repeatedly requesting outdated URLs, struggling to access certain sections or spending time on low-value areas of the site.

28. Compare performance at page level

Site-wide reporting can provide a useful overview, but it often hides the detail needed to understand what has changed.

Compare performance across:

• Old and new landing pages
• Directories
• Page templates
• Device types
• Countries
• Branded and non-branded searches
• Products and categories
• Lead-generating pages
• Informational content

This helps separate broad migration movement from more specific problems.

For example, if visibility declines across one template while the rest of the website remains stable, the cause may relate to missing content, incorrect canonicals, weaker internal links or a rendering issue. If one directory loses traffic, the redirect mapping or new site architecture may need closer review.

The same approach should be applied to keyword and query data, because an overall ranking average can hide losses across commercially important searches. Comparing old and new URLs directly also helps confirm whether search engines are transferring visibility to the intended destinations, particularly where several legacy pages have been consolidated into one stronger resource.

29. Watch commercial performance

Rankings, clicks and traffic remain important, but the website ultimately needs to support the wider goals agreed at the beginning of the project.

Monitor:

• Enquiry volume
• Lead quality
• Transactions
• Revenue
• Conversion rate
• Average order value
• Form completion
• Phone calls
• Quote requests
• Bookings
• User engagement across priority journeys

A migration can protect organic traffic while still creating friction in forms, checkout steps or navigation, which is why commercial performance needs to be reviewed alongside search data.

For example, a new service page may continue to rank well but generate fewer enquiries because the call to action is less prominent, while an eCommerce category may retain traffic but convert at a lower rate because filters or product information have become harder to use.

These changes should be assessed at page and journey level, with input from sales, customer service and eCommerce teams where relevant. Their feedback can reveal issues in lead quality, user intent or buying behaviour that analytics alone may not show.

30. Keep redirects in place

Redirects should remain active well beyond the first few weeks after launch. Google advises retaining them for at least one year, while keeping them for longer is often sensible when backlinks, bookmarks, printed materials and historic campaigns continue to use the old URLs.

Removing redirects too early can break valuable external links and create a poor experience for returning users, while also weakening the connection between the old and new pages. Redirect rules should be documented and included in future hosting, development and platform plans so they are not accidentally removed during later technical work. This is especially important where the website has already been through several migrations and multiple generations of URLs still receive visits.

Periodic redirect checks can also help identify chains that have developed over time, allowing the team to update older rules so they point directly to the current destination.

31. Investigate declines methodically

When performance falls, changes should be investigated in a controlled order so the team can identify the most likely cause before making further adjustments.

Work through the evidence in a logical sequence:

1. Confirm analytics and conversion tracking are working
2. Check that the affected pages are technically accessible
3. Review redirect behaviour
4. Compare indexation across old and new URLs
5. Inspect canonical tags and robots directives
6. Compare the old and new page content
7. Review internal links and crawl depth
8. Check for template or rendering changes
9. Analyse keyword, query and landing-page losses
10. Review competitor activity and changes in the search results

This order helps separate measurement issues from technical problems, and technical problems from changes in relevance or competition. If a page has been accidentally noindexed, rewriting the copy will not resolve the issue. In the same way, if the new page no longer satisfies the original search intent, resubmitting the sitemap is unlikely to restore performance.

Every fix should be documented, with implementation dates added to analytics and reporting tools where possible, so the team can assess what changed and whether the action had the intended effect.

A measured approach also reduces the risk of making several overlapping changes that become difficult to evaluate later, which gives the business a clearer path towards recovery and continued improvement.

Common Website Migration Mistakes

Even well-funded website projects can lose search visibility when the migration is treated mainly as a design or development exercise. Most problems we’ve learnt over our 20 years often come from decisions made too late, incomplete data or technical instructions that do not align across the new site.

Bringing SEO into the project too late

SEO should be involved before the sitemap, templates and URL structure are finalised. When those decisions have already been made, the migration team has less room to protect high-performing pages, retain useful content or prevent unnecessary URL changes.

Early involvement also gives SEO specialists time to work alongside developers, designers and content teams, which helps reduce rushed compromises shortly before launch.

Changing too many elements at once

A new domain, CMS, design, navigation structure and full content rewrite may all be commercially justified, although combining every change into one launch increases the level of risk.

It also makes performance movement harder to diagnose, because traffic or ranking losses could relate to redirects, content, internal links, rendering, hosting or the wider structure. Where practical, retain stable elements that already perform well and make each major change for a clear reason.

Building the redirect map from incomplete data

A crawl or XML sitemap alone may miss orphaned pages, historic URLs, paid campaign landing pages and content that still receives traffic or backlinks. When those URLs are absent from the migration inventory, they are more likely to return errors or be redirected to an unsuitable destination after launch.

A complete redirect map should draw from crawl data, analytics, Search Console, backlink tools, historic redirects and other relevant systems.

Redirecting old pages to the homepage

Sending large groups of old URLs to the homepage creates a poor experience because the destination rarely matches the original page.

A user looking for a specific service, product or guide should reach the closest relevant replacement, while search engines also need a clear relationship between the old content and the new destination.

Where no suitable replacement exists, a genuine 404 or 410 response can provide a clearer signal than an unrelated redirect.

Creating redirect chains

Redirects should take users and crawlers directly from the old URL to the final live destination.

Chains often develop when historic rules are carried into a new migration without review, creating routes such as:

Old URL > previous URL > new URL

These additional steps slow the journey, use more crawling resources and make the redirect setup harder to maintain over time.

Removing content that supported the old page

A new design may use shorter copy, fewer modules and more visual space, but important information can disappear during that process.

Removing FAQs, service detail, product specifications, case studies, reviews or internal links may reduce the page’s relevance and make it less convincing to potential customers. Content can be improved during a migration, although priority pages should still satisfy the original search intent and retain the detail that helped them perform.

Carrying staging instructions onto the live site

A live website can be blocked from search even when it appears to work normally for users.

Common causes include:

• Site-wide noindex directives
• Restrictive robots.txt rules
• Password protection
• Canonical tags pointing to staging
• Internal links using staging URLs
• XML sitemaps containing development URLs

These checks should be part of the final deployment sign-off and repeated as soon as the production website is live.

Relying on redirects for internal links

Redirects are designed to support old URLs, backlinks and historic references, while the new website’s internal links should point directly to the final destinations.

Leaving old URLs in menus, body content, breadcrumbs or product links creates unnecessary redirect paths throughout the new site and carries avoidable technical debt into the platform from launch.

Forgetting about analytics and conversions

A migration can appear to have lost enquiries or revenue when tracking has stopped recording key actions properly. Forms, transactions, calls, booking journeys and CRM integrations should be tested before launch and checked again on the live site, with any intentional changes to reporting documented clearly.

Without accurate measurement, the team cannot assess whether the migration has protected performance or identify where users are dropping out.

Focusing only on traffic and rankings

Organic visibility remains important, but a migration should also improve how the website supports the business.

A new site may retain traffic while generating fewer enquiries because forms are harder to complete, calls to action are less visible or product filters create more friction. Commercial measures such as lead quality, conversion rate, revenue and bookings should be reviewed alongside rankings and traffic.

Stopping the project at launch

Search engines still need to process redirects, crawl new pages and update their indexes after the site goes live, while real users may uncover issues that were not obvious on staging.

Post-launch monitoring should be planned in advance, with responsibility for crawling, Search Console reviews, performance analysis and technical fixes clearly assigned.

Simple Website Migration SEO Checklist

This checklist provides a clear overview of the main areas that should be covered before, during and after a migration. Larger or more complex websites may require additional checks around international targeting, eCommerce filters, JavaScript rendering or multiple domains.

Before the build

• Define the commercial goals and migration scope
• Bring SEO, development, content and analytics teams into planning
• Record current traffic, rankings, conversions and revenue
• Crawl the existing website
• Build a complete URL inventory from several data sources
• Identify high-value pages and backlinks
• Review the proposed sitemap, navigation and URL structure
• Decide what should happen to every existing URL
• Agree ownership, approval and rollback procedures

During development

• Keep the staging site out of search
• Create and review the redirect map
• Preserve important content, metadata and internal links
• Check canonical tags, robots directives and indexability
• Retain and validate structured data
• Make important content available in the initial HTML
• Test mobile usability and Core Web Vitals
• Validate forms, transactions and conversion tracking
• Crawl the staging website and investigate errors

Before launch

• Test redirects in the development or staging environment
• Confirm XML sitemaps contain final canonical URLs
• Remove staging references and temporary restrictions
• Confirm backups and rollback access
• Prepare DNS, hosting and deployment access
• Test priority pages and commercial journeys
• Confirm key stakeholders are available
• Complete and sign off the final launch checklist

Immediately after launch

• Crawl the live website
• Test priority redirects manually
• Check for noindex tags, blocked pages and staging references
• Confirm canonical tags use the live domain
• Test forms, checkout, bookings and account areas
• Submit the new XML sitemap
• Use the Change of Address tool where relevant
• Update paid media, product feeds and external marketing links
• Confirm analytics and conversion tracking are recording correctly

After launch

• Monitor crawling and indexation in Search Console
• Review 404s, redirect errors and canonical conflicts
• Compare old and new landing-page performance
• Monitor rankings, traffic, leads and revenue
• Review performance by directory, template and device
• Investigate declines in a controlled order
• Document every fix and implementation date
• Keep redirects in place for at least one year
• Continue improving pages and journeys after performance stabilises