Website Migration SEO Checklist: Protect Rankings Before and After Launch

A website migration can improve speed, design, content structure and the way a business manages its site. It can also wipe out years of organic visibility if the move is treated as a development project first and an SEO project afterwards.

The danger is rarely one dramatic mistake. It is usually a collection of smaller ones: old URLs disappear without redirects, valuable content is shortened during the redesign, canonicals still point to staging, analytics stops recording, external links land on 404s, or a site-wide noindex setting survives launch.

A safe migration therefore starts long before DNS changes. The job is to identify everything the existing website has already earned — rankings, links, enquiries, revenue, useful content and technical signals — and deliberately transfer that value to the new version.

What counts as a website migration?

A migration is any change substantial enough to alter how users, search engines or business systems reach and understand the website.

Not every redesign needs to become a full migration. If the domain, URLs, CMS and core content remain stable, the SEO risk is much lower. That is why the choice between a redesign and a completely new website should be made before the project scope starts expanding.

Does a website migration always hurt SEO?

No. Some short-term movement can happen while search engines recrawl changed pages, process redirects and understand a new architecture. That is very different from a permanent traffic loss caused by preventable implementation mistakes.

A migration is successful when the new site preserves the useful signals of the old one while improving the things that actually needed changing.

The aim is not “zero movement at any cost”. It is to prevent avoidable loss, detect problems quickly and give search engines a clear path from the old site to the new one.

Phase 1: define the migration goal before building anything

One of the strongest gaps in many migration plans is that they begin with tasks rather than a reason.

Set out what the migration is supposed to achieve.

1. Set measurable goals

Examples might include:

• improve mobile performance;
• move off an unsupported CMS;
• simplify a confusing site structure;
• merge overlapping content;
• support a rebrand without losing organic demand;
• reduce editing and maintenance time;
• improve conversion rate;
• consolidate several properties into one domain.

Then define how success will be measured. That could include organic traffic retention, conversion rate, Core Web Vitals, lead volume, indexed-page count, crawl health or revenue.

2. Separate business goals from SEO protection

SEO preservation is a requirement, not the reason for the migration.

If the business is moving because the current platform is limiting growth, the project should improve that problem while preserving the search value already earned.

That prevents teams from treating “keep rankings” as the only success measure and forgetting why the site is being changed in the first place.

Phase 2: score the migration risk

Not all migrations carry the same level of danger.

3. Create a written risk register

For a larger migration, record:

• what could go wrong;
• how likely it is;
• the commercial impact;
• how it will be detected;
• who owns the response;
• what the rollback trigger is.

This sounds formal for a small website, but even a simple one-page document can prevent the “I thought someone else was checking that” problem.

Phase 3: align the people involved

SEO migrations fail when different teams make decisions in isolation.

4. Name the people responsible for each area

A migration may involve:

• business owner or leadership;
• project manager;
• web developer;
• SEO specialist;
• content team;
• paid-media team;
• analytics or CRM owner;
• hosting or IT provider.

Not every small business has separate people for these roles, but the responsibilities still exist.

5. Create one migration document

Keep the key information in one place:

• scope;
• launch date;
• URL map;
• owners;
• risks;
• testing status;
• rollback plan;
• post-launch monitoring.

That document becomes valuable later when staff change or another migration happens years afterwards.

Phase 4: choose a sensible migration date

6. Launch when traffic and business risk are lower

Use analytics to find a quieter period.

A business-critical site should not be migrated on the morning of a major promotion, seasonal peak or sales event simply because the development work happens to be finished.

7. Make sure the people needed to fix problems are available

The perfect low-traffic window is useless if the developer, hosting provider or decision-maker is unavailable afterwards.

A controlled weekday launch is often easier to support than an unattended weekend launch.

8. Freeze unrelated changes around launch

A short change freeze helps isolate problems.

If the site goes live while unrelated content, tracking and design changes are also being pushed, diagnosis becomes much harder.

9. Lower DNS TTL in advance when appropriate

For migrations involving DNS changes, lowering the time-to-live beforehand can help the new DNS settings propagate more quickly.

This is not necessary for every redesign, but it is worth planning when infrastructure is changing.

Phase 5: benchmark the old site before it disappears

The existing site is the evidence base for the migration.

10. Export every important URL

Do not rely on one source.

Use:

