Changing domains without losing search engine ranking is a planning objective, not a guarantee. The way to reduce risk is to maintain the relationship between content, redirect each URL to the appropriate destination, and check site signals before and after the change.
An old website address can still reach your customers through search engines, emails, and saved links long after the rebranding. Migration work involves managing these customer journeys and ensuring that each person receives a relevant response.
A new domain affects more than just the homepage: links, images, emails, analytics, integrations, and external profiles may all depend on the old one. It's best to treat it as a project with its own inventory and assigned owners, even if the design remains the same.
Difference between domain change, hosting, and structure
Changing your domain means the main website address changes. Changing your hosting provider can keep all URLs the same. Modifying the domain structure alters paths within a domain. You can do several things at once, but each change increases the amount of validation you need to do.
If the sole reason is to improve hosting, consider keeping the domain and paths. If you need a new brand, try not to combine the migration with a mass deletion of content. The more elements that change, the harder it will be to explain a performance variation.
1. Build the URL inventory before the move
Combine sitemap paths, site crawl data, pages with clicks in Search Console, and URLs used in campaigns or marketing materials. The menu doesn't necessarily contain everything that matters. Add documents and resources that receive links.
It also saves titles, directives, canonical tags, and referral metrics. It defines which URLs are kept, which have an equivalent, and which are removed. For a page that disappears, don't force a redirect to a destination that doesn't fulfill the same need.
2. Prepare a correspondence map
| Source URL, example | Destiny or decision | Validation |
|---|---|---|
| previous-domain.example/service/ | new-domain.example/service/ | Same service and accessible content. |
| previous-domain.example/blog/guide/ | new-domain.example/blog/guide/ | Full article and resources. |
| A removed page with no equivalent | Documented decision; possible 404 or 410. | Do not send to the default homepage. |
| A historical URL that already redirected | Relevant final destination. | Avoid unnecessary chains. |
The domains in the example are for illustrative purposes. In your file, use full URLs and add expected status, responsible party, and test result. Keep one row per legacy URL: a rule of thumb can help, but it doesn't replace checking for exceptions.
3. Validate the destination before making it public
Verify that the new domain has a valid certificate and serves the correct content. Review navigation, forms, purchase information (if applicable), media, and legal pages. Identify any protections in the sandbox environment and remove them at the appropriate time without first exposing an indexable copy.
Verify that canonical tags, internal links, and the sitemap point to the final URLs. If languages are involved, check their relationships as well. Look for references to the old domain in templates, buttons, scripts, and documents that users can download.
4. Implement and test the redirects
For a permanent migration, set up permanent server-side redirects according to the platform. Each old URL should redirect to its equivalent with the shortest reasonable path. Google recommends maintaining redirects for at least a year; you should keep them longer if users or links continue to use the old domain.
Distinguish between redirection and pointing to the preferred URL: our canonical guide It explains the role and limitations of that label.
Test both popular pages and routes from different templates. Check HTTP and HTTPS, with and without www, and URLs that were already redirecting. Don't mistake a visual "page moved" message for a successful redirect.
Retain ownership and the necessary certificates for the old domain as long as it continues to process requests. If it expires or stops responding, redirects will no longer work. Also ensure that changing the website does not delete email records that need to be retained.
5. What to check when changing the domain in WordPress
Make a backup of your database and files. Check your WordPress address and site address, but don't limit the changes to just those two fields: content and plugins can store absolute URLs.
If you also rebuild the site, check the information architecture before changing routes that could be preserved.
If you're using URL replacement, run a simulation first and use tools that support serialized data. Check which tables belong to the site and avoid a global replacement without backups. Redirect rules should reside where the old domain is actually being served, even if WordPress is already running on the new one.
Next, check images, permalinks, forms, and scheduled tasks. Open the site without logging in to see what a visitor sees. An authenticated administrator can view content or bypass caches that affect real users.
6. Report the change and monitor both properties
Verify the necessary properties in Search Console and use the change of address tool when the move meets the requirements. Submit the sitemap for the new site and review the reports for both properties. A notification tool does not replace redirects or fix lost content.
Update company profiles, your own links, campaigns, and signatures that you control. Prioritize destinations with traffic or commercial value. If you're also changing emails, prepare a separate project for their accounts and deliverability.
Example map: what to do with pages that no longer fit
Imagine a company rebranding and taking the opportunity to reorganize three services into two. Simply copying the old paths using a general rule only solves part of the migration: one of the pages no longer has an exact equivalent. This exception requires an editorial decision before the server is configured.
Review what users were looking for on that page and what it offered. If the service is genuinely being integrated into a new page, that could be a relevant replacement. If it disappears and there's no substitute, sending visitors to any service creates a false expectation. Document the withdrawal and evaluate an appropriate absence response.
For a guide that retains its content, the destination should typically be the same guide under the new domain. For an established category, check if the selection and purchasing criteria are preserved. Equivalence is defined by the need addressed, not by whether both URLs contain a similar word.
Include a justification column on the map. «Same content,» «integrated service,» or «removed without replacement» allows for auditing decisions afterward. If someone asks about a route weeks later, the team will know what was agreed upon and won't have to improvise another rerouting.
How to test a redirect beyond the homepage
Choose a sample URL by route type and check the complete path. An old URL might correctly redirect to the new domain and then go through another redirect to reach the final version. The visual result might look normal, but the path reveals rules that should be simplified whenever possible.
Note the requested URL, the initial response, the intermediate steps, and the final destination. Then review the content of the destination. An expected response code doesn't compensate for a listing that displays a different product or a page that asks you to log in.
It includes addresses copied from real links and variations the site used. It also checks URLs with parameters important for business functions. It decides which ones should be kept and which ones can be discarded; a rule that removes everything after a question mark could break a legitimate function.
Finally, review internal links. Although redirects may still serve the old routes, the new website should link directly to their current destinations. This streamlining process improves navigation and reduces dependencies on the old domain within the site itself.
The domain is also connected to forms, payments, and tools
Make a list of services that recognize the domain: analytics, forms, CRM, payments, calendars, widgets, transactional emails, and login systems. Some require authorizing the new address or updating a return URL. The migration team should allocate time to check for these dependencies.
Test each route with a real-world use case. Send a test form and verify its receipt at the intended destination. If a purchase is made, use the supplier's established procedure for reviewing and confirming the return. Don't consider an integration complete just because the button keeps appearing.
In measurement, it distinguishes between configuration continuity and data continuity. Changing a visible address does not guarantee that labels, filters, or domain references will continue to correctly interpret traffic. Record the time of the change so that future reports have context.
Email deserves a separate review. If the brand also changes its addresses, decisions will need to be made regarding mailboxes, aliases, and communications. If email remains on the old domain, it retains the necessary records and services. A web project shouldn't accidentally shut down infrastructure that the team is still using.
How to prepare for the launch so everyone knows what to check
Divide the plan into preparation, cut-off, and follow-up. For each phase, write down the responsible party, the entry requirement, and the exit evidence. Preparation ends when the destination is ready and the map is approved; cut-off begins when there is an agreed-upon window and a recoverable copy.
On switch day, use a short checklist of critical checks: homepage, priority services, contacts, purchasing when applicable, legacy higher-value routes, and mobile access. Then expand to the full sample. This helps the team distinguish between a bottleneck that requires a complete shutdown and a minor issue that can be resolved without disrupting operations.
Define who has the ability to change DNS, redirects, and application settings. If those people won't be available, resolve the issue of authorized access first. Having a perfect list and relying on an inaccessible account during launch can prolong a preventable incident.
Maintain an incident log with the time, URL, symptom, and solution applied. While conversations help with coordination, they don't replace this log. An emergency fix that goes undocumented can later explain why two sections behave differently.
What can you promise and what do you need to observe
The team can commit to defined inventory, implementation, testing, and monitoring. Positions also depend on how signals are processed and a constantly evolving competitive environment. Separate these aspects when accepting the project.
First, verify that important pages exist and are being served correctly. Then, observe discovery, indexing, and performance by query families. Maintain the previous baseline and avoid comparing a week of high demand with a week of low activity without explaining the difference.
If you detect a concentrated loss, use the map to review that family before redoing the entire migration. There might be an unresolved exception, missing content, or an inconsistent signal. The value of prior work becomes apparent precisely when you need to diagnose quickly and recover a specific decision.
7. Define when to consider the project finished
The launch is complete when the site is up and running; the migration requires follow-up. Maintain a list of critical URLs and verify their response, content, and destination. Compare queries and pages between equivalent time periods, without adding properties in a way that duplicates records.
Document issues and fixes. If one section drops while another remains the same, analyze the affected section before changing the entire site. Avoid promising that the ranking will be identical the next day: Google may need time to process the migration, and results may fluctuate.
Before setting the change date, prepare your main URLs and their destinations. We can review the map and the launch plan with you.
Sources and documentation consulted
Documentation consulted on September 27, 2026.
Frequently asked questions about domain changes and SEO
Does changing your domain name always lead to a loss of SEO?
Not necessarily, but there may be fluctuations and implementation errors. The goal is to reduce risk and preserve useful signals, not to promise unchanging positions.
How long should I keep the previous domain?
Google recommends keeping redirects for at least a year. Keeping the domain longer can be beneficial if links and traffic to the old addresses continue.
Is it enough to simply change the address in WordPress?
No. You should also check saved references, content, redirects, certificates, links, and connected tools.
Can I change the design and domain at the same time?
You can do it, but it increases complexity and makes it harder to isolate problems. Separate changes when feasible and document the correspondences.
