AI AI Tools Guidebook
Indie Dev & Website Building

Will Changing Domains Hurt SEO? 301 Redirect Migration Playbook

A domain change costs short-term ranking but is recoverable. Use this 301 redirect playbook, Search Console Change of Address steps, and verification commands.

Published: Updated: 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 recoverable, but it is not free. An Ahrefs analysis of migrations in 2025 found roughly 60% saw measurable organic traffic loss, almost always from skipped or broken redirects rather than the move itself. Do the 301 redirects, the Search Console Change of Address, and the sitemap resubmit correctly and you keep the rankings. This is that procedure, with the actual commands.

TL;DR

  • A permanent 301 (or 308) redirect from every old URL to its exact new equivalent passes ranking signals; Google states permanent redirects do not cause a loss in PageRank.
  • File a Change of Address in Search Console for domain-to-domain moves: it forwards site-level signals for 180 days (as of June 2026). It complements, not replaces, the 301s.
  • Keep the redirects live for at least 1 year (Google’s stated minimum) and the old domain registered indefinitely — the day either lapses, transferred authority dies.
  • Expect a temporary fluctuation; Google’s John Mueller has put settling at 4 to 12 weeks depending on site size. Move the domain first, restructure URLs later.

Background

Search engines associate authority with URLs. When oldsite.com/foo ranks well, that ranking is attached to that exact URL. A permanent 301 redirect passes that authority to newsite.com/foo; Google’s own documentation states that 301 and 308 permanent redirects “don’t cause a loss in PageRank.” A botched migration (no redirects, mismatched URLs, broken canonical, no Search Console Change of Address) leaves rankings stranded on a dead site, which is exactly how that 60% loses traffic.

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": "/:rest*", "destination": "https://newsite.com/:rest*", "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 a Domain property + DNS TXT record so HTTPS/HTTP/www/non-www variants are all covered by one property.

  2. On the OLD property, use the “Change of address” tool. Settings → Change of address → pick the verified new property. Google then prioritizes crawling and indexing the new site and forwards site-level signals for 180 days (per Search Console Help, as of June 2026). The tool checks that your 301s are live before it lets you submit, so configure redirects in step 3 first.

  3. Submit the new sitemap, resubmit the old one. Both via Search Console → Sitemaps. Resubmitting the old sitemap triggers Google to recrawl the old URLs and see the redirects sooner. 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 redirects live for at least 1 year and the OLD domain registered indefinitely. Google’s site-move guidance says keep redirects “at least 1 year”; from a user perspective, keep them forever. Set auto-renew plus a calendar reminder for the old domain — the day it lapses, the 301s die and the transferred authority dies with them.

  2. Monitor crawl health daily for the first two weeks, then weekly. Watch Search Console → Pages (Indexing) and Crawl Stats for 404s and redirect errors; the first 48 hours catch the worst mistakes. Compare Performance vs the previous period. Avoid deploying other big changes during the move so Google has one clean signal to process.

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 (it confirms 301s are live first).
  • New sitemap submitted; old sitemap resubmitted to trigger recrawl.
  • Old domain has auto-renew enabled and a calendar reminder set — keep it registered indefinitely.
  • DNS TTL on both domains was lowered to 300s about 48 hours before the switch.
  • Internal links rewritten at the source to the new URLs, not left to the 301 to fix.

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. This is the single most common cause of the ~60% that lose traffic.
  • Using a 302 (temporary) instead of a 301 (permanent) — use a permanent redirect (301 or 308). Detect a mistake with curl -I, which shows HTTP/2 302 instead of 301.
  • 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; the tool’s 180-day signal forwarding speeds it up.
  • Letting the old domain expire — once a domain lapses, 301s die and recovered authority dies with them. Keep it indefinitely.
  • Forgetting to update canonical tags on the new site — og:url and rel="canonical" both must point at the new domain.
  • Long redirect chains (old then intermediate then new). Googlebot follows up to 10 hops, but each hop slows reindexing — always redirect to the final URL in one hop.
  • Relying on the 301 for internal links — rewrite internal links on the new site to the new URLs directly; chained internal redirects waste crawl budget.

FAQ

  • How long does recovery take?: Plan for a 4-to-12-week settling period; Google’s John Mueller has cited that range, scaling with site size. Small sites with clean 301s often stabilize in 2 to 4 weeks. There is normal week-to-week fluctuation while Google recrawls the old URLs.
  • Do I lose backlinks?: No. The links still live on the source sites, and a 301 passes their value to the new URL. Google states permanent redirects do not cost PageRank, so the redirects make those backlinks count for the new domain.
  • Can I delete the old site after a year?: Keep the domain and 301s indefinitely. Google’s stated minimum is 1 year, but there is no penalty for leaving them forever, and any backlink or bookmark you cannot control still routes through them.
  • Does the Change of Address tool replace 301 redirects?: No — they do different jobs. The 301s handle page-level authority and user navigation; the Change of Address tool signals the site-level move and forwards signals for 180 days. Use both.
  • Does HTTPS-to-HTTPS matter?: Yes. Redirect from https://oldsite.com to https://newsite.com directly, not via HTTP. Browsers block mixed-protocol chains and each extra hop slows reindexing.

Authoritative references

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

Related Articles

Indie Dev & Website Building

Root vs www is cosmetic until both serve the same content and split your SEO. Use this verified DNS table (Vercel, Firebase, Cloudflare), redirect config, and curl checks to lock it down in one pass.

#Indie dev #Domain