• a full crawl;
• Search Console;
• analytics;
• XML sitemaps;
• backlink data;
• CMS exports where useful.

A page missing from the current navigation can still receive search traffic or external links.

11. Save Search Console performance

Export important queries and landing pages before launch. Twelve months of data is useful where seasonality matters.

12. Save analytics and conversion data

Record organic sessions, form submissions, transactions, call events and other meaningful outcomes by landing page.

A page with modest traffic may still be commercially important.

13. Record rankings for high-value queries

You do not need to track every keyword in the index. Track the queries that matter to the business and the landing pages currently associated with them.

14. Record Core Web Vitals and performance

If improved performance is one reason for the migration, measure the old site before replacing it.

Otherwise there is no reliable way to prove the new build improved anything.

15. Crawl the old site and save the crawl

Record:

• status codes;
• titles;
• meta descriptions;
• H1s;
• canonicals;
• robots directives;
• internal links;
• hreflang where used;
• structured data;
• images and files;
• redirects.

16. Document the current architecture

Do not only save a URL list.

Record:

• main navigation;
• footer structure;
• category relationships;
• template types;
• dynamic filters;
• search functionality;
• third-party integrations;
• subdomains.

Phase 6: audit the destination before committing to it

This is especially important in domain migrations.

17. Check the history of a new domain

If the business is moving onto a previously used domain, investigate what lived there before.

Look for signs of:

• spam;
• irrelevant historical content;
• suspicious backlinks;
• previous penalties or indexation problems;
• a subject history completely unrelated to the new business.

A domain name can look clean while carrying a messy past.

18. Audit the backlink profile of the destination domain

Do not inherit someone else’s low-quality history blindly.

Phase 7: decide what happens to every important page

19. Classify each old URL

Every important URL should be marked:

• Keep — same URL survives;
• Move — direct permanent redirect to a new equivalent;
• Merge — several overlapping pages combine into one stronger page;
• Retire — no useful equivalent exists.

20. Preserve valuable URLs where possible

Do not change a strong URL because a new designer prefers a different folder structure.

If the current URL ranks, earns links and still describes the content accurately, keeping it removes migration risk completely for that page.

21. Build a one-to-one redirect map

Old URL → closest true new equivalent.

Avoid redirecting everything to the homepage or one generic category simply because it is faster to configure.

22. Prioritise pages by value

A good migration sheet should flag:

• organic traffic;
• conversions;
• backlinks;
• revenue;
• ranking importance;
• business priority.

That gives the team an order for testing rather than treating every URL as equally important.

Phase 8: decide what content survives

23. Do not let the redesign thin ranking pages

One of the easiest ways to lose relevance is to keep the URL but remove the content that made the page useful.

Whitespace is not an SEO strategy.

If a service page currently explains pricing, process, FAQs, locations and proof, replacing it with a hero banner and three icons may improve the mock-up and weaken the page.

24. Consolidate duplicate content deliberately

A migration is a good opportunity to merge genuinely overlapping pages, but only when one replacement can satisfy the intents the old pages covered.

25. Keep useful content history

Back up old pages even when they are being removed. Content that appears unimportant during launch can later turn out to have supported a ranking, backlink or customer journey.

Phase 9: build a protected staging environment

26. Use staging rather than building on the live site

The replacement should be tested privately while the existing website continues serving customers.

27. Block staging properly

Password protection is stronger than relying on noindex alone because it stops both users and crawlers from reaching the duplicate site.

If noindex is also used, make removal of that setting an explicit launch task.

28. Mirror important infrastructure

Where relevant, test:

• CDN;
• caching;
• forms;
• CRM;
• payments;
• chat;
• analytics;
• personalisation;
• email delivery.

The closer staging behaves to production, the more useful the testing becomes.

Phase 10: test the new site’s SEO before launch

29. Crawl staging

Look for:

• 4xx and 5xx responses;
• redirect chains;
• staging URLs inside internal links;
• missing titles;
• duplicate titles;
• missing or incorrect canonicals;
• wrong noindex directives;
• broken images;
• orphaned pages.

The technical SEO audit checklist provides a deeper second-pass review for crawlability, indexation and template issues.

30. Compare old and new metadata

Important pages should not lose useful titles, headings or descriptions accidentally during the CMS move.

31. Validate canonical URLs

