Website Redesign Migration Checklist: Protect URLs, Rankings and Data

By Parker Gawryletz · Local Cochrane Web Design · Last updated: · 8 min read

Code editor showing redirect rules during a Cochrane website redesign migration
Code editor showing redirect rules during a Cochrane website redesign migration

A safe website redesign follows a migration checklist: inventory every current URL and its performance, decide each page's fate, build a one-to-one 301 redirect map, protect titles and internal links, block staging from indexing, verify redirects on launch day, submit the new sitemap, and monitor rankings, traffic and errors for at least 30 days.

A redesign is the moment a website's rankings are most at risk. Change URLs without redirects and Google treats your new pages as strangers, while years of links and local search history point at addresses that no longer exist. A website redesign migration checklist exists to prevent exactly that.

This checklist covers the work before launch, on launch day, and through the first 30 days. It is the same discipline behind website redesign services in Cochrane, where a full URL redirect map is part of every project.

The short answer

  • Inventory every URL and its traffic before anything changes.
  • Map every old URL to one new destination with a 301 redirect.
  • Keep staging blocked from search engines until launch day.
  • Verify redirects, sitemap and analytics on launch day itself.
  • Monitor rankings, errors and enquiries for at least 30 days.

Create the current URL and performance inventory

Before anything changes, export a complete list of your current URLs and record how each one performs: which pages bring search traffic, which rank for valuable terms, and which produce enquiries. This inventory is the baseline every later decision — keep, merge, move or retire — is measured against.

Build it from three places: a site crawl, your analytics pages report, and the Search Console performance report. Take a full backup at the same time — files, database, content and images — and store it outside the hosting account. The inventory protects rankings; the backup protects everything else.

Decide which pages stay, merge, move or retire

Give every URL in the inventory one of four fates: stay (same content, same address), merge (combined into a stronger page), move (same content, new address), or retire (removed, with a redirect to the closest relevant page). No URL leaves the spreadsheet without a decision.

The dangerous decision is retiring a page that quietly earns traffic or rankings. Check the inventory before cutting anything: a thin-looking page that ranks well should be merged into a stronger one, not deleted. And pages that keep their exact URL need no redirect — stable addresses shrink the whole migration.

Build a one-to-one redirect map

Create a spreadsheet with two columns: every old URL, and the single new URL it permanently redirects to. Use 301 redirects, point each old address at the most relevant new page — never everything at the homepage — and avoid chains where one redirect passes through another.

Google's site-move documentation describes exactly this: permanent redirects from each old URL to its new equivalent, so ranking signals transfer to the right destination. Bulk-redirecting everything to the homepage does not do that — it tells Google the old pages have no true replacement, and it dumps visitors somewhere that does not answer their question.

Test staging without exposing it to indexing

Build and test the new site on a staging address that search engines cannot index — behind a password or a noindex rule — then confirm that block is removed at launch. Two accidents cause real pain: staging getting indexed as duplicate content, and the noindex tag shipping to the live site.

  • ☐ Before launch: every planned page exists on staging and matches the redirect map
  • ☐ Before launch: staging is blocked from indexing — password or noindex, confirmed
  • ☐ Before launch: forms tested end to end, with test enquiries received
  • ☐ Before launch: titles, descriptions and canonicals in place on every page
  • ☐ Before launch: full backup of the current live site completed and stored safely

Launch-day technical checklist

On launch day, deploy the new site, switch on the redirect map, remove every staging block, and verify the highest-value pages by hand. Launch mid-week and early in the day where possible, so problems surface while people are available to fix them — not on a Friday night.

  • ☐ Launch day: redirects live — test your top old URLs by hand in a browser
  • ☐ Launch day: noindex and password protection removed from the live site
  • ☐ Launch day: HTTPS working everywhere, with old addresses redirecting cleanly
  • ☐ Launch day: analytics and Search Console still receiving data
  • ☐ Launch day: speed spot-checked on a real phone, not just a desktop

Speed belongs here because redesigns often ship heavier pages than the ones they replace. The measurable targets to hold are set out in website performance requirements.

Submit sitemap and inspect critical URLs

Generate the new XML sitemap, submit it in Google Search Console, and run the URL inspection tool on your most important pages to confirm Google can crawl and index them. This tells Google about the change directly, instead of waiting for it to discover the new structure on its own.

Recrawling takes time even when everything is correct, so treat this step as starting the clock — not finishing the job.

Monitor rankings, traffic, errors and enquiries

For at least 30 days, watch four things: rankings for the terms that matter, organic traffic against the pre-launch baseline, crawl errors and 404s in Search Console, and — most importantly — whether enquiries keep arriving. Some movement is normal after a migration; a sustained drop is a signal to investigate.

  • ☐ First 30 days: compare organic traffic weekly against the pre-launch baseline
  • ☐ First 30 days: watch Search Console for 404 errors and close them with redirects
  • ☐ First 30 days: track rankings for your most valuable local search terms
  • ☐ First 30 days: confirm enquiries — calls, forms, emails — match normal volume
  • ☐ First 30 days: check no old URL with real traffic was missed in the map

Enquiries matter most. Rankings can look healthy while a broken form quietly loses a week of leads — send yourself a test enquiry in week one, and again in week four.

Keep redirects and document the final map

Redirects are not temporary scaffolding. Google's site-move guidance is to keep them in place for at least a year, and in practice there is rarely a reason to remove them at all. Document the final redirect map and store it with your website records, so future work never breaks it.

A provider who has migrated sites before will show you a redirect plan without being asked — a useful filter when choosing who handles your redesign. For the local market, see Cochrane web design companies compared.

Frequently asked questions

Will a website redesign hurt SEO?

Not if the migration is planned. Rankings suffer when URLs change without redirects, content that earned traffic is deleted, or a noindex tag ships to the live site. With a full URL inventory, one-to-one 301 redirects and post-launch monitoring, a redesign can protect rankings and often improve them.

Do old URLs need redirects?

Yes. Every old URL that changes or disappears needs a permanent 301 redirect to the most relevant new page. Redirects pass along the ranking signals your old pages earned and stop visitors landing on error pages. Redirecting everything to the homepage is not a substitute for a one-to-one map.

How long should redirects remain?

Keep redirects in place long-term. Google's site-move guidance recommends holding them for at least a year, and in practice there is rarely a reason to remove them at all. Old links in directories, emails and bookmarks keep working for years, and each one still carries visitors and signals.

What should be backed up before redesign?

Back up everything: website files, the database, all page content and images, the redirect map itself, your analytics baseline, and exports of Search Console data. Store a copy outside the hosting account. If launch day goes wrong, a complete backup turns a crisis into a simple rollback.

How do I test a site migration?

Test on a staging copy that search engines cannot index. Confirm every planned page exists, forms deliver enquiries, titles and canonicals are correct, and the redirect map points each old URL at the right new page. On launch day, retest your most valuable URLs by hand in a browser.

What should I monitor after launch?

For at least 30 days, monitor organic traffic against the pre-launch baseline, rankings for your most valuable terms, crawl errors and 404s in Google Search Console, and enquiry volume from calls and forms. Small fluctuations are normal after a migration; a sustained drop needs prompt investigation.

Sources

Request a redesign migration audit — a page-by-page review of your current URLs, rankings and redirect needs before any redesign work begins.

Part of the guide series: Best Web Design Companies in Cochrane (2026): Local Options Compared

Get in Contact · See Our Work — free consult, no obligation, local to Cochrane. Written, itemised proposals within one business day from Local Cochrane Web Design.