How to Move a Website to a New Domain Without Losing SEO?

Changing your domain name is one of the riskiest things you can do to an established website. A rebrand, a merger, or finally getting the .com you always wanted are all good reasons to move, but every ranking, backlink, and bookmark you have built points at the old address. Handled carelessly, a domain change can wipe out months of organic traffic overnight. Handled properly, Google treats it as a well-understood site move and transfers your signals to the new domain, usually with only a temporary dip. This guide covers the full process: preparing a URL inventory, building a redirect map, implementing 301 redirects in Nginx and Apache, verifying every redirect with a script, using Google Search Console's Change of Address tool, and monitoring the results. If you are only switching hosts and keeping the same domain, that is a different job; see how to plan a zero-downtime DNS migration instead.

How Search Engines Handle a Domain Move

When Googlebot requests a URL on your old domain and receives a permanent redirect (HTTP 301 or 308) to a URL on the new domain, it treats that as a strong signal that the new URL should replace the old one in its index. Google's documentation on site moves states that permanent server-side redirects are the preferred way to tell Google about a move, and that ranking signals are passed through them.

Three things determine how smoothly that goes:

• One-to-one mapping: every old URL redirects to its closest equivalent on the new domain, not to the homepage.
• Consistency: canonical tags, internal links, sitemaps, and structured data on the new site all point to the new URLs.
• Time: Google has to recrawl the old URLs to discover the redirects. For a small site this can take days; for large sites it can take weeks or months, and Google's own guidance warns that rankings may fluctuate during that period.

The less you change at the same time, the easier the move is to diagnose. If possible, move the domain first and leave redesigns, URL restructuring, and CMS changes for a separate project.

Step 1: Prepare Before You Touch Anything

Inventory Every URL

You cannot redirect what you do not know about. Build a list of old URLs from several sources, because each one misses something:

• Your XML sitemap(s)
• A full crawl with a tool such as Screaming Frog or Sitebulb
• Google Search Console's Pages report and Performance report (pages with impressions)
• Your analytics landing-page report for the last 12 months
• Backlink tools or the Search Console Links report (pages other sites link to)
• Server access logs, which also reveal old URLs that still receive traffic

A quick way to pull every URL from a sitemap on the command line:

curl -s https://oldsite.com/sitemap.xml \
  | grep -oE '<loc>[^<]+</loc>' \
  | sed -E 's#</?loc>##g' \
  | sort -u > old-urls.txt

wc -l old-urls.txt

If your sitemap is an index file pointing to child sitemaps, run the same command against each child.

Record Benchmarks

Export current performance so you can measure the impact later: clicks and impressions per page from Search Console, organic sessions from analytics, rankings for your priority keywords, and the number of indexed pages. Our guide on how to audit website SEO is a good checklist for capturing a baseline.

Check the New Domain's History

If the new domain was registered before, it may carry baggage: spam backlinks, a manual action, or a reputation as a parked or expired domain. Look it up in the Wayback Machine and check its backlinks before committing. Our guide on how to check a domain's history walks through this.

Set Up and Verify the New Domain

Before launch day:

1. Configure DNS for the new domain and issue its TLS certificate.
2. Verify both domains in Google Search Console. A Domain property (verified with a DNS TXT record) covers all protocols and subdomains, which is ideal here. See how to verify domain ownership with a TXT record.
3. Deploy the site on the new domain, but block it from indexing until launch, for example with HTTP authentication on a staging copy. Avoid noindex tags or robots.txt blocks that you might forget to remove.
4. Lower the DNS TTL on the old domain a day or two ahead if you will be changing where it points.

Step 2: Build the Redirect Map

A redirect map is a spreadsheet with two columns: the old URL and its new URL. For a pure domain change where paths stay identical, the map is a single pattern rule. For anything more, list each change explicitly.

