A website migration goes well when every old URL leads to its new equivalent, Google can crawl the new site without being blocked, and someone watches old and new addresses separately for weeks. Google warns of temporary fluctuations, and for a medium-sized site it can take a few weeks or more before the new URLs appear. This guide follows that order: what kind of move you have, what Google says, what to save first, how to build the redirects, and what to check on launch day and afterwards.
Timeframes and rules come from Google's documentation, read on 5 November 2026. Where something is our own judgement we say so, and the examples with data are invented.
What changes with each type of migration
"Migration" covers several different jobs. The first question is whether the URLs people see will change, because almost everything else follows from that.
| Type of change | Do URLs change? | Change of Address tool | Where it can go wrong |
|---|---|---|---|
| Moving to a new domain | Yes | Yes, for every verified variant of the old domain | Forgotten variants (www, subdomains), redirects to URLs that don't exist |
| HTTP to HTTPS | Yes | No, Google works it out | robots.txt on the HTTPS version, internal links still on HTTP |
| New structure or paths on the same domain | Yes | No | Incomplete URL list, redirect chains |
| Changing CMS | Depends on whether paths change | No, unless the domain changes too | Templates without titles or without content in the HTML, leftover staging blocks |
| New hosting or CDN with the same URLs | No | No, it has its own guide | Capacity of the new server, DNS, switching off the old host too early |
The last column is our summary of the mistakes Google describes and of the risks of each change. It is not a statistic.
If you have several things to change, Google recommends doing them one at a time: first the domain, then the layout. The more you combine, the harder it is to tell what caused a drop. It also warns that combining a move with a redesign of content and URL structure will probably cost traffic, because Google may need to reassess individual pages.
What Google actually says
Plenty of migration advice is second-hand. These are the statements worth having to hand in any project meeting, because they settle the usual arguments. They come from Google's guide to site moves with URL changes, last updated on 20 August 2026.
- Duration: for medium-sized sites it can take a few weeks or more for Google to start showing the new URLs, and longer for large ones. Speed depends mainly on the number of URLs and your server.
- When it's finished: Googlebot has to visit every URL on the old and new site at least once. The move happens per URL, so there's no single date when the whole site switches.
- Link equity: Google says 301 and other permanent redirects don't cause a loss in PageRank.
- How long to keep redirects: as long as possible, generally at least a year. For users, Google suggests considering keeping them indefinitely.
- Redirect type: permanent and server-side if technically possible, such as 301 or 308. Client-side redirects are a last resort.
- Chains: Googlebot can follow up to 10 hops, but Google advises redirecting straight to the final destination or, failing that, ideally no more than 3.
- Home page: don't redirect many old URLs to one irrelevant destination such as the home page. It can confuse users and may be treated as a soft 404.
- All at once or in sections: Google recommends moving small and medium sites all at once. Large sites can go section by section, ideally starting with a part that changes little.
- Timing: if your traffic has seasonal or weekly dips, move during one.
- Load: after the move, Google crawls the new site more heavily than usual, because crawls of the old URLs are redirected on top. Your server has to cope.
Search Console's Change of Address tool is only for moving from one domain or subdomain to another, and only after the redirects are live. It isn't for HTTP to HTTPS, for www and non-www on the same domain, or for moving paths within a domain. On a domain move, Google asks you to submit it for all verified variants of the old domain, even ones you don't use. A less familiar warning: don't chain moves from A to B and straight on from B to C, and try not to merge several sites into one at once.
Before you touch anything: the inventory
A redirect map is only as good as the URL list behind it. For a simple domain change, one wildcard rule may do. As soon as paths change, you need the complete list. Google suggests starting with your important URLs and names these sources. The right-hand column is our addition:
| Source | What it gives you | What it misses |
|---|---|---|
| Sitemaps | The URLs you declared as important | Older pages that still get visits but are no longer declared |
| Server logs | What was really requested, by Googlebot too, images included | URLs with no requests in the period you chose. Make that period cover your seasonality |
| Web analytics | The URLs with the most traffic | Anything without the tag: refused consent, files, bots |
| Links in Search Console | Pages with internal and external links | Links the report doesn't list |
| CMS | Everything currently published | Old URLs that no longer exist but still get requests |
Google also mentions something that's easy to overlook: images, videos, PDFs, JavaScript and CSS have URLs too and need moving the same way. An image or a PDF may have traffic or links of its own.
What to save today
- Export Search Console by page and by query, for the longest period available, before the move starts. That is your baseline. The performance report shows three months by default, so change the range.
- Save titles, descriptions and H1s for every important URL, so that after a drop you can see what changed.
- Save structured data and hreflang annotations if you have them. They get lost easily when templates change.
- List the pages you can't afford to lose: those that sell, those with links and those that answer a specific query. That list is your final test, ahead of any overall percentage.
- Save the list of sites linking to your old URLs. Google advises keeping it so you can ask them to update their links later, starting with those that send the most visits.
This is also when you decide what won't move. Google asks that deleted content returns 404 or 410. If you've consolidated content on a new page, you can redirect to it. Removing a page with links or its own queries without checking its data is a decision that's easy to make without noticing.
The redirect map
This is where much of the outcome is decided. Google says it frequently sees people redirecting to wrong or non-existent URLs on the new site. The rule is simple to write: each old URL goes directly to its equivalent. The hard part is deciding what to do when there's no exact equivalent.
When there's no equivalent
Google sets two clear limits: don't send URLs in bulk to an irrelevant destination, and use 404 or 410 for what's gone. Between those, this is our order of preference. It's our judgement, not a Google rule:
- Direct successor. The same page, or the model that replaces it.
- Nearest category. If the product or article no longer exists, the subcategory it sat in, provided visitors find something comparable there.
- Parent category. Only if it still answers what the person wanted.
- 410. If there's nothing to offer, say so clearly.
The home page isn't on this list.
Why name similarity misleads
With thousands of URLs and no equivalent, it's tempting to automate: compare the words in the old slug with the new ones and take the closest. That's fine for proposing candidates. As a decision, it fails in a specific way. An invented example from a spare parts shop:
| Old URL | Closest candidate | Problem |
|---|---|---|
/brake-pads-model-x6-front | /mudguard-front-model-x6 | Model and position match, but it's a different part |
/tyre-8-inch-black | /tyre-10-inch-black | Nearly identical, wrong size |
/charger-model-2 | /charger-model | Trimming the "-2" looks like tidying a duplicate, but here it's part of the name |
Model and position are the same in both slugs, and only the product type tells them apart. A similarity score treats them all alike. To use automation without being misled:
- Rule out product type conflicts. If both URLs name a type and they don't match, drop the candidate however high its score.
- Rule out size conflicts. Two different measurements are two different products.
- Split into three lists: safe, unsure and no candidate. A person reviews the unsure ones, or they stay as 410.
- Read the destination. A 200 status says the page is alive, not that it's the right one. Slugs go stale while products change, so compare against the actual page title.
Which status code
| Situation | Code | What Google does |
|---|---|---|
| The page has moved for good | 301 or 308 | Treats it as a signal that the target should be canonical and shows the target in results |
| Temporary change | 302 or 307 | Keeps showing the source URL in results |
| Content deleted with no replacement | 404 or 410 | Removes previously indexed URLs from the index, and crawling gradually decreases |
| A "doesn't exist" page returning 200 | Avoid | Search Console may report it as a soft 404 |
An accidental 302 during a move means Google keeps showing the old URL, so your check has to look at the code as well as whether the redirect works. If redirects from an earlier migration exist, point them straight at the new destination so they don't form a chain.
Staging and sign-off
Before launch, review the new site the way Googlebot will see it. Google asks you to test thoroughly and gives details that prevent the costliest mistakes:
- Staging blocks. If you block crawling during development, prepare the final robots.txt now. If you use noindex, keep a list of the URLs it must come off. Google lists forgetting these blocks among common mistakes.
- noindex and robots.txt don't work together. For Google to see a noindex, the page must not be blocked in robots.txt. If it's blocked, it can still appear in results.
- Canonicals. Each new URL needs a self-referencing canonical. One possible template mistake is leaving them pointing at staging or the old domain.
- hreflang. With several languages, annotations must use the new URLs. Each version lists itself and the others, and if two pages don't point to each other, Google ignores the tags.
- Internal links. Change them to the new URL using the same map. A working redirect is no reason to link to it from your own site.
- Content in the HTML. If the new site relies on JavaScript, compare what the server returns with what's there after rendering. The details are in our guide to JavaScript SEO.
- Search Console. Verify the variants of old and new sites, and check verification will survive the move. If you've uploaded a disavow file, Google recommends uploading it to the new property as well.
- Newly bought domain. Check for manual actions and URL removals left by the previous owner.
Test the map against real data
Checking ten redirects by hand tells you little about a map with ten thousand. What gives confidence is a script that walks the full list of old URLs and checks for each one:
- that the first hop returns the planned code,
- that it reaches its destination in a single hop,
- that the destination returns 200,
- that the destination's title is the expected one,
- that the destination has no noindex and its canonical points to itself.
Status and content are separate tests: a page can return 200 and be empty or show an error. Also test a sample with parameters, with and without a trailing slash, and with capitals if your old site had them. If staging runs on another domain, the script should swap that and nothing else.
Launch day
Pick a low-traffic moment with people available afterwards. We wouldn't launch right before a weekend, because the first errors show quickly and someone has to be able to fix them. This sequence is based on Google's order. Step 8 and the owner column are our additions:
| Step | What happens | Who checks |
|---|---|---|
| 1 | Turn on the redirects on the server | Development |
| 2 | Remove blocks: final robots.txt and the noindex list | SEO |
| 3 | Check canonicals and robots meta rules in the main templates | SEO |
| 4 | Run the redirect script against the full list | SEO and development |
| 5 | Test important URLs with URL Inspection | SEO |
| 6 | Submit the Change of Address, if the domain changes | Search Console owner |
| 7 | Submit the new sitemap and keep the old one to hand | SEO |
| 8 | Test checkout, forms and analytics on the new site | Business owner |
| 9 | Point ad campaigns and profiles at the new URLs | Marketing |
| 10 | Review server logs: errors and Googlebot arriving | Development |
On sitemaps, Google's guide says two things: submit the new one because it helps discovery, and you can then remove the old one. In its monitoring section it also suggests submitting both to watch one fall and the other rise. In practice, keeping the old one for a few weeks gives you a useful gauge. Warnings there that the URLs redirect are normal, Google says.
The first 30 days
Google expects fluctuation. The difficulty is telling it apart from a fault. The basic rule: look at old and new URLs separately. Added together, a troubled migration can look stable for days.
| What you watch | What to expect | What should worry you |
|---|---|---|
| Indexed pages per sitemap | The old one falls towards zero and the new one rises | The new one still isn't rising after several weeks |
| Queries in Search Console | New URLs gradually gain impressions and clicks | An important query disappears without its new URL picking it up |
| "Not found" errors | A few URLs nobody mapped | An unusually high number, a sign of wrong redirects |
| Server logs | More Googlebot crawling than before | 5xx errors, which make Google slow down crawling |
| Traffic in analytics | Falling on old and rising on new | Falling on both at once |
| Pages you can't afford to lose | They keep doing their job and keep selling | One disappears or clearly loses clicks |
The timeframes aren't a promise. Google talks of weeks for most pages of a small or medium site to move, without being more exact, so comparing with last week on day one says little. Compare with the same earlier period, separate brand from non-brand, and allow for seasonality.
The mistake of measuring only what Search Console reports
An error report only shows what Google has already tried. If your map fails on URLs Google rarely crawls, weeks can pass with no warning. So keep running the script over the full list rather than only the URLs flagged. Server logs also show who still requests the old URLs. If it's people, they're arriving from links or bookmarks, and that's another reason to keep the redirects, beyond Google's advice.
If something goes wrong
- Check the mechanics first: noindex, robots.txt, canonicals and redirect targets. A forgotten block takes minutes to fix, and while it's there nothing else matters.
- Compare specific pages with the copy you saved: title, content, internal links.
- Roll back only as a last resort. With a serious fault and the old site still available, reverting early can do less harm than fixing on the fly. That's our judgement. Once Google has processed part of the move, reverting is itself another move.
Special cases
Changing e-commerce platform
This can change a great many URLs at once, including filters, variants and product images. Decide what happens to out-of-stock and discontinued products before you build the map, then apply the order of preference above. Filter URLs need their own decision: if they were indexed and got traffic, they belong in the map. Test a full purchase before opening, and test images too, since they have their own URLs.
Multilingual sites
Map each language separately, and check each translation goes to its translated equivalent. It's easy to send English to the German version by accident. hreflang annotations are reciprocal, so a mistake in one language can break the link with the others. If keeping every pair is too hard, Google says it will still process the pairs that point to each other.
Moving to a JavaScript framework
Before launch, check whether content and key tags are in the server's HTML. This move joins two risks, so Google's advice to change one thing at a time carries extra weight. The diagnostic steps are in our guide to JavaScript SEO.
Changing hosting without changing URLs
There are no redirects here. Google's steps are to copy and test the site, check Googlebot can reach the new infrastructure, lower your DNS TTL, switch DNS and shut down the old infrastructure only when nobody uses it, Googlebot included. Its logs tell you when.
When to get help
An HTTP to HTTPS move on a small site can be done by following Google's guide. A second pair of eyes is worth having when many URLs have no direct equivalent, when domain and CMS change together, when the business depends on organic traffic or when nobody can read the server logs. In that case, our SEO relaunch service can review your plan.
Frequently asked questions
How long does Google take to process a site migration?
Google gives no exact figure. For medium-sized sites it talks of a few weeks or more before new URLs start to appear, and longer for large ones. It depends on the number of URLs and server speed. The move is complete when Googlebot has visited all old and new URLs at least once.
How long should I keep 301 redirects?
Google says as long as possible, generally at least one year, so it can transfer all signals, and suggests considering keeping them indefinitely for users. Redirects add latency, so update your own links and the high-volume links from other sites.
Do 301 redirects lose link equity?
Google says 301 and other permanent redirects don't cause a loss in PageRank. That doesn't guarantee your rankings. If you also change content, structure or internal links, Google may reassess the pages, and any fall would come from those changes.
Can I redirect everything to the home page?
Google advises against it. Sending many URLs to a single irrelevant destination such as the home page can confuse users and may be treated as a soft 404. If content really has been consolidated on another page, redirect there. If it's gone, return 404 or 410.
Do I need Change of Address when moving to HTTPS?
No. Google says the tool is for domain or subdomain changes, and that it works out HTTP to HTTPS moves by itself. It also isn't for www and non-www on one domain or for moving paths. You still need redirects in all of those cases.
Should I migrate in phases or all at once?
Google recommends moving small and medium sites all at once, because that helps its systems detect the move faster. Large sites can go section by section to make problems easier to find. If you can, start with a section that changes little, though it won't fully predict what happens to the whole site.
Sources
Read on 5 November 2026.
- Google Search Central: Site moves with URL changes (updated 20 August 2026)
- Search Console Help: Change of Address tool
- Google Search Central: Changing your hosting
- Google Search Central: Redirects and Google Search
- Google: HTTP status codes and crawling
- Google Search Central: Block indexing with noindex
- Google Search Central: Localized versions and hreflang
- Search Console Help: Performance report
Further reading on the concepts: 301 redirect, 302 redirect, redirect chain, soft 404, canonical tag, hreflang, noindex and log file analysis.
How this article was made
This article was first published in March 2026. It was rewritten from scratch in November 2026 with AI assistance, from the Google documentation linked above, and reviewed before publication. The URL examples are invented, and parts marked as our own judgement don't come from Google.
