A website migration is any substantial change that can alter how visitors or search engines reach, understand or render your pages. It might involve a new domain, a redesigned site with different URLs, a CMS change, an HTTP-to-HTTPS move or a switch of hosting provider.

The design work is often the visible part. The risk sits underneath it: missing pages, broken redirects, lost metadata, blocked crawling, changed internal links and analytics that stop recording at the moment you most need reliable data.

This checklist helps a small business plan the move as a controlled release rather than a hopeful launch.

First, identify the type of migration

Write down exactly what is changing. A hosting move with unchanged URLs needs different controls from a domain change. A redesign may appear cosmetic but still become an SEO migration if page addresses, headings, copy or navigation change.

Record whether the project changes:

  • the domain or protocol;
  • URL paths or file extensions;
  • CMS, hosting, rendering method or CDN;
  • page copy, titles, structured data or internal linking;
  • navigation and site architecture;
  • multilingual or regional targeting;
  • tracking, forms and conversion journeys.

The more categories you tick, the more important a staged test and a named migration owner become.

Before development: capture the current site

You need a baseline against which to judge the new site. Export the current URL inventory from your sitemap, CMS, analytics, Search Console and a crawler. No single source will reveal every useful page.

For each URL, capture its status code, canonical URL, title, meta description, main heading, indexability, internal links, organic visits, conversions and external links if available. Mark business-critical pages such as high-value services, location pages and resources that attract enquiries.

Also record current performance:

  • organic landing-page traffic;
  • leads or sales by landing page;
  • indexed-page trends;
  • top queries and countries;
  • Core Web Vitals and page templates;
  • crawl errors and existing redirects.

Do not use the migration to erase every old issue at once. Separate defects you must correct from established signals you should preserve.

Build a one-to-one URL map

If URLs change, map every valuable old address to the closest equivalent new address. A spreadsheet with old URL, new URL, reason, redirect status and test result is sufficient.

Avoid sending many unrelated pages to the homepage. That is poor for visitors and may not preserve the relevance of the old pages. If there is no genuine replacement, a clear 404 or 410 response can be more honest than an irrelevant redirect.

Use permanent server-side redirects—normally 301 or 308—for permanent moves. Point each old URL directly to its final destination and avoid chains such as old page → interim page → new page. Keep redirects in place for at least a year; maintaining useful legacy redirects longer is often sensible.

Protect content and search signals

On the staging site, compare important pages with their existing versions. Confirm that valuable copy, headings, title tags, descriptions, image alt text and structured data have not disappeared during component rebuilding.

Check that:

  • canonical tags use the intended production URLs;
  • internal links point directly to new URLs;
  • pagination and language annotations remain valid;
  • XML sitemaps contain indexable canonical URLs only;
  • robots directives do not block required assets or pages;
  • staging noindex rules will be removed at launch;
  • genuine removed pages return the correct status.

Preserve strong page intent. A prettier service page that removes proof, detail and customer questions may perform worse even if its technical implementation is flawless.

Test the whole customer journey

SEO protection is incomplete if rankings survive but enquiries break. Test on real mobile devices as well as desktop browsers.

Complete every key action: submit a form, click a telephone link, book an appointment, make a purchase, download a document and join a mailing list. Verify confirmation messages and emails. Check analytics events, consent settings, advertising tags and CRM hand-offs.

Crawl the staging site where access controls permit. Look for broken links, redirect loops, orphan pages, duplicate titles, missing headings and unexpected canonicals. Compare template speed and accessibility with the baseline.

Launch-day sequence

Choose a lower-risk trading period, but ensure developers and decision-makers are available. Take a final backup and freeze content changes long enough to keep the URL map accurate.

At launch:

  1. Deploy the production site and redirects.
  2. Remove temporary crawl blocks and noindex instructions.
  3. Test representative old URLs, including high-traffic and deeply nested pages.
  4. Verify HTTPS, canonical tags, status codes and robots.txt.
  5. Submit the new XML sitemap in Search Console.
  6. If the domain changed, use Search Console's relevant site-move tools where applicable.
  7. Confirm analytics, forms and transactions in real time.
  8. Update paid campaigns, social profiles, directory listings and important external links.

Do not shut down old infrastructure before you know requests and redirects are reaching the new environment reliably.

Monitor after launch

Expect old-site traffic to decline while new URLs are discovered and processed. Temporary fluctuation is not automatically a failure. What matters is whether the intended signals are transferring and errors are being fixed quickly.

Review daily at first, then weekly:

  • server errors and soft 404s;
  • excluded or unexpectedly indexed URLs;
  • redirect failures and chains;
  • organic landing-page traffic and conversions;
  • rankings for commercially important themes;
  • server capacity and crawl activity;
  • mobile usability and template performance.

Annotate the migration date in reporting. Compare like-for-like page groups, not merely total traffic, and investigate material losses at URL level.

FAQ

Will a migration always reduce rankings?

No. Some fluctuation can occur while search engines recrawl and reassess URLs, but a well-planned migration can preserve performance. The largest avoidable losses usually come from incomplete redirects, blocked crawling, missing content or untested tracking.

Should every old URL redirect?

Every old URL with a relevant replacement should. Redirecting obsolete pages to unrelated destinations creates a poor experience. Decide deliberately whether each page should be replaced, consolidated or retired.

Can we redesign and change domains at the same time?

It is possible, but combining changes makes diagnosis harder. If commercial constraints allow, reducing simultaneous variables makes risk easier to manage.

If your migration needs a clear URL map, technical review and post-launch measurement plan, talk to Yieldberg Studios.

Sources

Continue reading