Change your domain while minimising the impact on rankings

During the life of a project there may come a time when, because of a rebrand, a change of focus or any other reason, a decision is made to change the business name, which will also mean changing the domain in use.

The change requires coordinating the application, DNS, certificates and redirects. You will also want to keep the visibility and links associated with the previous domain.

To simplify, Google keeps an index storing all the pages of your website; each one is independent and may rank better or worse depending on the search terms. When you change domain, you want the rankings and relevance assigned to each of these URLs to be passed on to the corresponding content on the new domain.

This is done with permanent redirects (301). A permanent redirect is a way of telling the search engine that the content that used to be at dominio.com is now at nuevodominio.com, that the change is permanent and that the content therefore has a new permanent destination. Google processes this signal together with the rest of the site's information.

But, as mentioned, each page is independent, so what you really need is for the search engine or a visitor going to dominio.com/cualquiercosa to be redirected automatically to its equivalent on the new domain, nuevodominio.com/cualquiercosa.

If the structure stays identical, a wildcard rule can keep the paths without setting up each page separately. If it changes, you will need a map of equivalents.

A wildcard redirect is combined with the permanent redirect so that, whatever address is requested, it is always redirected to its counterpart on the new domain.

You can create this redirect easily from cPanel, in the Redirects section, filling in the form as follows:

• Type: Permanent (301)
• https?://(www.)?: Select the old domain
• /: Leave the field empty
• Redirects to: https://nuevodominio.com
• www. redirection: Redirect with or without www.
• Wild Card Redirect: ticked

This redirect keeps the path, but it is only correct if the new site's URL structure matches the old one. If paths or content change, prepare a URL-by-URL map and redirect each old address to the most relevant equivalent; do not send every page to the home page.

Before the change, test the new site and update internal links, canonical, sitemap, hreflang and resources that still point to the old domain. Afterwards, crawl both sites to detect chains, loops, 404s and incorrect redirects.

Add and verify both domains in Google Search Console, submit the new site's sitemap and use Change of Address on the old property when the migration is between whole domains or subdomains. This tool is not used for a change from HTTP to HTTPS only, from www to non-www, or for paths within the same domain.

Keep the redirects and control of the old domain for at least a year, and preferably indefinitely for URLs with links or traffic. Monitor indexing, performance and errors during the transition. A well-run migration minimises the impact, but no procedure can guarantee that there will be no temporary fluctuations in visibility.

Check the variants and measure the change

Test a sample of the home page, categories, articles and linked files, with HTTP/HTTPS and with/without www where those variants existed. The old domain's certificates must still be able to serve its HTTPS URLs before redirecting them.

Keep a baseline of queries, pages, clicks and conversions. After the change, review both domains and compare equivalent periods; an initial fluctuation does not on its own point to an error. Google's migration guide explains the monitoring and the signals you need to update.

If a page disappears with no relevant replacement, do not redirect it to unrelated content just to avoid a 404. First review its traffic, links and usefulness to decide whether to keep or recreate that content.