Changing your domain or page addresses does not by itself cost you traffic from Google. What costs you traffic is missing an address map and setting up redirects on the fly, after the fact. What you need is to know which of three situations you're actually in, which redirect fits it, and how many days those redirects need to stay live before the new address fully takes over the old one's place in results.
This page gives you a working order of operations: how to build a map of old and new addresses, when to file a change of address in Search Console, what to check in the first week after the move, and which mistakes most often cost real customer inquiries.
Three situations where page addresses change
For Google this isn't one operation — it's three, each with a different level of risk. Before you start building an address map, work out which one you're actually in; that decides how much work and how much caution you need.
A new domain
The whole site moves to a different main address — from old-company.com to new-company.com, after a rename, a rebrand, or buying a shorter domain. This requires redirecting every old address to its counterpart on the new domain, plus filing a change of address in Search Console for the old site — without that, Google takes longer to recognize this is the same content under a new name.
New addresses on the same domain
The domain stays, only the address structure changes — for example after a rebuild by a new contractor, a platform change, or reorganizing categories. Here you don't file a change of address, because the domain is the same — the whole burden falls on an accurate map and redirects for every single page.
Migrating from http to https
Formally this is also an address change — http:// and https:// are two different addresses of the same page as far as a search engine is concerned. Usually the least risky of the three, because the paths after the slash stay identical, but it still needs the same thing: a permanent redirect from every old address to its https version, no exceptions and nothing redirected to the homepage.
The address map — the foundation of the whole move
Before anyone touches the server, you need a table: every old address and its exact counterpart at the new address. Without it, redirects get built from memory, and memory tends to lose exactly the pages that bring in traffic and inquiries — a service page, a contact form, a specific category offer.
The map is built from three sources at once: the list of addresses from the old site's panel, the traffic report (which addresses actually get visits), and the Search Console backlinks report (which addresses have links from other sites — those matter the most). An address with no counterpart on the new site also needs to be marked — the decision about it is part of the map, not something to sort out later.
| Old address | New address | Redirect type | Checked |
|---|---|---|---|
| /offer | /services | 301 | yes |
| /contact | /contact | 301 | yes |
| /blog/post-1 | /blog/post-1 | 301 | yes |
| /pricing | /services#pricing | 301 | yes |
| /gallery | removed, no counterpart | 410 or 301 to a category | to do |
| /shop/product-x | /shop/product-x | 301 | yes |
The "removed, no counterpart" row isn't an exception to the rule — it's the most common column in a real map. A page that's gone with nothing to replace it gets a 410 status (permanently removed) or a redirect to the nearest matching category — never automatically to the homepage, because that loses the signal of what the old address was actually about.
Permanent 301 and 308 redirects: telling Google "this is the same address"
Redirects split into permanent and temporary, and the difference matters for search results, not just for the browser. Google's redirects documentation states it plainly: permanent redirects show the new target address in results, while temporary ones still show the source address. Google treats code 301 (moved permanently) and code 308 (moved permanently, preserving the request method) the same way — as a strong signal that the new address should be canonical.
Use permanent redirects when you're sure the redirect won't be reversed — which is exactly the case with a domain change, a structure rebuild, or an https migration. Temporary redirects (302, 307) are for the opposite situation: a page being briefly unavailable, an A/B test, a seasonal promotion you'll switch off in a month. Mixing these two up is one of the more common mistakes in a site move — a temporary redirect left in place permanently means Google takes much longer to shift rankings to the new address.
Chain length matters too: address A redirects to B, B to C, C to D. Every extra link adds delay and the risk that a crawler stops following before it reaches the destination. A correct address map always runs in one step — straight from the old address to the final new one, with no stops along the way.
What Google's documentation says about PageRank and filing a change of address
Google Search Central spells it out: permanent redirects don't cause a loss of PageRank. That means links pointing to old addresses aren't wasted — their strength passes through the redirect to the new address, as long as the redirect is permanent and points directly to the right place.
For a domain or subdomain change, there's a second step: filing a change of address in Search Console for the old site, covering every verified variant of the old address — with and without www, http and https. This tool isn't a reporting formality — it's a signal for Google to actively pair the old and new versions of the site and shift the existing ranking over faster. Adding a sitemap for the new site speeds up discovery of the new addresses by crawlers, which shortens the time before traffic actually moves to the new address.
The whole path on Google's side runs as one chain:
- 01address map
- →02301 redirects
- →03filing a change of address
- →04watching indexing
- →05180 days of upkeep
Skipping any link doesn't stop the process entirely, but it stretches it out and raises the risk that some old addresses stay indexed separately, alongside the new ones.
How long to keep the redirects live
Search Console help for the change of address tool gives an exact figure: the move notification stays visible in Search Console for 180 days, and redirects need to stay in place for at least that long — longer if you're still seeing search traffic land on the old addresses after that. Removing redirects earlier than 180 days is one of the most common reasons part of the old traffic simply disappears instead of moving over to the new site.
180 days isn't a box to tick — it's the real time it takes Google to gradually update its index and shift signals from the old address to the new one. It's worth keeping the old domain you're moving away from paid up for that whole period even with no active content on it — letting it lapse breaks the redirect chain and undoes part of the effect of the whole move.
What to check in the first days after the move
Right after switching the site to the new address, the priority is the page indexing report in Search Console for the new site. It shows the indexing status of every address Google knows about — both indexed and skipped ones, with a stated reason. Some reasons are normal (an address deliberately blocked in robots.txt, or flagged as a duplicate of another page), and some point to a real problem that needs fixing.
Alongside the indexing report, check what a customer actually sees, not just what a crawler sees: does the contact form send submissions to the right address after the change, is the phone number on the site still current, does the site link on the Google Business listing point to the new address rather than the old one you're phasing out. It's also worth checking your analytics panel — a dip in inquiries in the first week after the move is partly normal while redirects are still working and the new addresses are still being indexed; no improvement after several weeks is a sign that something in the address map got missed. On how to set up the numbers an owner actually looks at every day, see our article on reporting automation.
The most common mistakes when changing a domain or addresses
The first and most common mistake is redirecting every old address to the homepage instead of to its exact counterpart. A visitor coming from a link to a specific offer lands on the homepage, doesn't see what they were looking for, and closes the tab — and Google loses the signal that the offer page ever existed at the new address.
The second mistake is redirect chains built up from a series of unsupervised changes — an address redirected to another, then again, and again. The third is a forgotten Google Business listing and paid ad links that still point to the old address — if those aren't redirected or land on a dead end, you lose traffic you're still paying for. The fourth, less often noticed: a redirect set up as temporary (302) "for now" and left that way for months.
The common thread in all these mistakes is nobody being responsible for the whole thing — each piece gets moved by someone different, and nobody checks the final result. We describe a similar kind of caution around bigger changes to company processes in our article on mistakes when implementing automation — the principle is the same: a change only shows its real effect once someone has checked every part of it individually.
Do it yourself: a checklist before, on the day, and after the move
Before the move: build a complete address map from three sources (site panel, traffic, backlinks); decide the redirect type for every row; get the server or hosting ready to handle permanent redirects; back up the old site.
On moving day: turn on redirects and manually check a sample of addresses — does each one land where it should, with no chain along the way; file a change of address in Search Console if the domain is changing; add and submit a sitemap for the new site; update the site link on the Google Business listing.
After 7 days: review the new site's indexing report; check that forms and the phone number work; compare inquiry numbers against the week before the move, expecting a temporary dip.
After 30 days: check in Search Console for the old domain whether the move notification is still active; spot-check a sample of old addresses for the correct redirect code; if traffic is still landing on the old address, leave the redirects in place — they need to run for at least 180 days.
How long it takes to check a sample of old addresses depends on how many there are: days_needed_for_verification = number_of_old_addresses ÷ addresses_checked_per_day. As an example using round numbers — substitute your own: at 240 old addresses and a pace of 40 checked per day, that's 240 ÷ 40 = 6 working days to fully verify the whole map.
What a system-run site move looks like
Manually watching the address map, redirects, and indexing report for several weeks is doable for ten pages and difficult for a hundred. When a system runs the process, the order stays the same, but oversight of every step moves from the owner's memory to a process:
- 01address map
- →02redirects
- →03checking each address
- →0430 days of monitoring
- →05a change report
No promises to hold rankings — Google decides the results; the system's job is making sure no step on your side gets skipped.
If the site is getting rebuilt from scratch alongside the address change, a good place to start is Websites and stores — structure built around one decision a visitor has to make, not a copy of the old site with a new address. Visibility in Google and maps after the move, including tidying up the business listing, is covered by SEO and maps. If the migration also involves an online store with a catalog and payments, that's covered by Online Stores — restaurants with online ordering go through a similar process, which we cover in our article on online orders for restaurants. Measuring how many inquiries and calls the new site brings in during the first weeks is handled by Analytics and BI, and connecting your till, calendar, and CRM to the new site by Integrations. Before deciding whether to build something custom alongside the move or stick with ready-made tools, read our article on custom automation versus ready-made SaaS.
Frequently asked questions
Does changing domains always lower Google rankings for a while?
Partly, yes — indexing the new address and transferring signals from the old one doesn't happen overnight, so short-term fluctuations are normal. How big and how long that period is depends on whether the address map is complete, the redirects are permanent and chain-free, and the address change was filed in Search Console.
Does a 301 redirect carry over all the previous traffic from Google?
A permanent redirect carries over the signal the search engine associates with an address, including link strength — but the ranking itself shifting in results takes time for the new address to be re-indexed. Traffic from direct links and bookmarks moves over almost immediately, as long as the redirect works correctly.
What should you do with a page that has no counterpart on the new site?
Mark that address separately in the map — don't redirect it to the homepage automatically. The fix is either a 410 status (permanently removed) or a redirect to the nearest matching category, if one exists and reasonably answers what the visitor was looking for.
Do you need to file a change of address in Search Console when only the address structure changes on the same domain?
No — the change of address tool is for moves between different domains or subdomains. When only the address structure changes on the same domain, what matters is an accurate map and permanent redirects for every page, with no separate filing needed.
How long should the old domain stay active after the move?
At least 180 days with working redirects — that's the period during which Google can still send traffic to the old address, and during which the move notification stays visible in Search Console. Longer, if reports still show traffic landing on the old domain after that.
Does migrating from http to https need the same kind of address map as a domain change?
Yes, in a simplified form — the paths after the protocol usually stay identical, so the map comes down to redirecting every http address to its https version. Same rule applies: a permanent redirect, no exceptions, and nothing pointed at the homepage by default.