SEO & answer engines · 12 min read

Moving or Redesigning a Website Without Losing Google Rankings: A Migration Checklist

How to redesign, re-platform or change domain without losing rankings: redirect maps, 301s and 308s, Change of Address, and what to monitor after.

On this page
  1. What counts as a website migration?
  2. Why do sites lose rankings after a migration?
  3. How do you build a URL inventory and redirect map?
  4. Should you use 301 or 308 redirects?
  5. How do you keep content and internal links intact?
  6. What should canonicals, sitemaps and robots.txt say?
  7. How does Search Console's Change of Address tool work?
  8. What about Bing?
  9. How do you protect security and customer data during a move?
  10. What should you monitor after launch?
  11. How long does ranking fluctuation last?
  12. A website migration checklist
  13. Frequently asked questions
  14. About the author

To move or redesign a website without losing rankings, list every URL that matters, map each one to its closest new equivalent, and send it there with a permanent server-side redirect (301 or 308). Keep the content, titles and internal links that earned the rankings. Update canonicals and sitemaps, and tell Google and Bing about any domain change. Google says some ranking fluctuation during a move is normal, and that small to medium-sized sites usually take a few weeks for most pages to move.

This guide is for business owners in the UK, the US and Canada who are planning a redesign, a new platform or a new domain, and want to know what their developer should be doing.

What counts as a website migration?

Any change that alters the URLs, the domain or the infrastructure search engines crawl. Google's site move guide covers both moves with URL changes and moves without them (Google Search Central, updated 20 Aug 2026).

  • Redesign. New layout and templates. Low risk if the URLs and content stay the same; higher risk if pages are merged, renamed or dropped.
  • Platform change. Moving to a new CMS or a custom build. URLs often change because each platform has its own patterns.
  • Domain change. For example, a rebrand from oldname.co.uk to newname.co.uk, or a country domain to a generic one. Every URL changes.
  • HTTP to HTTPS. Google treats this as a site move, but you do not need the Change of Address tool for it.
  • URL structure change. For example, /services.php?id=4 becoming /services/kitchen-fitting/.
  • Hosting move with no URL change. Google handles this separately: lower your DNS TTL beforehand, expect a temporary dip in crawl rate, and keep the old hosting running until its traffic reaches zero (Google Search Central, accessed Oct 2026). For client sites we build and host on AWS (Amazon Web Services).

Google's most useful single piece of advice is "Change only one thing at a time." Its own example separates a URL change from a new layout: "do them one at a time." If you must redesign and change domain, launching them weeks apart makes any problem far easier to trace.

Why do sites lose rankings after a migration?

Usually because something that earned the rankings was removed or broken, not because Google penalises moves. Google states that "301 and other permanent redirects don't cause a loss in PageRank" (Google Search Central).

The common causes we see in audits:

  • Old URLs with no redirect, so links and bookmarks hit 404 pages.
  • Everything redirected to the home page. Google says not to "redirect many old URLs to one irrelevant single URL destination, such as the home page", and may treat it as a soft 404.
  • Content cut during the redesign: service descriptions shortened, location pages dropped, blog posts left behind.
  • A noindex or robots.txt block left over from staging.
  • Internal links still pointing to old URLs, creating chains of redirects.

How do you build a URL inventory and redirect map?

Start by collecting every URL that has traffic, links or rankings, then decide where each one goes. Google suggests four sources: your sitemaps, "your server logs or analytics software for the URLs that get the most traffic", the Links report in Search Console, and your CMS's own list of pages.

Build the map as a spreadsheet:

  1. Export URLs from all four sources, plus a crawl of the live site, and remove duplicates.
  2. Add data to each row: organic clicks, conversions and linking sites.
  3. Assign a destination. Map one-to-one wherever a new page covers the same topic. Pages merged into one new page can all point to it.
  4. Retire pages deliberately. If content is not moving, Google says to "make sure those URLs correctly return an HTTP 404 or 410 error response code on the new site", rather than redirecting it somewhere irrelevant.
  5. Keep the spreadsheet. You will test against it on launch day and use it for an old-URL sitemap.

Should you use 301 or 308 redirects?

Either. Both are permanent server-side redirects, and Google lists them together as meaning "moved permanently" (Google Search Central, updated 14 Apr 2026). Google uses a permanent redirect "as a signal that the redirect target should be canonical."

  • Prefer server-side. Google recommends "a permanent server-side redirect whenever possible". JavaScript redirects are a last resort.
  • Use permanent only when it is final. Google advises permanent redirects "when you're sure that the redirect won't be reverted."
  • Avoid chains. Redirect each old URL straight to its final destination. When you migrate a site that has been redesigned before, update the earlier redirects too.
  • Keep them for years, not weeks. Google says to keep redirects "for as long as possible, generally at least 1 year". Bing's migration guidance says "at least 1 to 2 years, preferably longer" (Bing Webmaster Blog, Dec 2020). Keep renewing the old domain as well, or the redirects disappear with it.

