How to change your domain name without harming your website’s SEO

Changing a domain name sounds like a settings change. In reality, it’s closer to moving houses. Everything that pointed at the old address, search rankings, backlinks, bookmarks, email, ad campaigns, has to be told where you went or it gets lost.

The good news is that a domain change is a solved problem. Google has a documented process for it and the work is mostly mechanical once you know the order. The bad news is that the order matters and one step done out of sequence is the difference between a clean move and months of lost traffic.

This guide covers moving a live website from one domain to another, for example from oldbrand.com to newbrand.com, while keeping your traffic and rankings intact. Before the steps, one point of confusion is worth clearing up, because it sends a lot of people down the wrong path.

"Changing a domain" can mean different things

People search for this phrase meaning very different jobs. Getting the wrong one wastes days.

• Moving your whole site to a new domain. Your content stays the same, the address changes. This is what most people mean and it is what this guide covers.
• Forwarding one domain to another. You keep the site where it is and point a second domain at it. This is a redirect you configure at your registrar, DNS provider or redirect service, not a migration. If that is what you need, see our guide to domain forwarding.
• Changing a display name or brand. If the domain itself is not changing, you are editing content, not moving a site.
• Pointing DNS at a new host. If the domain stays the same and only the server changes, that is a host move, not a domain change and it does not need most of the steps below.

If your job is the first one, moving a live site to a genuinely new domain, read on. The load-bearing step is redirects, so most of this guide is about getting those right.

Why you would want to change your domain name

A domain change is almost always downstream of a business decision. The common reasons:

1. Upgrading to a shorter or cleaner domain.

The easiest case. The brand and usually the URL structure stay the same, so it is close to a straight domain swap. Moving from getmybrand.io to mybrand.com, where /pricing and /blog/post-title keep the exact same paths and only the domain in front changes, is a typical example.

2. Moving to a .com from a .io, .net or country-code domain.

Also low risk on its own. The trap is doing it at the same time as a rebrand, which quietly turns one migration into two.

3. A rebrand or company name change.

The most common trigger. The whole site moves, but if you carry the URL structure across unchanged, the move stays manageable.

4. Spinning a product or brand off onto its own domain.

Harder, because only part of the site moves. The risk is in the mapping: deciding exactly which URLs leave and which stay and not orphaning either side.

5. A merger or acquisition that consolidates several sites onto one.

The hardest by a distance. You are running several migrations at once, each with its own redirect map, often with competing URL structures and separate teams who all have to agree. This is the trigger we see go wrong most often.

The reason rarely changes the process. Whatever the trigger, the technical move is the same.

What’s impacted when you change your domain

This is the part that turns a simple idea into a real project. When the domain changes, every reference to the old one is now pointing at nothing unless you handle it.

• Organic rankings and search traffic. Search engines have indexed your old URLs. Without redirects, those pages return errors and the rankings attached to them disappear.
• Authority: Search engines build trust in a domain over time and that trust is tied to the old one. A new domain starts without it and while Google says permanent redirects do not cause a loss of PageRank, the transfer is not instant because Google has to recrawl the old URLs and reassign the links pointing at them. This is a big part of why a move causes a temporary dip before rankings recover.
• Inbound backlinks. Every link from another site still points at the old domain. Those links only keep their value if the old URLs redirect to the new ones.
• Email. Addresses on the old domain stop working unless you migrate email separately.
• Bookmarks, QR codes and print. Anything saved or printed with the old address needs the old domain to keep resolving.
• Analytics continuity. Your historical data lives under the old domain. Plan how you will keep reporting continuously across the cut.
• Paid campaigns and tracking. Ad destination URLs, UTM parameters and conversion tracking all reference the old domain.
• Integrations and callbacks. Webhooks, API callbacks, SSO and third-party tools configured with the old hostname will fail until updated.

None of these are hard on their own. The failure mode is forgetting one of them.

Before you start: the pre-change checklist

Do this before you touch anything live. A domain move is far easier to get right than to fix after the fact.

Register and secure the new domain.

Confirm you own it and can manage its DNS.

Crawl the old site and export every URL.

You need a complete inventory of what exists today. This becomes the master list for redirects.

Build a one-to-one URL map.

For every old URL, write down its exact match on the new domain. Old homepage to new homepage, old pricing page to new pricing page and so on down the list.

Baseline your rankings and traffic.

Record current positions and organic traffic now, so you can measure recovery later and spot real problems versus normal noise.

Plan the email move separately.

Website and email are different systems that happen to share a domain. Decide how mailboxes and MX records will move.

List every external reference you control.

Social profiles, business listings, ad accounts, email signatures, anything you can update directly.

The URL map is the single most important artifact here. Skipping it is how sites end up redirecting everything to the homepage, which is a mistake we will come back to.

How to change your website's domain name, step by step

The order below is deliberate. In particular, redirects go live before you tell Google, because Google checks for them.

1. Register and verify the new domain

Own the new domain outright and confirm you can control its DNS records. If email will move too, make sure the new domain is set up to receive mail before anyone relies on it.

2. Stand up the site on the new domain