old_url,new_url
https://oldsite.com/,https://newsite.com/
https://oldsite.com/about-us/,https://newsite.com/about/
https://oldsite.com/services/web-design/,https://newsite.com/web-design/
https://oldsite.com/blog/2024/05/domain-tips/,https://newsite.com/blog/domain-tips/
https://oldsite.com/contact/,https://newsite.com/contact/

Guidelines for the map:

• Redirect to the most relevant equivalent. Mass-redirecting old pages to the new homepage is likely to be treated as a soft 404, and those pages lose their value.
• Avoid chains. If an old URL already redirected somewhere else on the old site, point it straight to the final new URL.
• Keep paths identical where you can. A domain-only change is the safest migration of all.
• Include non-HTML assets that receive links: PDFs, images, and downloadable files.
• Decide what is genuinely gone. Content you are retiring with no equivalent can return 404 or 410, which is better than a misleading redirect.

Step 3: Implement 301 Redirects

Redirects must be server-side and permanent. JavaScript or meta refresh redirects are weaker signals and should only be used when you cannot control the server. Keep the old domain's server running only to serve redirects; do not leave the old site live alongside the new one.

Nginx Redirect Map

Nginx's map directive is the cleanest way to handle hundreds or thousands of explicit mappings. Place the map in the http context (for example in /etc/nginx/conf.d/redirect-map.conf) and the server block for the old domain alongside it:

# Explicit old-path to new-path mappings (matched against the path only)
map $uri $new_path {
    default                     "";
    /about-us/                  /about/;
    /services/web-design/       /web-design/;
    /old-pricing.html           /pricing/;
}

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name oldsite.com www.oldsite.com;

    # Keep a valid certificate on the old domain, or HTTPS visitors
    # and crawlers will hit an error before seeing the redirect.
    ssl_certificate     /etc/letsencrypt/live/oldsite.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/oldsite.com/privkey.pem;

    # 1. Explicit mappings from the map above
    if ($new_path) {
        return 301 https://newsite.com$new_path$is_args$args;
    }

    # 2. Pattern rule: /blog/YYYY/MM/slug/ becomes /blog/slug/
    location ~ ^/blog/\d{4}/\d{2}/(?<slug>[^/]+)/?$ {
        return 301 https://newsite.com/blog/$slug/$is_args$args;
    }

    # 3. Everything else keeps the same path on the new domain
    location / {
        return 301 https://newsite.com$request_uri;
    }
}

A few details matter here. $uri excludes the query string, so the map matches clean paths, and $is_args$args reattaches any query string. $request_uri in the fallback already includes the query string. If you load a very large map and Nginx complains on startup, increase map_hash_bucket_size or map_hash_max_size in the http block. Test and reload with:

sudo nginx -t && sudo systemctl reload nginx

Apache .htaccess Redirects

On Apache or LiteSpeed hosting, put the rules in the old domain's .htaccess file (or, better for performance, in the virtual host configuration):

RewriteEngine On

# 1. Explicit mappings (most specific first)
RewriteRule ^about-us/?$             https://newsite.com/about/        [R=301,L]
RewriteRule ^services/web-design/?$  https://newsite.com/web-design/   [R=301,L]
RewriteRule ^old-pricing\.html$      https://newsite.com/pricing/      [R=301,L]

# 2. Pattern rule: /blog/YYYY/MM/slug/ becomes /blog/slug/
RewriteRule ^blog/[0-9]{4}/[0-9]{2}/([^/]+)/?$ https://newsite.com/blog/$1/ [R=301,L]

# 3. Everything else keeps the same path on the new domain
RewriteCond %{HTTP_HOST} ^(www\.)?oldsite\.com$ [NC]
RewriteRule ^(.*)$ https://newsite.com/$1 [R=301,L]

In .htaccess context the leading slash is stripped from the path before matching, which is why the patterns start with ^about-us rather than ^/about-us. When the substitution URL has no query string of its own, Apache appends the original query string automatically. On WordPress, place these rules above the # BEGIN WordPress block. For plugin-based approaches, see how to set up 301 redirects in WordPress.