Canonicals should point to the intended final live URLs, not staging or old-domain versions.

32. Check structured data

Make sure relevant schema still matches the visible content and has not been dropped or duplicated by the new templates.

33. Check hreflang

International sites need every language and regional annotation updated to the final URL structure.

34. Check robots.txt

Do not allow a staging rule to block the live site.

35. Build the new XML sitemap

It should contain canonical live-intent URLs, not redirects, test pages, staging addresses or pages deliberately excluded from search.

Phase 11: test the business systems as aggressively as the SEO

A migration that preserves rankings but breaks the sales process is still a failed migration.

36. Test every important form

Confirm the enquiry reaches the intended inbox or CRM, not merely that the browser displays a success message.

37. Test ecommerce and booking journeys

Complete real test actions where possible.

38. Test analytics and Tag Manager

Confirm the correct production IDs and events are present.

39. Test CRM, automation and live chat

These integrations are frequently forgotten because they are owned by different teams.

40. Test consent behaviour

Check that analytics and advertising tags behave in line with the site’s consent setup.

Phase 12: back up everything and define rollback

41. Take a final backup of the old site

Keep files and database somewhere controlled by the business or a trusted provider.

42. Keep a reference copy of the legacy site

For larger migrations, a read-only copy or recoverable archive can be extremely useful when a missing asset or old page needs to be checked after launch.

43. Define rollback conditions

Examples include:

• widespread server errors;
• checkout failure;
• missing redirect rules;
• critical forms failing;
• serious DNS or SSL errors;
• site-wide noindex or crawl blocks;
• major integration failure.

“We will decide if something goes wrong” is not a rollback plan.

Phase 13: consider migrating in phases

Large sites do not always need to move in one event.

A phased migration can reduce risk when:

• several websites are being consolidated;
• there are tens of thousands of URLs;
• multiple business units are involved;
• the new platform has never been tested at full scale;
• different sections have different technical owners.

The advantage is diagnostic clarity. If one section moves first, problems can be identified before the rest follows.

Phase 14: prepare the launch itself

44. Freeze content and code changes

Stop non-essential changes while the final crawl and redirect validation are happening.

45. Take the final pre-launch crawl

Compare staging against the old site and your migration sheet.

46. Test the redirect file before launch

Where technically possible, validate the map in the new environment before traffic arrives.

47. Confirm DNS, SSL and hosting capacity

Search-engine recrawling can temporarily increase requests because crawlers hit old URLs and follow the redirects to new ones.

Make sure the new infrastructure can handle the load.

Phase 15: launch-day SEO controls

48. Activate permanent redirects

Test high-value old URLs first.

49. Remove staging crawl blocks

Check the live site, not the deployment checklist.

50. Recheck canonicals on production

Production and staging can behave differently.

51. Upload the correct XML sitemap

Verify it contains only intended live canonical URLs.

52. Confirm analytics is receiving live data

Use real-time reporting and test conversion events.

53. Check Search Console and Bing Webmaster Tools

For a domain move, use the appropriate site-move or change-of-address processes and verify both old and new properties where relevant.

54. Re-test forms, checkout and bookings

Do not assume staging success means production success.

Phase 16: update the wider web after a domain change

This is often under-covered in migration checklists.

55. Update important backlinks where practical

Permanent redirects should remain, but high-value backlinks are cleaner when they point directly to the new URL.

Prioritise links you control or relationships where an update is realistic.

56. Update social profiles

Change website links on LinkedIn, Facebook and other business profiles where necessary.

57. Update Google Business Profile and other local listings

If the domain or important business details changed, local profiles should not keep sending users to the retired address.

58. Update paid advertising destinations

Do not rely on redirects for active ads when the final URLs can be updated directly.

59. Update email templates and signatures

Old website links can survive in places the migration team never sees.

Phase 17: monitor the first 24 hours

• check the homepage and priority landing pages;
• test high-value redirects;
• watch 4xx and 5xx errors;
• verify analytics and conversions;
• test forms and sales journeys;
• crawl the live site;
• check robots.txt and sitemap;
• check server performance.

Phase 18: monitor the first seven days

• compare organic landing-page traffic;
• watch important rankings;
• review Search Console indexing;
• check which old URLs Google is still crawling;
• investigate unexpected 404s;
• check redirects for important backlink targets;
• compare conversion volume with the old baseline.

