Changing your domain without losing search traffic

Success is simple: every old URL redirects once to its new twin, Google understands the move, and traffic returns after some weeks. Expect fluctuation. You avoid a cliff by keeping signals consistent and removing ambiguity.

• One to one 301s, never to the home page.
• Both domains verified in Search Console, domain properties preferred.
• Change of Address submitted for the domain level move.
• All internal links, canonicals, hreflang and structured data updated to the new host.
• Old sitemap kept for a while so Google crawls and sees the redirects.
• Redirects kept for at least a year, longer if you can.

The redirect map is the backbone. It is a two column table in your repo: old URL, new URL. Every old page has exactly one destination. No gaps, no many to one dumps.

1. 1

   Crawl the old site

   Use your crawler to export every indexable URL. Include query driven pages you serve, like /blog?page=2, if they are canonical.

2. 2

   Export known URLs from Search Console

   Pull Pages and Sitemaps URLs. Add any top pages from the Performance report. This catches unlinked and legacy paths.

3. 3

   Export the sitemap

   Add every URL in sitemap.xml and any sitemap index files. You want full coverage.

4. 4

   Decide the new twin for each URL

   Map one to one. If the path does not change, only the host changes, write it that way: http://old.com/guides to https://new.com/guides.

5. 5

   Apply redirects at the edge or server

   Use an nginx map, a CDN rule set, or next.config.js redirects. One hop only. No redirect chains.

6. 6

   Test every mapping

   Script requests to each old URL. Assert final status is 200 on the new URL and hop count is one. Fix any 404s or multi hop routes.

next.config.js

module.exports = {
  async redirects() {
    return [
      { source: '/guides/getting-started', destination: 'https://newdomain.com/guides/getting-started', permanent: true },
      { source: '/pricing', destination: 'https://newdomain.com/pricing', permanent: true }
    ]
  },
  trailingSlash: false
}

Verify the old and the new domains in the same Search Console account. Use Domain properties to cover all hosts, like www and non www, and both HTTP and HTTPS.

• Submit the current sitemap for the old domain.
• Prepare, but do not submit yet, the new sitemap on the new domain.
• Note top queries and pages so you can compare post move.
• Check Pages, Soft 404 and Not found reports for stray URLs to include in the map.

The Change of Address tool tells Google the whole site moved to a new domain. It only works for domain level moves, not just path changes or HTTPS only.

1. 1

   Meet the requirements

   Both properties verified. 301s in place for all pages. The new domain is live with the same content.

2. 2

   Open Settings on the old domain property

   Choose Change of address. Select the new domain property from the list.

3. 3

   Run the pre checks

   The tool checks sample redirects and verification. Fix any issues it flags.

4. 4

   Submit and monitor

   Submit the request. Watch the Pages and Performance reports on both properties over the next weeks.

Update every place that tells crawlers what the canonical URL is. Mixed signals slow consolidation and cost you clicks during the move.

• Internal links: make them absolute or root relative to the new host. No links pointing to the old domain.
• Canonical tags: point to the new URL on the new host. One canonical per page.
• Hreflang: all references must use the new host, including self references.
• Structured data: update sameAs, url, and any URL fields in JSON LD.
• Sitemaps: list the new URLs only on the new domain. Keep the old sitemap on the old domain for a while.
• Robots.txt: keep it simple. Do not block the old domain while redirects need crawling.
• Open Graph and Twitter tags: update og:url and similar to the new host.

Pick your trailing slash form. /page and /page/ are different URLs apart from the root. Redirect the one you do not use, and keep links consistent.

If you are also moving HTTP to HTTPS, treat that as a site move. 301 each HTTP URL to its HTTPS twin in one hop. Update canonicals, sitemaps, hreflang and links. Avoid mixed content. Verify the HTTPS property.

A fixed page on the new host uses a self canonical to the new URL, has only internal links to the new host, and returns 200 without redirects.