Redirects on Platforms Without Server Access

If the old domain lives at a registrar with no hosting, you can still forward it with the registrar's URL forwarding feature, provided it issues a 301 and preserves the path. Many basic forwarding services send every URL to the new homepage, which is not good enough for SEO. Check with curl before relying on it. The trade-offs are explained in how to redirect a domain using DNS records.

Step 4: Verify Every Redirect With a Script

Spot-checking a handful of URLs in a browser is not enough. Browsers cache 301s aggressively, hide the hop count, and you will never click through thousands of URLs. A quick manual check with curl shows the status and target of a single URL:

curl -sI https://oldsite.com/about-us/ | grep -iE '^(HTTP|location)'
# HTTP/2 301
# location: https://newsite.com/about/

For the full map, use a script that reads your CSV and checks that each old URL returns a single 301 hop to exactly the expected URL, which then responds with 200. This Python script needs only the requests library (pip install requests):

#!/usr/bin/env python3
"""Verify a redirect map. Usage: python3 check_redirects.py redirects.csv"""
import csv
import sys

import requests

TIMEOUT = 20


def check(old_url, expected_url):
    problems = []
    resp = requests.get(old_url, allow_redirects=True, timeout=TIMEOUT)
    hops = resp.history

    if not hops:
        problems.append(f"no redirect (status {resp.status_code})")
    else:
        if hops[0].status_code not in (301, 308):
            problems.append(f"first hop is {hops[0].status_code}, not permanent")
        if len(hops) > 1:
            chain = " > ".join(h.url for h in hops)
            problems.append(f"{len(hops)}-hop chain: {chain}")
    if resp.url != expected_url:
        problems.append(f"ends at {resp.url}")
    if resp.status_code != 200:
        problems.append(f"final status {resp.status_code}")
    return problems


def main(path):
    total = failures = 0
    with open(path, newline="", encoding="utf-8") as f:
        for row in csv.DictReader(f):
            old, new = row["old_url"].strip(), row["new_url"].strip()
            total += 1
            try:
                problems = check(old, new)
            except requests.RequestException as exc:
                problems = [f"request failed: {exc}"]
            if problems:
                failures += 1
                print(f"FAIL {old}\n     expected {new}\n     " + "; ".join(problems))
            else:
                print(f"OK   {old}")
    print(f"\nChecked {total} URLs, {failures} failure(s)")
    return 1 if failures else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1] if len(sys.argv) > 1 else "redirects.csv"))

Run it before launch against a staging copy of the redirect server (by temporarily pointing the old hostname to it in your /etc/hosts file), and again immediately after launch. It exits with a non-zero status when anything fails, so you can drop it into a CI job or a cron task. If you prefer pure shell, curl -s -o /dev/null -w '%{http_code} %{redirect_url}' URL returns the same first-hop information in one line.

Step 5: Launch and Update Everything on the New Site

On launch day, enable the redirects and remove any access restrictions on the new site, then work through this list:

• Internal links: search and replace the old domain in content, menus, templates, and the database. Internal links should never rely on redirects.
• Canonical tags: every page on the new site should have a self-referencing canonical with the new domain.
• hreflang annotations, Open Graph URLs, and structured data such as Organization and WebSite markup.
• XML sitemap: publish a sitemap of new URLs and submit it in the new Search Console property. Google also suggests that temporarily submitting a sitemap of the old URLs can help it discover the redirects sooner.
• robots.txt: the old domain must not block crawling. If Googlebot cannot fetch the old URLs, it never sees the redirects.
• Analytics, ads, and tag manager: update the domain in analytics data streams, ad destination URLs, conversion tracking, and any cross-domain settings.
• Third-party services: payment gateways, OAuth callback URLs, email sending domains (SPF, DKIM, DMARC), CDN settings, and API allow-lists.

Step 6: Use Google Search Console's Change of Address Tool

