Website Migration Guide: Changing Domains Step by Step

A domain change goes smoothly when you treat it as five jobs in a fixed order: prepare the new site, map every old URL to a new one, set up permanent redirects on the server, launch and tell Search Console, then watch both sites. That is the sequence in Google's site move with URL changes (Opens in a new tab) documentation, which also states plainly that temporary ranking fluctuation is to be expected. Nothing guarantees an unchanged position afterwards, but avoidable damage comes from steps skipped before launch day.

If you run a small shop, a publisher or an agency handling a client's rebrand, one page that holds the whole plan saves you from piecing it together under pressure. Moves that leave every URL untouched, such as a hosting switch, follow a different Google document and get only a short comparison here.

The five stages at a glance

Google splits a move with URL changes into stages, from general best practices to traffic monitoring. The table turns each stage into something you can hand to a person and check off.

Which document governs your project depends on the kind of move. Google lists three kinds that change URLs: a change of URL scheme such as http to https, a domain change (including merging domains or host names) and a path change such as page.html becoming page.htm. When the switch affects only hosting or a content delivery network and users see the same URLs, the separate site move without URL changes (Opens in a new tab) page applies.

Fix the scope in writing

A move touches several teams, so open with a one-page scope note. It names every domain, subdomain and language that will move and says who owns each task.

Scope questions

• Is only the main domain moving, or also the blog, shop and help centre subdomains?
• Are several domains merging into one? Google counts that as a domain change.
• For multilingual sites, will hreflang annotations be rewritten to the new URLs for every language?
• Are images and downloads moving with the site or staying on a CDN?
• Which pages will not move, and does each have a decided 404 or 410 outcome?

Who does what

In a very small business one person can hold all five roles. Write the list anyway, because the date next to each task is what lets you spot a gap.

Three rules to settle before you start

Change one thing at a time

Google advises against combining a domain move with a CMS change or a layout change. If traffic falls, you will not know which change caused it. Practical suggestion: postpone the redesign until after the move settles. The website redesign SEO checklist covers that separate project.

Choose a quiet period

The page recommends a low-traffic period where possible, which limits lost visitors and leaves server resources free for crawling. Launching in the middle of a seasonal rush is a risk you can avoid.

Decide between all at once and in sections

For small and medium sites Google recommends moving all URLs simultaneously. For large sites, moving one section at a time makes problems easier to find and fix. If you split a large move, start with a stable section.

Know what a move does not fix

A new domain carries the old site's weaknesses with it: thin pages, broken links, slow templates. Note them before the move so that a later dip is not blamed on the migration by reflex.

Plan the way back

The Search Console help page on the change of address tool says a move can be cancelled within 180 days. It describes the steps: remove the 301 redirects from the old server, add 301 redirects from the new site back to the old one and press Cancel Move in the tool on the old site. Work out in advance who would do that and how long it would take.

Build and verify the new site

Redirects should only go live once the new domain holds a complete, tested copy of the site. Google's preparation points translate into a checklist.

• Set up the CMS, preferably the same one, and import the content.
• Move hosted images and downloads such as PDF files.
• For https, obtain and configure the TLS certificate.
• Set up robots.txt on the new site and remove any crawl blocks that existed only for development. If no robots.txt exists, the server should return a proper 404.
• If you used noindex during development, list the URLs from which you will remove it.
• Return 404 or 410 for content you are not moving. The HTTP status codes guide explains the difference.
• Install analytics on both sites.

Search Console verification

Google asks you to verify all variants of both the old and the new site: www, non-www, http and https. Check that the verification file, meta tag or analytics code will survive the move, and match settings across the two properties. Leave the crawl rate on "Let Googlebot determine" and upload any disavow file to the new property again. The domain vs URL-prefix property article explains the property types.

Check the domain's history

If the new domain was owned before, look for manual actions and leftover URL removals from the previous owner. Google says to file a reconsideration request if needed. The documentation does not say how long such a review takes, so do this check well before launch day.

Server capacity

According to the page, Google temporarily crawls a migrated site more heavily than usual. Plan for the extra load, and warn your host if the site is large.