Treat the content that ranks as the asset you are moving, and the design as the wrapper.

  • Carry over the substance of each ranking page: copy, title, headings, images and alt text. Rewrite deliberately, not as a side effect of a new template.
  • Update internal links to the new URLs directly. Google says to "change the internal links on the new site from the old URLs to the new URLs" rather than relying on redirects.
  • Update hreflang annotations on multilingual or multi-country sites to use the new URLs.
  • Update links you control: social profiles, your Google Business Profile, directory listings, email signatures and ad campaigns.
  • Ask your most valuable linking sites to update their links. Google suggests contacting the sites on your list of referring domains.

What should canonicals, sitemaps and robots.txt say?

They should all point to the new URLs, and nothing from the staging site should survive launch.

  • Canonicals. Google says "each new URL should have a self-referencing" canonical tag. A template that copies the old domain into canonical tags is a common, quiet failure.
  • Sitemaps. Submit a sitemap of the new URLs in Search Console. Google also suggests submitting a sitemap of the old URLs, so it finds the redirects sooner. Warnings on that file are "normal and you can ignore these warnings", and you can remove it later.
  • robots.txt. Check that the new file blocks only what you intend, and do not block the old URLs, or crawlers cannot see the redirects.
  • Staging. Keep the development site behind a password, not just noindex. For private content, Google says "you need to password protect it", and that this also keeps it out of Search (Google Search Central, accessed Oct 2026). Then remove "any noindex or robots.txt blocks that were only needed for the migration."

How does Search Console's Change of Address tool work?

It tells Google that your whole site has moved to a new domain, which helps it transfer signals faster. Use it only for domain or subdomain changes. Google's requirements (Search Console Help, accessed Oct 2026):

  • Ownership. "You must be an owner of both the old and new properties in Search Console", using the same Google account.
  • Domain-level properties only. It cannot move a path-level property such as example.com/shop/.
  • Not for every move. Do not use it for HTTP to HTTPS, or for switching between www and non-www on the same domain.
  • Every variant. Since June 2026, Google's guide says to submit requests "for all verified variants of the old domain, including subdomains and www/non-www versions."
  • Redirects first. The tool checks that you own both sites and that a sample of pages redirect permanently. Critical failures block the request until they are fixed.
  • 180 days. Google's handling "continue[s] for 180 days". Keep the redirects at least that long, and longer if old URLs still receive search traffic.

We used it ourselves. In October 2026 Digital Architect moved from digitalarchitect.dev to digitalarchitect.in, with a 308 redirect on every old URL to its exact new equivalent, then submitted the Change of Address in Search Console. Google's help page talks only about 301s. Its redirect documentation treats 308 as equally permanent, and the tool accepted our move.

What about Bing?

Bing follows permanent redirects on its own. Bing's 2020 migration guidance tells site owners to report the move with its Site Move Tool, which "requires verifying website ownership with Bing", and to update sitemaps to the new hostname (Bing Webmaster Blog, Dec 2020). However, users on Microsoft's community forum reported in 2025 that the tool is no longer available in the current Bing Webmaster Tools (Microsoft Tech Community, Jan 2025). We could not find an official Bing notice either way, so check your own account.

Whether or not the tool appears, the reliable steps are the same:

  • verify the new site in Bing Webmaster Tools;
  • submit the new sitemap;
  • use IndexNow to tell Bing which URLs have changed, if your platform supports it (Bing Webmaster Blog, 19 May 2025);
  • keep the redirects live.

How do you protect security and customer data during a move?

Treat the migration as a change to how you process personal data, not just a design job. Contact forms, booking systems, newsletter lists and customer accounts all move with the site.

  • HTTPS on every hostname. The old domain needs a valid certificate too, or HTTPS visitors see an error before the redirect fires. Google's web.dev guidance says not to enable HSTS "until you're certain your site operation is robust enough" to avoid certificate errors (web.dev, accessed Oct 2026).
  • Test every form end to end. Check that enquiries arrive, auto-replies send, and nothing is written to logs or emails it should not be.
  • UK and EU. UK GDPR requires "appropriate technical and organisational measures" for security. The ICO recommends encryption for stored and transmitted personal data, and says a contract with a processor, such as a new host or platform, "must stipulate that the processor takes all measures required under Article 32" (ICO, accessed Oct 2026).
  • Canada. Under PIPEDA an organisation remains responsible for personal information "transferred to a third party for processing", and must use "contractual or other means" to protect it (Office of the Privacy Commissioner of Canada, accessed Oct 2026).
  • US. Obligations depend on the state. California's CCPA, for example, applies to for-profit businesses that do business in California and meet set revenue or data-volume thresholds (California Attorney General, accessed Oct 2026).
  • Update your privacy notice if the host, processors or data locations change.

