You bought the better domain. The one that matches the rebrand, drops the hyphen, or finally gets you off the platform subdomain you launched on three years ago. Now the cursor is hovering over the DNS record, and the only question that matters is whether the rankings you spent those three years earning will survive the jump to a new address.
They can. Moving to a new domain is one of the few high-stakes SEO operations with a documented, Google-supported path, and most of the ranking loss people blame on migrations comes from a short list of avoidable gaps rather than from the move itself. What follows is what actually transfers, which tool does what, and the order of operations that keeps your equity attached to your pages.
What a domain move is, and what it is not #
A domain move is content leaving one hostname and arriving at another: example.com becoming example.org, or shop.example.com folding into example.com. In Google’s own vocabulary this is a “site move with URL changes,” because the address of every page changes even when the content on it does not. The hostname moved. That is the whole event.
Two operations look similar and are not the same, which matters because they use different tools and carry different risk. Switching from HTTP to HTTPS on the same domain is a site move without URL changes in Google’s terms, and it does not use the Change of Address tool at all. Reshuffling folders or slugs inside a domain you are keeping is a URL-structure change, not a domain move. If the registered domain or subdomain is what changed, you are in domain-move territory, and the rest of this applies.
What the Change of Address tool does, and what it does not #
The Change of Address tool lives in Google Search Console, and it is a message, not a moving truck. Filing it tells Google to emphasize crawling and indexing your new site over the old one, forwards ranking signals from the old URLs toward the new ones, and tells Google to prefer the new pages when it picks a canonical. Before it accepts the request, it checks that the redirects are in place on your top five URLs.
Here is the part that trips people up. The tool moves nothing on its own. The redirects do that. Filing a change of address over broken or missing redirects accomplishes little. It also has boundaries worth knowing before you rely on it:
- It applies to domain and subdomain changes only. For an HTTP-to-HTTPS move you skip it.
- Both the old and new sites must be verified in the same Search Console account, including the www and non-www variants.
- If you are moving several subdomains, you file a separate request for each one, plus the www and non-www forms.
Tool interfaces and steps in Search Console change over time, so confirm the current flow in Google’s Search Central documentation before you file rather than trusting a screenshot from an old tutorial.
The redirect map is the actual work #
If one part of a domain move earns the late night, it is this one. Every old URL that Google has indexed needs a permanent, server-side redirect (a 301, or a 308, never a temporary 302) pointing to its closest equivalent on the new domain. Not to the new homepage. To the matching page.
Redirecting everything to the homepage is the classic shortcut that quietly costs rankings, because a product page that now answers with “here is our homepage” reads to Google like a page that no longer exists. Keep the mapping one-to-one wherever a real equivalent exists, and reserve the fallbacks for genuine dead ends. A simple decision rule covers almost every URL:
| Old URL situation | What to do |
|---|---|
| Exact equivalent exists on new domain | 301 straight to that page |
| Close but not identical page exists | 301 to the nearest genuinely relevant page |
| No equivalent, but the old page had traffic or backlinks | 301 to the most relevant parent or category, not the homepage |
| No equivalent, and the page had no value | Let it 404 or 410, or consolidate it, rather than forcing a redirect |
Two mechanical rules protect the map. Redirect straight to the final destination, because chains bleed speed and reliability even though Googlebot will follow up to about ten hops before it gives up. And clear out any conflicting redirect directives that were already sitting on your servers, since Google can keep obeying an old instruction it finds on the next crawl. Domain moves rarely fail at the strategy level. They fail in the gap between “I filed the change of address” and “every indexed URL resolves through a single clean 301.”
The order you do it in #
Order matters more than speed. Sequence is what separates a calm move from a scramble, and a workable order looks like this:
- Stand the new site up completely, with a self-referencing canonical tag on every new URL.
- Verify both the old and new properties in Search Console, every variant included.
- Put the 301 redirect map live, old URL to new URL.
- Test the redirects: your top pages first, then a broader sample, checking for chains and dead ends.
- Submit an updated sitemap of the new URLs in Search Console.
- File the Change of Address request for each old-domain variant and subdomain.
- Update internal links to point at the new URLs, and ask the sites behind your most valuable backlinks to repoint them.
The backlink step is easy to skip and worth the effort. Redirects forward the equity, but a link that points directly at the live new URL is cleaner than one that arrives through a redirect, and the handful of domains sending you the most authority are usually a short, workable list.
Change one thing at a time #
This is the discipline that saves the most migrations, and it is the one teams most want to break. Google’s guidance is to change only one thing at a time, and to move all your URLs together rather than section by section. A domain change stacked on top of a redesign, a CMS swap, and a content cull is not one project. It is four experiments running at once.
The reason is debugging. If your traffic shifts a week after a clean domain move, you have exactly one variable to examine. If it shifts after you also relaunched the design, rewrote half the pages, and pruned the rest, you have no way to tell which change did it, and no way to reverse the right one. Move it as-is. Redesign next month, on its own, where you can measure it.
After the switch: keep both sites alive and watch two properties #
The move is not done when DNS propagates. The old domain has a job to do for a long time yet, and the job is to keep answering. Leave its server responding and its redirects live, because Google recommends keeping migration redirects in place as long as possible, generally at least a year. The Change of Address relationship itself runs on roughly a 180-day window, but re-filing is not the maintenance plan; the redirects are, and they should outlast the tool’s window if any traffic is still reaching the old URLs. Do not switch the old pages to 404 early.
Expect the index to move at Google’s pace, not yours. A small-to-medium site generally takes a few weeks for most pages to reindex under the new domain, and larger sites take longer, depending on how many URLs there are and how fast the servers respond. During that stretch you watch two Search Console properties at once: coverage and impressions climbing on the new domain, residual crawling and traffic fading on the old one, plus crawl stats on both so you can catch a redirect that broke or a page that got stranded.
There is usually a wobble in the first week or two. Hold your nerve. Judge recovery over weeks, not over the panic of a single morning’s numbers. Before you ever touch the DNS record, export a full list of your indexed URLs from Search Console’s page indexing report and a crawl, and build the map against it. The move is only ever as clean as that spreadsheet.