Collect the old URLs

Everything in the move hangs on a table that pairs each old URL with its new one. Google lists where to find the old URLs: sitemaps and the Search Console Links report to find the important pages, server logs and analytics to find high-traffic and recently visited URLs, the CMS itself, which can list all content URLs, and embedded resources such as images, videos, JavaScript and CSS.

You can store the pairs in a database or as rewrite rules. When only the domain changes and every path stays the same, Google notes that a single wildcard server-side redirect may be enough. As soon as paths change as well, each address needs its own mapping.

Updates on the new site

1. Give each new URL a self-referencing canonical tag and make sure canonicals point to new URLs.
2. Update hreflang annotations to use the new URLs.
3. Point internal links to the new URLs.
4. Save a new sitemap and a list of the sites that link to your old URLs.

The list of linking sites feeds the outreach in the final phase. For the wider question of keeping link value through a move, see preserving backlink value during a site migration.

Redirect rules that hold up

Google recommends server-side permanent redirects, meaning 301 or 308. Ask your host or server administrator what is possible, for example .htaccess rules or a redirect function in the CMS. Client-side redirects are a last resort.

Avoid chains

Redirect straight to the final destination. If that is not possible, keep chains short: ideally three hops or fewer, and fewer than five. For existing chains, see redirect chains and loops.

Never funnel everything to the home page

Google tells you not to redirect many old URLs to one irrelevant destination, such as the home page of the new site. Send consolidated pages to the new combined page. A page with no equivalent should return 404 or 410.

Permanent, not temporary

For a domain change the redirect must be permanent. A temporary redirect does not tell Google that the target is the new canonical address.

Launch day, in order

1. Switch the redirects on by pushing the server configuration or enabling the CMS setting.
2. Check annotations: canonicals should point to the new URLs and no noindex should remain on them.
3. Test the redirects. Use URL Inspection for single URLs and scripts or command-line tools for bulk testing.
4. If a domain or subdomain changes, use the change of address tool. Google says you only need it when moving from one domain or subdomain to another, and it should be filed for every verified old variant.
5. Submit the new sitemap in Search Console and replace the old one.
6. Update internal links, social profiles and ad destinations straight away.

The conditions of the tool are a topic of their own. In short, you must own both properties with the same Google account and only domain-level properties qualify. The help page Change of Address tool (Opens in a new tab) lists the conditions. If your interface is not in English, menu names may look different.

A test sample for the redirects

Google tells you to test redirects but leaves the choice of URLs to you. Grouping them makes testing systematic. These groups are a practical suggestion.

For each row, record the status code, the final address and the number of hops. More than two hops suggests a chain. Re-running the same sheet after launch is the easiest way to show that nothing broke.

What to watch after launch

A move is not complete until Googlebot has visited every URL on both the old and the new site at least once, according to Google. Speed depends on site size and server capacity.

A weekly reading routine

Practical suggestion: answer the same three questions each week and log the answers in one sheet. How many new URLs are indexed, how many remain on the old sitemap, and did a new error type appear? If traffic stays lower than expected for longer than you can explain, inspect the server logs for the responses Googlebot receives, then recheck canonical and noindex settings.

How long the redirects stay

The site move page says to keep redirects for as long as possible and names at least one year as the benchmark. The help page for the change of address tool sets a lower floor: keep the redirects at least 180 days, and longer if you still see traffic to them from Google Search. It also recommends keeping the old domain registered for at least a year.

These two statements do not contradict each other. One is a minimum for the tool's process, the other a longer-term recommendation. Practical suggestion: put the domain renewal in the calendar and use the end of Google Search traffic to the old address as the sign to retire redirects, not a fixed date. Time limits in Google documents can change, so check the current pages before relying on them.

Redirects are slower for users, so keep updating internal links and your busiest external links to point directly to the new URLs.

Example scenario: a jewelry workshop

Example scenario: a family jewelry workshop sells rings and custom orders through a small site and has decided to rename itself after a new studio location. The site has product pages, a care guide section and an enquiry form for commissions.