Publish your site on the new domain so that the new URLs actually resolve. Where you can, keep the same URL structure. Google's site move guidance is to change only one thing at a time, so keeping the URL structure identical is the safest option.

While you are still testing, keep the new domain private with password protection so Google does not index it as a duplicate of your live site before launch. Remove that protection at cutover. Noindex is a weaker fallback if you cannot password-protect, since it still lets the pages be crawled.

If you combine a domain change with a URL restructure or redesign, expect a larger and longer traffic dip, because Google has to relearn the pages as well as the domain. If you can, move the domain first and redesign later as a separate project.

3. Configure DNS for the new domain

Point the new domain at your site and confirm it loads correctly over HTTPS. Sort out the www versus non-www version now and pick one canonical version rather than leaving both live and competing.

4. Set up 301 redirects from every old URL to its match

This is the step everything else depends on. Use permanent redirects, 301 or 308, rather than temporary 302s, because Google treats a permanent redirect as a strong signal that the new URL should become the canonical one, while a temporary redirect tells Google to keep showing the old URL. Point each old URL at its true equivalent on the new domain, page by page, using the map you built. There is more detail on doing this correctly in the next section, because it is where most migrations go wrong.

5. Update internal links, canonical tags and hardcoded references

Redirects are a safety net, not a substitute for clean links. Update internal links to point directly at the new URLs so visitors and crawlers are not bounced through a redirect on every click. Update canonical tags to the new domain. Search your codebase and templates for the old domain hardcoded in navigation, footers, sitemaps and scripts.

6. Update your sitemap and robots.txt

Publish a new XML sitemap listing the new URLs and make sure robots.txt on the new domain does not block crawling. Google says you can remove the old sitemap once the new one is submitted, but keeping it submitted is useful for monitoring, because the indexed count for the old URLs should fall as the count for the new URLs rises.

7. Tell Google with the Change of Address tool

Once your 301 redirects are live and tested, use the Change of Address tool in Google Search Console to tell Google the site has moved. The tool forwards ranking signals from the old domain to the new one and tells Google to prefer the new site. It runs a quick check for 301s on a few of your pages before it lets you confirm, which is exactly why the redirects have to exist first.

Two things to get right here:

• You must own both the old and new properties in Search Console, under the same Google account and the tool works on whole hosts only, so you can move example.com, www.example.com or m.example.com but not an individual path or subfolder.
• In a June 17, 2026 update to its site move documentation, Google added that when you move to a new domain, you should submit Change of Address requests for all verified variants of the old domain, including www, non-www and any subdomains, even ones you are not actively using, and that all of those variants need to be verified in Search Console first.

Note that the Change of Address tool does not replace your redirects. The tool announces the move. The redirects carry users and link equity. Submitting the tool before the redirects are live is a common and costly mistake and the tool's own pre-check is designed to catch it.

The tool is built for domain moves specifically. Google says you do not need it for a few adjacent jobs, including moving from HTTP to HTTPS, switching between www and non-www on the same domain or moving paths within the same domain. A host change where the URLs stay the same does not need it either.

8. Migrate email and update MX records

Move mailboxes to the new domain and update MX records so mail flows to the right place. Keep the old domain's email able to receive for a transition period so nothing sent to old addresses bounces. This is a separate job from the website move and it is easy to forget until someone's messages start disappearing.

9. Update external profiles, listings and backlinks you can edit

Your redirects protect links you cannot change. For links you can change, update them at the source. Social profiles, Google Business Profile and other listings, directory entries, ad account destination URLs and email signatures. For your most valuable backlinks, it is worth asking the linking site to update the URL directly rather than relying on the redirect forever.

10. Monitor rankings, traffic, crawl errors and redirect health

After the switch, monitor Search Console for crawl errors and coverage issues, monitor your analytics for traffic patterns, and recheck your redirects using a redirect checker to confirm none are broken or chained. Add a GA4 annotation on the launch date, or across the settling window, so you can line the traffic dip and recovery up against the exact timing of the move. Compare against the baseline so you can tell normal settling from a real problem.

Redirect your old domain URLs

Redirects are the part of a domain change that people underestimate, so it is worth slowing down here.

Use 301, not 302.

A 301 is a permanent redirect and tells search engines the move is permanent, so ranking signals should flow to the new URL. A 302 signals a temporary move and holds those signals back. For a domain change, you almost always want 301s.

Redirect page to page, not everything to the homepage.

This is the classic mistake and it is rarely made out of ignorance. It happens because the URL map got left until launch week and blanket-redirecting everything to the homepage was the only way to hit the date. The result is the same either way: pointing every old URL at the homepage tells search engines those pages no longer have equivalents and their rankings evaporate.

Each old URL should land on its true match, an old blog post to the same blog post on the new domain, not the homepage. This is the whole reason the URL map is the first thing on the pre-change checklist. Build it early and this mistake never comes up.

Use pattern rules where the structure is identical.

