AI AI Tools Guidebook
Indie Dev & Website Building

Will Changing Domains Hurt SEO — and How to Soften the Hit

A domain change always costs some short-term ranking. Use this 301 redirect playbook, Search Console move steps, and verification commands.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

Renaming a site or migrating to a better TLD feels overdue — until you remember every backlink, every Google ranking, and every bookmark currently points at the old name. A domain change is doable, common, and survivable. But you must do the 301 redirects, Search Console move, and sitemap dance correctly. This is that dance, with the actual commands.

Background

Search engines associate authority with URLs. When oldsite.com/foo ranks well, that ranking is attached to that exact URL. A clean 301 redirect transfers the lion’s share of that authority to newsite.com/foo — usually 95%+ over a few weeks. A botched migration (no redirects, mismatched URLs, broken canonical, no Search Console move) leaves rankings stranded on a dead site.

How to tell

  • You are rebranding and the old domain no longer fits.
  • You are consolidating multiple domains into one.
  • You bought a better domain (e.g. moving from .co to .com).
  • You are splitting one site into two and need to reassign ranking signals.

Quick verdict

Do not change domains for vanity if rankings matter. If you must, do the full playbook: 301 every old URL to its new equivalent, update Search Console, resubmit sitemap, keep redirects forever. Skipping any of these steps is what causes rankings to drop and stay dropped.

Before you start

  • The new domain is registered, DNS-ready, and SSL provisioned before you change anything.
  • Both old and new domains are verified in Search Console (Domain property if possible).
  • You have a complete URL inventory — export the old sitemap and the Search Console “Pages” list.

Step by step

  1. Pick the new domain and have it ready. Provision SSL on the new domain first; do not switch DNS until curl -vI https://newdomain.com returns HTTP/2 and a valid cert.

  2. Map every old URL to a new URL. Export the old sitemap and build a CSV:

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

awk '{ sub(/oldsite\.com/, "newsite.com"); print $0 "," $0 }' old-urls.txt > url-map.csv
# manually adjust any URLs whose path is changing
  1. Configure 301 redirects from every old URL to the new equivalent. Wildcard the simple case, then patch exceptions. Firebase example on the old domain:
{
  "hosting": {
    "redirects": [
      { "source": "**", "destination": "https://newsite.com:dest", "type": 301 }
    ]
  }
}

Vercel vercel.json:

{
  "redirects": [
    { "source": "/(.*)", "destination": "https://newsite.com/$1", "permanent": true }
  ]
}

Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?oldsite\.com$ [NC]
RewriteRule ^(.*)$ https://newsite.com/$1 [R=301,L]

Nginx:

server {
  listen 443 ssl;
  server_name oldsite.com www.oldsite.com;
  return 301 https://newsite.com$request_uri;
}
  1. Verify a representative sample with curl:
while read url; do
  printf '%s -> ' "$url"
  curl -sI "$url" | awk 'tolower($1)=="location:"{print $2}'
done < <(shuf -n 20 old-urls.txt)
# every output should be the corresponding new URL, no chains

  1. In Google Search Console, add the new domain as a property and verify. Use Domain property + TXT record so SSL/HTTP/www variants are all covered.

  2. On the OLD property, use the “Change of address” tool. Settings → Change of address → Update site → pick the new property. Google waits for the tool to confirm 301s are live.

  3. Submit the new sitemap, resubmit the old one. Both via Search Console → Sitemaps. Update robots.txt on the new domain to reference the new sitemap:

# robots.txt on newsite.com
User-agent: *
Allow: /
Sitemap: https://newsite.com/sitemap-index.xml
  1. Update canonical tags on the new site to point at the new domain only. In your Astro layout:
<link rel="canonical" href={`https://newsite.com${Astro.url.pathname}`} />

Then grep the build output to confirm:

grep -ROIE 'rel="canonical"' dist | grep -v newsite.com
# any output is a leak that must be fixed

  1. Keep the OLD domain registered for at least 2 years and the redirects live forever. Set a calendar reminder for the renewal — losing the domain kills the transferred authority instantly.

  2. Monitor weekly. Expect a 4-8 week dip then recovery. Search Console → Performance → Compare to previous 90 days. Stop deploying new content for the first 2 weeks if possible so signal is clean.

Implementation checklist

  • 301 redirect rule covers ** and is verified by curl -I on at least 20 random URLs.
  • New canonical tags reference only the new domain — verified by grep against build output.
  • “Change of address” submitted in old Search Console property.
  • New sitemap submitted; old sitemap resubmitted to trigger recrawl.
  • Old domain has auto-renew enabled and is paid out at least 2 years.
  • DNS TTL on both domains was lowered to 300s 48 hours before the switch.

After-launch verification

  • Search Console URL Inspection on a sample of old URLs should show “Page with redirect”.
  • New-domain coverage should rise; old-domain coverage should fall in parallel — that is the migration working.
  • Compare clicks/impressions between old vs new property weekly; the sum should approach the pre-migration baseline within 8 weeks.

Common pitfalls

  • Forgetting 301s — without them every backlink hits a 404 and authority dissolves.
  • Using 302 (temporary) instead of 301 (permanent) — search engines treat them differently; 302 does not transfer authority. Detection: curl -I shows HTTP/2 302.
  • Restructuring URLs at the same time as moving domains — combining two big changes makes recovery messier and slower. Move first, restructure later.
  • Skipping “Change of address” in Search Console — Google figures it out eventually, but slower.
  • Letting the old domain expire — once a domain lapses, 301s die and recovered authority dies with them.
  • Forgetting to update canonical tags on the new site — og:url and <link rel="canonical"> both must point at the new domain.
  • Long redirect chains (old → intermediate → new). Always redirect once.

FAQ

  • How long does recovery take?: Most sites see 80% recovery in 4 weeks, full recovery in 8 to 12 weeks. Authority transfers but Google needs time to re-rank.
  • Do I lose backlinks?: You lose direct hits, but 301s preserve almost all the SEO value of those backlinks. The links still exist on the source sites; the redirects make them count.
  • Can I delete the old site after a year?: No. Keep the domain and redirects forever — or at least until you migrate every old URL away via Search Console verification of removal.
  • What about social media and email mentions?: Update what you can (profiles, bios). The rest is fine — links pointing at the old domain will 301 transparently.
  • Does HTTPS-to-HTTPS matter?: Yes. Redirect from https://oldsite.com to https://newsite.com directly, not via HTTP. Browsers will block mixed-protocol chains.

Tags: #Indie dev #Domain #SEO #Technical SEO

Related Articles