Phase 19: monitor the first month

Do not judge the whole website from one aggregate traffic chart.

Compare groups separately:

• service pages;
• location pages;
• blog articles;
• product/category pages;
• international sections;
• brand vs non-brand queries.

A drop in one directory points to a different problem than a site-wide drop.

60. Re-run a complete SEO audit

Live environments expose issues that staging can hide.

61. Track 404 landing-page traffic

Configure analytics or reporting so real users landing on 404 pages can be identified. That often reveals forgotten redirects faster than a periodic manual check.

62. Recheck backlinks

Find valuable external links still landing on errors or weak destinations.

63. Compare ranking and conversion recovery

Traffic is not the only measure. A migration can keep visits stable while breaking enquiry quality, and it can reduce low-value traffic while improving conversions.

How should you diagnose a post-migration traffic drop?

Do not start by rewriting the site again.

Take a sample of affected URLs and ask:

1. Does the old URL redirect correctly?
2. Does the final page return 200?
3. Is it indexable?
4. Does it canonicalise to itself?
5. Does the new page still satisfy the old search intent?
6. Did important content disappear?
7. Do internal links point to it?
8. Is it in the sitemap?
9. Are external links landing in the right place?
10. Are impressions beginning to transfer?

If pages are indexed but still fail to compete after the migration settles, why a page can be indexed but not ranking helps separate migration faults from intent, content and competition problems.

What is normal movement and what is migration damage?

Some temporary movement is normal.

These are not “wait and see” signals:

• important URL groups returning 404;
• redirect loops;
• live pages carrying noindex;
• canonicals pointing to staging;
• entire directories losing impressions;
• forms or checkout no longer converting;
• XML sitemaps full of redirects;
• server failures under crawl load;
• Google repeatedly preferring retired URLs.

How long should redirects stay in place?

Permanent moves should be treated as permanent.

Important redirects are useful long after launch because old bookmarks, links and search-engine references can continue sending users to the former addresses.

When can the old hosting be cancelled?

Not immediately.

Keep the old environment or a reliable backup available until the new site is stable, redirects have been verified and there is no operational need to roll back.

Larger migrations deserve a longer safety window.

Document the migration after it is complete

A good final record should contain:

• migration type and date;
• old and new architecture;
• URL mapping;
• redirect test results;
• DNS changes;
• analytics changes;
• Search Console actions;
• known issues;
• performance baselines;
• post-launch results.

That documentation makes the next audit, handover or migration far easier.

Migration SEO and website redesign should be planned together

Migration SEO is not something to add after the new design has been approved.

Design decisions affect content. Development decisions affect rendering, URLs and redirects. Hosting affects availability. Analytics affects measurement.

Our web design work in London treats these as part of replacing an existing site, while the broader website launch checklist covers forms, mobile QA, accessibility, analytics and production checks beyond the migration itself.

How much does migration work add to a redesign?

There is no useful flat figure.

A ten-page site keeping every URL may need relatively little additional migration work. A 5,000-page ecommerce move with a new CMS, product structure, domain and filter system can require weeks of crawling, mapping, testing and monitoring.

The website redesign cost guide covers those wider project costs without turning this checklist into a competing pricing page.

Frequently asked questions

Can a website migration improve SEO?

Yes. A migration can improve architecture, speed, content organisation and technical quality. The benefit comes from the improvements themselves, not from the fact that the website moved.

Should URLs change during a redesign?

Only where there is a real benefit. Keeping strong existing URLs is usually safer than changing them for cosmetic reasons.

Should every deleted page be redirected?

No. Redirect when there is a genuinely relevant replacement. Unrelated content should not be forced to the homepage merely to avoid a 404.

How long does an SEO migration take?

Small migrations can be planned and executed relatively quickly. Large sites, domain moves and multi-team migrations may need several months of preparation, testing and post-launch monitoring.

Should a large migration happen all at once?

Not necessarily. Phased migration can reduce risk and make troubleshooting easier where the site is very large or several properties are involved.

What is the biggest mistake businesses make?

Treating SEO migration as a launch-day redirect task rather than a project that begins with benchmarking, architecture and risk planning.

When should old hosting be cancelled?

Only after the new environment is stable, the redirect set has been verified and there is no realistic need to roll back.