• Redirects: define permanent redirects in next.config.js. Keep one hop only.
• Trailing slash: set trailingSlash to true or false. Keep links consistent with it.
• Metadata API: set metadataBase and alternates.canonical per page. It will not pick for you.
• Sitemap and robots: add app/sitemap.ts and app/robots.ts with new host URLs.
• Fonts and images: next/font and next/image help with page speed but do not affect redirect logic.

Do not rely on the framework to set titles or canonicals. You must write them. The framework will not make a page worth indexing for you.

Tell people and systems about the new domain. It speeds up consolidation and reduces lost referral traffic during the move.

• Your product, blog and docs navs, footers and CTAs.
• Email templates and footers.
• Social bios and pinned posts.
• App store listings and marketplace profiles.
• Docs, SDK readmes and package descriptions.
• Partner links you can request edits for.
• Paid ads final URLs and tracking templates.
• Analytics, tag manager and pixels where domain is whitelisted.

1. 1

   Week −3

   Finish the redirect map draft. Crawl the old domain, export Search Console pages and sitemaps, and fill gaps. Decide www choice and trailing slash.

2. 2

   Week −2

   Implement redirects in a staging or rules file. Build the new sitemap. Update canonicals, hreflang and structured data on the new domain build. Verify both domains in Search Console.

3. 3

   Week −1

   Run full redirect tests from a URL list. Fix any chains and missing pages. Keep the old sitemap live. Prepare comms and update links you control to switch on launch day.

4. 4

   Launch day

   Deploy redirects live. Ship the new domain. Submit the new sitemap on the new property. Submit Change of Address from the old property. Spot check top pages and queries.

5. 5

   Week 1

   Monitor 404s and Soft 404s on both properties. Fix bad links and stray URLs. Update any missed internal links. Re test the redirect map. Keep the old sitemap listed.

6. 6

   Weeks 2 to 4

   Expect query volatility. Keep content and design steady. Answer partner edit requests. Track key pages in the Performance report on the new property.

7. 7

   Weeks 5 to 8

   Traffic should settle if signals are clean. Tidy any remaining duplicate host issues, like non www pages not redirecting. Check hreflang is consistent.

8. 8

   Months 3 to 12

   Keep redirects running. Renew the old domain and keep the DNS up so redirects keep working. Remove only truly dead content with 410 if you retire it.

Test the map with a script before and after launch. It prevents chain building and missed pages that drain signals and crawl budget.

bash

# urls.txt contains one old URL per line
while read -r url; do
  final=$(curl -sIL "$url" | awk '/^HTTP/{code=$2} END{print code}')
  hops=$(curl -sIL "$url" | grep -ci '^location:')
  if [ "$final" != "200" ] || [ "$hops" -ne 1 ]; then
    echo "Issue: $url -> status $final, hops $hops"
  fi
done < urls.txt

• Check that the final URL is the exact new URL you mapped.
• Ensure only one 301 hop. Fix 301 to 302 to 200 chains.
• Fix any 404 or 410 that should redirect.
• Retire defunct content only when you are sure it should not exist.

Keep redirects for as long as possible. At minimum, one year. Google’s guidance says keep them permanently when you can. Do not let the old domain expire while traffic still uses old links.

Keep DNS and TLS for the old host working so HTTPS redirects succeed. Keep the old sitemap listed for a while so Google recrawls and sees the 301s.

• Redirecting many pages to the new home page. This wastes page equity and triggers soft 404 patterns.
• Leaving internal links pointing to the old domain. You bleed link equity and add crawl hops.
• Submitting Change of Address without working 301s. The tool will not fix missing redirects.
• Moving domain, structure and design at once. You cannot diagnose the cause of a drop.
• Forgetting hreflang updates. Mixed hosts in tags break language pairs.
• Inconsistent www or trailing slash. Duplicates split signals.
• Chains and mixed content when also adding HTTPS. Fix in one hop and audit includes.