Changing Domain Name SEO: Does It Hurt Rankings?

Changing your domain name does not permanently cost you rankings, provided every old URL 301-redirects to its matching new URL and those redirects stay up. Google supports the move, gives you a tool for it, and calls the fluctuation that follows normal. Its documentation says a medium-sized site takes "a few weeks for most pages to move in our index", and that you should "keep the redirects for as long as possible, generally at least 1 year".

The permanent losses come from execution, and one specific timing mistake causes more of them than anything else. The Change of Address tool in Search Console forwards signals for 180 days. Google's advice on redirects is at least a year. Teams read the first number as the length of the migration, retire the old domain at six or seven months, and take down the redirects while Google is still using them.

Does changing your domain name hurt SEO?

Temporarily, yes. Permanently, only if something in the move is broken. Google's guidance on moving a site with URL changes states plainly that "the visibility of your content in Search may fluctuate temporarily during the move" and that "this is normal and a site's rankings will settle down over time".

The mechanism behind the dip is worth understanding, because it tells you what to worry about and what to leave alone. When you change domains, every URL Google has indexed is now a different URL. Google does not learn this all at once. It learns it one URL at a time, as it recrawls each old address and discovers the redirect sitting there. Until it recrawls a given page, that page is still associated with the old domain in the index. So for a few weeks you have a site that is genuinely half moved, and the reporting reflects that honestly rather than being broken.

What does not recover on its own is a URL that never got a redirect, or got one pointing somewhere unhelpful. Those pages had rankings, links and history, and none of it transfers to a homepage they were dumped on. A domain change is not risky because Google penalizes it. It is risky because it forces you to be complete about several thousand URLs at once, and completeness is hard.

How long does it take Google to move a site to a new domain?

Google's answer is that "as a general rule, a medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer". Size is the variable that matters, because the work is per URL. A thirty page site can move in days. A large catalog moves in whatever order Googlebot reaches it, which means a month or more of watching a chart that is part old domain and part new.

A more useful question during those weeks is whether the move is progressing or stuck, because for the first two weeks both look the same. The thing to watch is direction, not level. A healthy migration shows new URLs entering the index at roughly the rate old ones leave it. A stuck one shows old URLs dropping while new ones stay flat, which almost always means Googlebot is following your redirect and then hitting something on the target that stops it. In practice that is a canonical tag still naming the old domain, or a noindex that shipped with the new site and never got removed.

Give it four weeks before you conclude anything. If new URLs are still climbing at four weeks, keep waiting, because that is exactly what the documented behavior looks like. If they have been flat for a fortnight while old ones fall away, stop waiting and go read the rendered HTML of a page that should have moved.

The 180 day trap

The Change of Address tool tells Google that one domain has become another, and forwards signals between them. Search Console's documentation says these actions "continue for 180 days after you start migration in Search Console", after which Google stops recognizing the relationship between the two sites.

Read next to Google's redirect advice, that produces a gap most people never notice. Six months of signal forwarding, at least twelve months of recommended redirects. The tool finishing does not mean the migration finished. It means the shortcut expired and your redirects are now doing all of the work by themselves, which is precisely when people cancel the old domain registration because the migration "is done".

Two things follow from that. Renew the old domain for at least two years at the moment you migrate, and put a calendar reminder on the renewal rather than trusting anyone to remember why an unused domain is still being paid for. And treat the redirects as permanent infrastructure. There is no benefit to removing them, and every year of traffic and links pointing at old URLs keeps arriving.

What the Change of Address tool does and does not cover

The row that surprises people is the subdomain one. Consolidating a blog from a subdomain into a subfolder is one of the most common moves there is, and the tool does nothing for it. That move runs entirely on redirects, internal linking and patience, and it typically takes longer to settle than a straight domain change because there is no signal shortcut at all.

What actually causes permanent losses

Every one of these is an execution failure rather than anything Google did:

Redirecting everything to the homepage. If an old URL has no exact equivalent, the honest choices are the closest relevant page or a clean 404. A mass redirect to the homepage tells Google the old pages were not really replaced, and their history goes nowhere.

Using 302 instead of 301. Google treats a permanent redirect as a signal that the target should be canonical and shows the new URL in results. A temporary redirect does the opposite: Googlebot follows it, but the indexing pipeline does not treat the target as canonical, so the old URL keeps appearing. Our breakdown of the "page with redirect" status in Search Console covers how that shows up in the report.

Redirect chains. Old URL to intermediate to final is common when a domain change lands on top of an earlier restructure. Each hop is another thing that can break, and the chains tend to grow rather than get cleaned up.

Building the map from the sitemap. Your sitemap is the list of URLs you meant to have. Google's index contains the URLs it actually has, and the difference is usually older pages still earning traffic that nobody currently on the project knows exist. Export what is indexed, not what is listed.

Leaving canonicals pointing at the old domain. The single most common reason new URLs refuse to index after an otherwise clean move. It is invisible unless you look at the rendered HTML of the new pages.

Forgetting everything outside the website. Ad accounts, analytics properties, email footers, review profiles and any dashboard that pulls your channels together are all still pointed at the old domain the morning after launch, and the resulting reporting gap gets misread as a traffic collapse for about a week.

The sequence that works

Before the launch, export the URLs Google currently has indexed and record impressions, clicks and average position for each one. That is your baseline, and without it every later conversation about whether traffic dropped is opinion. Then map each old URL to one new URL, single hop, with deliberate decisions about the ones that have no equivalent.

At launch, verify the redirects return 301 and not 302, submit the new sitemap in Search Console (Google says you can remove the old one at that point, since it will use the new sitemap going forward), and file the Change of Address request, including for the domain variants you do not use. Update internal links and canonicals to point at the new URLs directly rather than relying on the redirects.

After launch, the job is measurement for at least a month. Google is going to move your pages over on its own schedule, and the only thing you control is noticing quickly when a page is not moving. The full pre-launch and post-launch sequence, including redesigns and replatforms where the domain stays the same, is laid out on our website migration SEO checklist.

How to tell whether the move is finished

A redirect that returns 301 in your browser proves the server is configured. It proves nothing about whether Google has recrawled that old URL since you configured it, followed it, accepted the new URL as canonical, and indexed it. Those four steps fail independently, and none of the failures are visible from a redirect checker.

Search Console will answer this properly. The URL Inspection tool is exact but works one URL at a time, and Request Indexing is capped at roughly ten to twelve URLs a day per property, so neither scales to a migration. The Page indexing report covers the site, but Google notes that "the list of example URLs in the report is limited to 1,000 items, and isn't guaranteed to show all URLs in a given status, even when less than 1,000 items", and on a large move the URLs you most need are often the ones the sample omits.

The practical approach is to check both URL sets in bulk and repeat it weekly, so you are reading a trend instead of a snapshot. Watching old URLs leave the index is as informative as watching new ones arrive, and pages that fall out without a replacement showing up are the ones worth investigating. Our deindexed page detection is built for exactly that half of the picture, and new URLs that are eligible but slow can be resubmitted through official channels with the bulk URL indexer.

Changing your domain name in one paragraph

It costs a temporary dip and not a permanent loss, as long as every indexed old URL 301-redirects to its closest new equivalent and those redirects stay up. Expect a few weeks for a medium site and longer for a large one. File the Change of Address request, submit the new sitemap, update canonicals and internal links to the new URLs, and then measure both URL sets weekly until new pages have clearly replaced old ones. The 180 days the Change of Address tool runs for is not the length of the migration. Google's advice on the redirects themselves is at least a year, so keep the old domain registered well past the point where the move feels finished.