# Changing your domain without losing search traffic

You can move to a new domain and keep your search traffic. You need a complete redirect map, verified properties, the Change of Address tool, and tidy signals. This guide gives you the steps and the timeline.

Updated 2026-09-14 · Source: https://porteur.ai/guides/domain-change-seo

## What success looks like after a domain change

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.

## Build the redirect map

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. **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. **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. **Export the sitemap** Add every URL in sitemap.xml and any sitemap index files. You want full coverage.
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. **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. **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.

```js
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
}

```

> Never redirect old pages to the home page. That pattern looks like a soft 404 to Google.

## Verify both properties in Search Console

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.

> www and non www are different hosts. Pick one, 301 the other on every path, set canonicals to the chosen host, and verify a Domain property to cover both.

## Use the Change of Address tool

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. **Meet the requirements** Both properties verified. 301s in place for all pages. The new domain is live with the same content.
2. **Open Settings on the old domain property** Choose Change of address. Select the new domain property from the list.
3. **Run the pre checks** The tool checks sample redirects and verification. Fix any issues it flags.
4. **Submit and monitor** Submit the request. Watch the Pages and Performance reports on both properties over the next weeks.

> This tool does not replace 301s. You still need the full redirect map live before you submit.

## Update signals everywhere

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.

## Next.js specifics, if you use it

- 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.

## Update links you control and your listings

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.

## Launch plan: a week by week timeline

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. **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. **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. **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. **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. **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. **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. **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.

> Move one thing at a time. Do not change the domain, the URLs and the design in one release if you can avoid it.

## Testing the redirects at scale

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

```bash
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.

## How long to keep the old domain and redirects

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.

## Common traps that cost traffic

- 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.

## Questions

### Does changing a domain affect SEO?

Yes, temporarily. A clean one to one 301 map, the Change of Address tool, and consistent signals will help rankings settle within weeks. Expect volatility but not a cliff if you keep redirects for at least a year and avoid multiple changes at once.

### Do I need the Change of Address tool if I have 301s?

Use both. 301s are mandatory and handle users and crawlers. The Change of Address tool confirms the domain level move to Google and can speed consolidation. It does not work for path only changes or HTTPS only moves.

### How long should I keep the old domain?

Keep it and the redirects for as long as you can, at least a year. People and crawlers follow old links for a long time. Letting the old domain expire early will cause 404s and lost signals.

### Can I change domain, redesign and restructure at once?

You can, but you should not. If traffic drops, you will not know which change caused it. Move the domain first, then adjust structure or design after traffic stabilises.

### What if some pages are retired during the move?

If a page has a true replacement, 301 it to that page. If it has no replacement, you can return 410 Gone. Avoid mass 301s to the home page. Keep removals small during the move to reduce noise.

### Do I need to fix www and trailing slash during the move?

Yes. Choose your www host and trailing slash form, and redirect the other version with a 301 on every path. Set canonicals to the chosen forms and keep links consistent. This prevents duplicate URLs from splitting signals.

## Read next

- [Website migration SEO checklist: before, during, after](https://porteur.ai/guides/website-migration-seo-checklist): Run a safe website migration: crawl and export, build and test one-to-one redirects, switch cleanly, submit sitemaps, use Search Console, and watch the data.
- [Build a redirect map: one old URL, one new URL, tested](https://porteur.ai/guides/redirect-map): A practical redirect map: where to find old URLs, how to match them, store the table, apply 301s, and test every row for one hop and a 200.
- [How to use Google Search Console in ten minutes a week](https://porteur.ai/guides/how-to-use-google-search-console): A quick weekly routine: set four filters, compare 28 days, check pages then queries, and fix three findings, without getting lost in noise.
- [The Sitemaps report: what Success, Has errors and Couldn’t fetch mean](https://porteur.ai/guides/search-console-sitemaps-report): How to submit your sitemap URL, read Success, Has errors and Couldn’t fetch, and fix invalid XML, 404s, cross‑host URLs and missing child sitemaps.
- [Canonical tags: what they do and the mistakes that cost rankings](https://porteur.ai/guides/canonical-tag): What a canonical tag does, when to use one, the mistakes that cost rankings, and how to check and fix canonicals on a small site.
- [www or non-www: pick one, redirect the other](https://porteur.ai/guides/www-vs-non-www): Pick www or non-www, there is no SEO gain either way. 301 redirect every path to the chosen host, set canonicals, and verify a Domain property.
- [A second product: same domain, subdomain, or a new site?](https://porteur.ai/guides/seo-for-a-second-product): The three ways to launch a second product in search, what each costs, when a separate domain is right, and how to structure one site that holds both.
- [SEO through a rebrand: the name, the domain, the pages](https://porteur.ai/guides/seo-for-a-rebrand): What a rebrand costs in search, the order to do it in, the brand pages to ship first, and how long the old name keeps sending people to you.

Run a free 30 second check of your current site to see three findings on risky pages and rival results before you move. Free check: https://porteur.ai/