How to change your domain name without losing SEO

To Google, a new domain is a new site until something says otherwise. Every url it has indexed, every link on another site and every bookmark points at the old domain. Three things carry that history across, and Google’s site move documentation is built around them:

• a permanent redirect from every old url to its equivalent on the new domain — the signal that does most of the work.
• the Change of Address tool, which tells Google about the move explicitly and makes it prefer the new domain.
• time and continuity: the old domain keeps answering with those redirects long enough for Google to recrawl everything and for the links pointing at it to keep working.

Moving hosts without changing any url is a different and simpler job — no redirects at all, just DNS, as Google’s hosting change guide describes. This page is about the case where the domain in the address bar changes.

• verify both domains in Search Console, including every variant — Google’s guide says to verify all variants of both sites. A Domain property verified by DNS covers http, https, www and other subdomains in one go.
• collect every old url. Crawl, sitemap, the Search Console pages export and the logs — not only to build the map, but to have a list to test against after the switch. The sources are described in finding orphan urls.
• export Search Console data for the old property — performance, links, page indexing — as a baseline to compare against.
• prepare the new site completely: every page, every image and pdf, https working, robots.txt allowing crawling. Google’s move guide also asks for urls of embedded content — images, videos, javascript and css — to be included in the plan.
• update everything that names the domain: internal links, self-referencing canonical tags, hreflang annotations, the sitemap, structured data, open graph urls.

If the paths stay the same, one rule on the old domain covers the whole site: take the requested path and query string and send it to the same address on the new domain. The usual forms:

apache (.htaccess or vhost) — RewriteEngine On, RewriteCond %{HTTP_HOST} ^(www\.)?old-brand\.com$ [NC], RewriteRule ^/?(.*)$ https://new-brand.com/$1 [R=301,L]

nginx — a server block for old-brand.com and www.old-brand.com with return 301 https://new-brand.com$request_uri;

registrar or cdn forwarding — works if it forwards with a 301 and keeps the path. Many simple “domain forwarding” options send everything to the homepage or use a 302 — test before relying on one.

Check that the rule catches every variant of the old domain — http://, https://, with and without www. — and lands on the final address in one step. http://www.old-brand.com/pricing should go straight to https://new-brand.com/pricing, not via https://www.old-brand.com/pricing first. Google’s guide asks for chains to be kept short, “ideally no more than 3 and fewer than 5”; one is better. The old domain still needs a valid TLS certificate, or https requests fail before any redirect can answer.

Use a server-side 301 or 308. Google’s redirect documentation treats a permanent redirect as a signal that the target should be canonical; a temporary one is not.

A rebrand rarely moves only the domain. The new site comes with a new navigation, renamed sections and merged pages, and then the catch-all rule above sends /leistungen/webdesign to new-brand.com/leistungen/webdesign — a 404. Now you need two layers on the old domain:

• specific rules for every path that changed, each pointing straight at its final url on the new domain;
• the catch-all rule after them, for every path that stayed the same.

Building the first layer is a redirect mapping job. In Silentfrog, enter the old domain as the old site and the new one — or its staging address — as the new site; both are crawled and every old url is matched (starting a run). Rows in the exact bucket kept their path and are covered by the catch-all. Everything else is the list of specific rules.

One thing to know about the downloads. The generic csv carries absolute urls on both sides — source_url on the old domain, target_url on the new — which is what rules on the old domain’s server need. The importer files (Webflow, Shopify, .htaccess and the rest) are path pairs for a redirect that stays on one host, and they leave out rows whose path did not change. For a domain move, write the targets with the new domain in front, or take them from the generic csv; the .htaccess and nginx guide shows the one-line conversions. The first 50 old pages are free.

Once the redirects are live, tell Google. The tool lives in the settings of the old domain’s Search Console property; you pick the new property, it runs pre-move checks, and you submit. What Google’s Change of Address help says about it:

The tool runs a few pre-move checks before it accepts the request. Critical failures block it, others show as warnings (how to use the tool). Because the tool does not carry subdomains along, a move from old-brand.com needs two requests at least: one from old-brand.com and one from www.old-brand.com, each to the new domain — Google asks for both variants even if one was only ever a redirect. If you moved other subdomains too — shop.old-brand.com to shop.new-brand.com — each needs its own request from its own property.

The redirects only work while the old domain resolves to a server that answers with them. Google’s move guide says to keep them “for as long as possible, generally at least 1 year”; the Change of Address help says at least 180 days, “longer if you still see any traffic to them from Google Search.” After the 180 days Google treats the two sites as unrelated, so whatever has not moved by then will not be moved by the tool.

In practice: renew the old domain for years, not months. Links on other sites, printed material, email signatures and old newsletters keep sending people there long after Google has finished. A lapsed domain can also be registered by someone else, along with every link that still points at it. And keep email on the old domain working, or forwarded, until nobody writes to it any more.

• request the full old url list and confirm every url answers 301 and lands on a 200 on the new domain in one hop.
• submit the new sitemap in the new property. Google's move guide suggests submitting the old urls' sitemap at first as well, so their redirects are seen; it can be removed later.
• watch both properties: indexed pages falling on the old one and rising on the new one, clicks moving across in the performance report.
• ask the sites with the most important links to update them, and change the domain in your own profiles, ads and listings.

Google’s move guide says that for a medium-sized site it can take a few weeks or more before the new urls are shown, longer for a large one, and that rankings may fluctuate in that period. The Search Console side of it is covered in Search Console for a site migration.

• Redirect every old url with a 301 to its equivalent on the new domain — never only the homepage.
• Cover http, https, www and non-www in one hop, with a valid certificate on the old domain.
• When paths change too: specific rules first, a catch-all for the rest.
• Use the Change of Address tool from the old property — once for the www and once for the non-www variant; it needs owner access to both sides and forwards signals for 180 days.
• Subdomains are not moved by the tool — each needs its own request.
• Keep the old domain and its redirects for at least a year; in practice, keep renewing it.