If your URL structure is carrying across unchanged, you can often redirect whole sections with a single rule rather than listing thousands of URLs by hand. Wildcard and path-based rules handle this. See our guide to wildcard redirects for how those work. Where the structure differs even slightly, fall back to explicit page-by-page rules so nothing lands in the wrong place.

Keep the redirects live for at least a year.

Google recommends keeping 301 redirects in place for at least a year and longer if the old URLs are still getting traffic. Google's reasoning is that the year gives it time to transfer all signals to the new URLs, including recrawling and reassigning links on other sites, so removing the redirects early strands anything that has not transferred yet.

This is the part that scales badly by hand.

A small site might have a few dozen redirects. A real business site can have thousands, spread across sections, some needing exact matches and some needing pattern rules, all of which have to stay live and correct for a year or more.

Managing that in server config files or one-off rules is where migrations quietly break, months later, when a rule gets dropped in an unrelated change.

A managed redirect platform like urllo exists for exactly this: holding a large set of redirects in one place, keeping them live and monitored and letting non-developers change them without a deploy. Whether you use a platform or not, the requirement is the same. Every old URL keeps redirecting to its match for as long as it matters.

A real consolidation: Ding

Ding, the world's largest provider of international mobile top-ups, ran exactly this kind of move.

The company had built up a set of smaller country and market-specific websites and subdomains and wanted them consolidated under the main Ding brand. That meant multiple lists of 301 permanent redirects, mapped page by page, with input needed from the SEO, IT and web development teams at the same time.

The goals were the ones the checklist above is built around: a smooth transition for users, link equity maintained and Google rankings kept.

Ding's SEO Specialist, Mary Plunkett, put the coordination problem plainly:

"Using urllo made this process so much faster and more simple and gave everyone involved in the projects visibility on our redirections."

Protecting your rankings during the move

A domain change will usually cause a temporary dip in rankings and traffic while search engines process the move, followed by recovery as signals transfer. A clean migration, with page-level 301s live and the Change of Address tool submitted correctly, recovers the large majority of rankings. Typical recovery runs a few weeks to several months depending on the size of the site and how much else changed at the same time.

That is the summary. The full playbook for preserving rankings through a move, including what to watch and how to diagnose a recovery that stalls, is its own topic. For that, read our detailed guide on how website migration affects SEO.

Common mistakes to avoid

• Redirecting all old pages to the homepage. Kills the rankings of every page that had them. Redirect page to page.
• Using 302 instead of 301. A temporary redirect tells Google to keep the old URL as the canonical, so the new URL does not take its place in search results.
• Submitting the Change of Address tool before redirects are live. The tool checks for redirects and the move fails or misfires without them.
• Removing redirects too early. Keep them at least a year.
• Forgetting email. Website and email move separately. Plan both.
• Letting the old domain expire. Keep paying for it for at least a year so it cannot be bought out from under you.

What to expect after the change

Expect a dip before a recovery. In the first days and weeks, Search Console may show a rise in crawl activity on the new domain and old URLs still appearing while Google works through them. Traffic often dips as rankings settle, then rebuilds as signals transfer. Watch three things: crawl and coverage errors in Search Console, the organic traffic trend against your baseline and the health of your redirects. Gaps that are still there after six months usually trace back to content, backlinks or a technical error, not to the decision to move.

Frequently asked questions about renaming your website

Will I lose my Google rankings if I change my domain name?

Not if the move is done correctly. Page-level 301 redirects pass ranking signals to the new URLs and the Change of Address tool tells Google to prefer the new domain. Expect a temporary dip while Google processes the move, then recovery. Most rankings return on a clean migration.

How long does it take to change a domain name?

The technical work can be done in a day or two for a small site. Recovery in search is the longer part, typically a few weeks to several months. Google's Change of Address tool forwards signals for 180 days after you start the move, while the redirects themselves should stay live for at least a year.

Can I change my domain name without losing traffic?

Largely, yes. The traffic you protect is the traffic covered by redirects and by updating references you control. The traffic at risk is anything pointing at an old URL with no redirect. A complete URL map and page-level 301s are what keep the loss temporary and small.

Do I need to keep the old domain after moving?

Yes, for a while. Google recommends keeping the old domain registered for at least a year so the redirects keep working and nobody else can buy it. Many businesses keep the old domain indefinitely for that reason.

Does changing a domain name affect my email?

Yes. Email on the old domain stops working unless you migrate mailboxes and update MX records for the new domain. Treat email as a separate move from the website and keep the old domain able to receive mail through the transition.

What is the difference between changing a domain and forwarding a domain?

Changing a domain moves your whole site to a new address and requires redirects, a Search Console update and the full process above. Forwarding a domain keeps your site where it is and simply points another domain at it, which is a registrar setting. If forwarding is what you actually need, see our domain forwarding guide and the GoDaddy domain forwarding walkthrough.

By Sean Pasemko

SEO & Growth Marketing Specialist

Sean Pasemko is an SEO and growth marketer at urllo, where he works closely with SEO, IT and WebOps teams on redirect management, domain changes and site migrations.

His writing draws on practical experience analyzing redirect behavior, crawl efficiency and long-term site maintenance to help teams avoid common routing and performance issues.