Changing a domain name is never only a change of signage. Customers, old links, saved documents and search engines all have to find their way back to the content that still matters. A rebrand, a merger or a reorganisation can justify the work. The hope that a different name will lift your rankings on its own does not.
A prepared migration removes avoidable mistakes. It does not guarantee steady traffic: Google still has to discover and process the new addresses. What you can control is narrower — working paths, consistent content, and enough measurement to explain what happens after the switch.
What actually changes during a migration
Three operations are often confused. A domain change replaces the public address of the site. A registrar transfer moves the registration to another provider without changing that address. A hosting move relocates the files and the database. They often happen together, but the risks and the procedures differ.
During a domain change, pages, images and documents can all receive new URLs, while inbound links, bookmarks, campaigns and email signatures keep pointing at the old site. Start from those real uses: pages that generate enquiries, documents sent to clients, products still being ordered, articles people have read for years.
The "domain authority" scores produced by SEO tools are not a balance of points administered by Google. Treat any promise to transfer 95% of your authority, or to recover fully in eight weeks, as marketing rather than method. Google's guidance is more modest: a site move can cause temporary fluctuations, and how quickly things settle depends on the size of the site and on crawling. See the Google documentation on site moves with URL changes.
Build the URL mapping before you touch the site
Write a table that pairs every old URL with its intended destination. Combine inventories: a crawl of the site, the sitemaps, the pages Search Console knows, your analytics entries and any inbound link data. None is complete alone. An orphan page can still receive traffic long after it left the menus, which is why a technical audit belongs before the mapping.
| Situation | Decision to document | Check |
|---|---|---|
| Same content, same path | Redirect to that path on the new domain | Destination relevant and publicly reachable |
| Page renamed | Explicit mapping to its new URL | No unnecessary intermediate hop |
| Several pages merged | Redirect to the page that carries their information | The old needs are still covered |
| Content removed with no equivalent | A considered 404 or 410 response | No misleading redirect to the home page |
| PDF or image still in use | Keep access, or redirect the file itself | Complete file, correct content type |
Give every important row an owner. Note why a destination was chosen, then keep a dated version of the table. That document is what you use to configure the migration, test it and fix an omission once the site is live.
Choose a permanent redirect and test it properly
An HTTP 301 or 308 response says the move is permanent. Google treats those as stronger signals than a temporary 302 or 307. That does not mean a 302 destroys your search history; the problem is a signal that contradicts a change made for good. A canonical tag is not a substitute: a visitor typing the old address still has to arrive somewhere. Google's page on redirects and Search sets out the distinctions.
The rule has to run wherever the request for the old domain lands: the server, a proxy, a redirection service, or the old application. A plugin installed only on the new site cannot intercept a request that never reaches that hosting. Check the HTTPS certificate on the old domain too — a failing TLS handshake stops the visitor before the redirect is served.
An Apache example when the paths stay the same
On Apache hosting that allows these rules in an .htaccess file, the principle can be written like this. The domains below are placeholders, not a configuration that suits every site:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.example$ [NC]
RewriteRule ^ https://new-domain.example%{REQUEST_URI} [R=301,L,NE]This keeps the requested path; query parameters belong in the test plan too. Encoded characters in historic addresses, separate applications behind the same name, or a proxy will need adjustment. Where paths change, put the specific mappings before the general rule. The Apache documentation on redirecting and remapping explains where mod_rewrite belongs.
A registrar's forwarding service can be enough if it returns a permanent status code, preserves the paths and supports HTTPS; a "masked" or framed forward is not a migration. Verify the HTTP response and the final address, not the look of the page.
Keep control of the domain, the access and the DNS
The domain should sit in an account the organisation controls, with usable recovery contacts and responsibilities written down. Check who receives renewal notices, who may change the DNS and who holds the codes. Turn on the registrar lock and arrange a fallback access, rather than relying on one person's inbox.
Authorisation codes, locks and waiting periods depend on the extension and the situation. For the domains it covers, the ICANN transfer policy sets out restrictions attached to certain recent events, such as a change of registrant. The blanket claim that "any change means a 60-day wait" is too general to plan around. Have the conditions that apply to your domain confirmed first.
Moving the registration elsewhere does not automatically move the mailboxes, the website or every associated service. So export the DNS zone and identify what each record is for: the website, the mail service, subdomains, verification records for third-party tools. A site can answer perfectly while email quietly stops arriving. Treat send-and-receive testing as separate work, and do not cancel the old hosting until you know what it still provides.
Preparing the switch: content, technical work and rollback
Pick a window that suits the business: a quiet period only helps if somebody is free to watch the launch. Preparation time depends on volume and dependencies; there is no universal migration slot.
- Backups: files, database, configuration and DNS records, with a rollback you have confirmed is possible.
- Working copy: protect its access and stop unintended outbound actions — duplicate emails, payments, scheduled jobs.
- Journeys: test forms, booking, checkout, downloads and mobile display with recognisable test data.
- Internal addresses: menus, in-content links, canonicals, language versions and sitemaps on the final domain.
- Measurement: the events you rely on, the consent flow and the conversion destinations, without multiplying tags.
- Dependencies: licences, callbacks, APIs and tools authorised for one specific domain.
Avoid stacking a domain change, a new structure, a CMS replacement and a content rewrite on the same day. If several projects are necessary, separate their steps and their evidence of validation, as a planned redesign sequence does. When something breaks, you will know which change caused it.
Switch day: verify before you announce
Deploy the final destinations, confirm they are publicly reachable, then enable the redirect plan. Test a representative sample plus every commercially important URL: variants with and without www, HTTP and HTTPS, deep pages, renamed URLs and files. Record the initial status code, each hop and the final destination.
Check that temporary protections were removed from the public site only. A page can return 200 and still carry a noindex tag or a canonical pointing at the staging copy. The opposite mistake is as common: do not block crawling of the old URLs, because that is where Google has to discover the redirects.
For an eligible domain change, use the Search Console Change of Address tool once both properties are verified. It checks some prerequisites; it does not replace the redirects, and it is not meant for an HTTP to HTTPS move or a directory move. Submit the new sitemap, then update campaigns, profiles and documents.
Monitoring the move without confusing incident and fluctuation
Keep a baseline from before the change: clicks and impressions by page group, enquiries, sales where relevant, technical errors. Then read the two domains together. A fall on the old domain alone is expected and says nothing about total performance. Allow for seasonality and campaign changes.
In the first days, watch server errors, redirect behaviour and the commercial journeys. Then follow the new URLs discovered, the pages retained in the index and the queries that matter. A loss concentrated in one directory calls for an investigation of that directory; publishing more articles at random is not a remedy. If the cause proves to be a traffic distribution problem, the fix differs again.
Keep the redirects for a long time. Google's site move documentation generally recommends at least a year, and longer often remains useful to visitors and old links. Plan the renewal of the old domain accordingly, and keep asking the owners of important links to update them.
The final validation is a matter of facts: useful old entry points still work, new pages are reachable, enquiries arrive, measurement is coherent, someone owns the follow-up. No recovery percentage and no timetable for rankings can be promised from a technical plan.
Common questions
Do I need to change registrar in order to change domain name?
No. Changing the public address and moving the registration to another provider are separate operations. You can register the new domain with your current provider or elsewhere. Check the DNS, the hosting and the email configuration separately.
How long should I keep the old domain?
At least as long as the redirects need to live. Google's migration guidance generally points to a minimum of a year, and keeping them longer often helps old links and existing customers. Diarise the renewal and re-check that the redirects still respond, HTTPS included.
Can I redirect every old page to the new home page?
Only where it genuinely answers the need the old page served, which is rarely true. Map each piece of content to a relevant equivalent. Something removed with no equivalent can keep a 404 or 410 response rather than a misleading redirect.
Does a well-prepared migration guarantee that I keep my rankings?
No. Preparation removes avoidable errors, but the search engine still has to process the new URLs and competitors keep moving meanwhile. Monitor access to the pages and the conversions, and read both domains together instead of expecting a stated recovery figure.
Does changing the domain also change our email addresses?
Not automatically. The website and the mail service depend on different records. If the addresses change too, plan the mailboxes, the forwarding, the authentication records and the send-and-receive tests before giving up the old service.