The owner writes a scope note first. Only the main domain moves, the care guides keep their paths and the redesign is postponed. The URL inventory comes from the sitemap, the Links report and analytics, and a short list of discontinued ring styles gets a 410 plan. Because paths stay the same, one wildcard permanent redirect handles the bulk. The enquiry form gets its own test, since a redirect that drops submitted data would cost real orders.

Launch happens on a quiet weekday. The owner verifies all variants of both domains beforehand, turns on the redirects, spot-checks the sample table, files the change of address and replaces the sitemap. Over the next weeks the log shows the old sitemap shrinking and the new one growing. The old domain's renewal goes into the calendar for a year ahead.

Hosting and https are separate jobs

If you change host and domain together, split them. Hosting changes that keep URLs the same follow Google's separate guide. It says to point DNS to the new infrastructure, lower the TTL to a conservative value about a week before the move, keep the old server running until traffic to it reaches zero and confirm with URL Inspection that Googlebot can reach the new host. Details are in changing web hosts: DNS cutover checklist.

The https switch is its own project too. For mixed content and HSTS use mixed content and HSTS after an https migration, and for settling on a single version of the address see www vs non-www, https and trailing slash.

Telling the outside world

Google lists several immediate follow-ups: fix internal links, ask external sites to update their links, update social profiles and point ad campaigns to the new landing pages. A sensible order follows.

1. Update properties you control: social profiles, email signatures, newsletter templates and payment page fields.
2. Switch ad destinations to the new URLs.
3. Rank the sites that link to your old URLs by importance and send each a short request with the old and the new address.
4. Update partner and directory listings.
5. Publish an announcement on the new site that explains the change to your readers.

A link update request works best when it is short and can be copied in one click. Since redirects already work, a late update will not lose the visitor, but it forces one extra step on every click.

Mistakes to review

Development blocks left in place

Google reminds you to remove noindex and robots.txt blocks that were used only for the migration. When a page seems to be missing from the new site, test it with URL Inspection.

Redirects to URLs that do not exist

The troubleshooting section names redirects to non-existent URLs as a problem. If you see many "Not found" responses, crawl the site with a crawling tool.

Old sitemaps left behind

Make sure every sitemap lists the new URLs.

Not enough capacity

Confirm that the server can handle the heavier Googlebot traffic.

Several changes in one week

New domain, new theme and new menu together make a traffic dip impossible to explain.

Checklist for the first look after launch

• The home page and five key pages reach the right new address in one hop.
• No noindex or crawl block remains on the new site.
• Canonical tags show the new address.
• The new sitemap is submitted and the old one is being watched.
• The change of address was filed for every old variant.
• Analytics and Search Console verification still work.

Frequently Asked Questions

Is a traffic loss unavoidable when changing domains?

Google says to expect temporary fluctuation in ranking during a move, and that medium sites can need a few weeks or more. Permanent redirects and accurate mapping reduce the risk of loss, but no outcome is guaranteed.

Can I redirect every old page to the new home page?

No. Google tells you not to redirect many old URLs to a single irrelevant destination such as the home page. Map each old address to its real equivalent and return 404 or 410 for pages with none.

How long should I keep the redirects?

The site move page says to keep them as long as possible, naming at least one year. The change of address help page sets a floor of at least 180 days and longer if Google Search traffic still arrives.

Is the change of address tool mandatory for a domain change?

Google says you need the tool when moving from one domain or subdomain to another. You must own both properties and use the same Google account for both.

May I redesign the site during the domain move?

Google advises changing one thing at a time. If traffic fluctuates, you cannot isolate the cause. Do the redesign before or after the move.

Is a hosting change also a site move?

A hosting or CDN change that leaves visible URLs unchanged follows a separate Google document, which covers the DNS switch, the TTL and keeping the old server running until its traffic reaches zero.

Conclusion

A domain move succeeds through small tasks done in order, not through one clever setting. Settle on one change at a time, build and verify the new site, collect the old URLs and pair each with its equivalent, set up permanent server redirects without chains, file the change of address and watch both sites. Keep the redirects for at least the period Google recommends.

After the move, if you want to build fresh mentions for the new domain, our guest post service can help.