The Change of Address tool tells Google directly that your site has moved from one domain to another. Google says it helps prioritize crawling of the new site and forward signals from the old one; Google's help documentation states that it forwards signals for 180 days. It does not replace redirects; it works alongside them.

To use it:

1. Make sure the 301 redirects are live and the old homepage redirects to the new homepage.
2. Open the old domain's property in Search Console.
3. Go to Settings, then Change of address.
4. Select the new domain's property from the list. You must be a verified owner of both properties.
5. Run the validation checks. Search Console tests the homepage redirect and a sample of important pages, and reports problems such as missing redirects or pages that return 404.
6. Submit the request.

Key limits to keep in mind:

• It is for domain or subdomain moves only, for example oldsite.com to newsite.com, or blog.example.com to example.com.
• It is not for HTTP to HTTPS migrations, www to non-www changes, or moving paths within the same domain.
• Use it on the property for the root of the old site, not on a sub-path.

Bing Webmaster Tools offers a similar Site Move tool. Verify the new domain there too and submit the move.

Step 7: Monitor and Maintain

Expect some ranking and traffic fluctuation in the first weeks. What you are watching for is a steady transfer, not a flat line.

What to monitor	Where	What good looks like
Indexed pages on the new domain	Search Console Pages report (new)	Rising steadily toward the old total
Indexed pages on the old domain	Search Console Pages report (old)	Falling, with "Page with redirect" growing
Crawl errors and 404s	Search Console, server logs	No spike in 404s for URLs that had traffic
Clicks and impressions	Search Console Performance (both)	Old declining as new rises, combined total recovering
Redirect health	Your redirect checker script	Zero failures on every run
Organic sessions and conversions	Analytics	Recovering to baseline over the following weeks

Then follow through on the long tail:

• Keep redirects in place for as long as possible. Google recommends at least one year, and in practice there is little reason to ever remove them, since external links and bookmarks keep sending visitors.
• Keep the old domain registered and on auto-renew. If it lapses, someone else can register it, inherit its backlinks, and capture your old traffic. Lock it at the registrar too.
• Ask for link updates from your most valuable referring sites. Redirects pass signals, but a direct link to the new domain removes a dependency.
• Update business listings and profiles: Google Business Profile, social profiles, directories, and email signatures.

Common Mistakes That Cost Rankings

• Redirecting everything to the new homepage instead of mapping pages one to one.
• Using 302 (temporary) redirects and never switching them to 301.
• Letting the old domain's TLS certificate expire, so HTTPS requests fail before the redirect is served.
• Blocking the old domain in robots.txt, which hides the redirects from crawlers.
• Combining a domain change with a full redesign, new URL structure, and content pruning, making any drop impossible to diagnose.
• Forgetting non-www, www, HTTP, and HTTPS variants of the old domain. All four should redirect in a single hop.
• Dropping the old domain after a few months to save a renewal fee.

Domain Migration FAQ

Conclusion

Moving to a new domain without losing SEO is less about any single trick and more about thoroughness. Inventory every URL, map each one to its best equivalent, implement permanent server-side redirects in a single hop, and verify them with a script rather than by eye. Update everything on the new site to use the new domain, keep the old domain crawlable, and tell Google about the move with the Change of Address tool.

After launch, monitor both Search Console properties, fix redirect failures quickly, and resist the temptation to clean up too soon. Keep the old domain registered and its redirects running for the long term. Do all of that, and a domain change becomes a short, manageable dip on the way to a stronger brand rather than a lasting setback.

Here are some useful references for going deeper on domain migrations:

1. Google Search Central: Site moves with URL changes — Google's official step-by-step guide to moving a site.
2. Google Search Console Help: Change of Address tool — requirements, validation checks, and limits of the tool.
3. Google Search Central: Redirects and Google Search — how Google interprets permanent and temporary redirects.
4. Nginx: Module ngx_http_map_module — reference for the map directive and its hash size settings.
5. Apache HTTP Server: mod_rewrite reference — the full RewriteRule and RewriteCond documentation.