For client projects we host on AWS, and the security set-up is checked as part of the launch, not after it.

This is general information, not legal advice.

What should you monitor after launch?

Watch crawling, indexing and conversions daily for the first two weeks, then weekly. Google says that ideally "traffic on the old site will go down, while on the new site the traffic goes up."

  • Redirect test. Run the full old-URL list through a crawler or script, and confirm each returns one permanent redirect to the correct page.
  • Search Console. Check the Sitemaps report, the Page indexing report and the Performance report for both properties. Google also recommends checking "your server access and error logs" for Googlebot activity and unexpected error codes.
  • Analytics. Compare enquiries and sales, not just sessions, by landing page against the same period before launch.
  • Bing Webmaster Tools. Check crawl errors and indexing for the new site.
  • 404s. Fix any old URLs that return errors and still get visits or links.

Our 90-day plan for a newly launched website covers what to do once the move has settled.

How long does ranking fluctuation last?

Google gives a range, not a promise. It says to "expect temporary fluctuation in site ranking during the move", that "a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer", and that for medium-sized sites "it can take a few weeks or more for Google to gradually start showing the new URLs" (Google Search Central).

If traffic is still well below normal after that window, recheck the redirect map and the monitoring list above. Do not undo the move in a panic: reversing redirects restarts the process.

A website migration checklist

Before launch

  1. Decide what is changing, and split domain, platform and design changes into separate launches where you can.
  2. Benchmark rankings, organic traffic and conversions for the top pages.
  3. Build the URL inventory and the one-to-one redirect map.
  4. Copy the ranking content across and review it page by page.
  5. Keep staging behind a password, and list every noindex to remove.
  6. Prepare self-referencing canonicals, the new sitemap and the old-URL sitemap.
  7. Verify the new site in Search Console and Bing Webmaster Tools.
  8. Lower the DNS TTL if the hosting is changing.

Launch day

  1. Switch on the server-side 301 or 308 redirects and test the full list.
  2. Remove staging blocks and check robots.txt and canonicals on live pages.
  3. Submit both sitemaps, and file the Change of Address for every domain variant if the domain changed.
  4. Test every form, payment and booking flow over HTTPS.

After launch

  1. Monitor Search Console, Bing, analytics and logs daily for two weeks.
  2. Update internal links, profiles, ad campaigns and key backlinks.
  3. Keep the redirects for at least a year, and keep the old domain registered.

Planning a rebuild? Migration planning is part of every website development project we take on.

Frequently asked questions

Will a website redesign hurt my SEO?

Not if the URLs, content and internal links that earned your rankings survive. Most losses come from missing redirects, cut content or staging blocks left in place.

Is a 301 or 308 redirect better for SEO?

Neither. Google treats both as permanent server-side redirects. Choose whichever your server supports and keep it consistent.

How long should I keep redirects after a domain change?

Google says at least a year, and as long as possible. Bing's guidance says at least one to two years. Keep the old domain registered for the same period.

Do I need the Change of Address tool when moving to HTTPS?

No. For HTTP to HTTPS, Google's help page says "don't use this tool; Google will figure out your changes for you." The tool is for domain and subdomain changes.

Should I redirect deleted pages to my home page?

No. Google may treat mass redirects to the home page as soft 404s. Redirect to a genuinely equivalent page, or return a 404 or 410.

How long before rankings recover after a migration?

Google says a small to medium-sized site can take a few weeks for most pages to move, and larger sites take longer. Expect some fluctuation during that time.

About the author

Arjun Raj is the founder of Digital Architect, a web, app and digital marketing studio founded in 2023, with its head office in LB Nagar, Hyderabad, and a studio in Bengaluru. The studio builds and migrates websites for clients in India, the United States, Canada and the United Kingdom. Arjun holds a B.Tech in Computer Science and Engineering, specialising in cybersecurity, from IIT Guwahati. More about Arjun

Planning a redesign or a domain change? Send us your current site and what is changing, and we will tell you where the risks are. Talk to Digital Architect.

Want it done for you?

Skip the reading. Talk to the person who wrote it.

Book a free 30-minute call with Arjun and leave with a first read of what to fix.

WhatsAppBook a free call

Free · No obligation

Let's talk about your project

Book a free 30-minute call with Arjun, the founder, or leave your number and we'll call you back.

Step 1 of 2 · A few questions

30 minutes on Google Meet with Arjun, the founder. Free, with no obligation. Your answers help him come prepared.

Times from 11 am to 11:30 pm IST, every day. We use your details only to arrange this call. Privacy policy