Changing a domain changes the addresses visitors and search engines know. Bookmarks, external links and crawled pages still point to the old location. Make an explicit decision for every old URL before switching.
Use the English URL-plan worksheet. It contains blank result fields and an explicitly fictional example, not evidence of an executed move. This guide covers address changes; a hosting-only migration is a different task.
Inventory old URLs from several sources
Combine the CMS, sitemap, server logs, analytics, Search Console and known external links. Include linked PDFs, images and other relevant resources. No single list is necessarily complete.
Deduplicate the inventory while noting current responses, parameters and meaningful path variations. Do not assume a redirect for the homepage covers changed paths or downloaded files.
Decide equivalent, merged or removed
| Decision | Appropriate response |
|---|---|
| Equivalent | Redirect directly to the exact corresponding new page |
| Merged | Redirect to a page that genuinely answers the old question |
| Removed | Return an appropriate not-found or gone response if no relevant replacement exists |
Resolve rows marked “review needed” before the switch. Sending every removed page to the homepage can fail to serve its original question and may be treated as a soft error by search systems.
Configure and check direct redirects
For moved URLs, use a permanent redirect such as 301 or 308 to the final intended address. Test the response and endpoint for each row. A loop, unexpected destination or avoidable intermediate redirect fails the check.
Coordinate domain-wide rules for unchanged paths with explicit mappings for changed ones. Include the relevant HTTP/HTTPS and www variations and preserve parameters where they determine content. Keep redirects for at least a year in line with Google's move guidance; retaining useful redirects longer may be appropriate.
Update the new site's annotations and links
Check self-referencing canonicals, internal links, language counterparts, structured data, feeds and intended indexing controls. The new sitemap should contain intended canonical, indexable URLs that load successfully. Submit and monitor it through the relevant search tools.
Update external places you control, including profiles, signatures and advertisements. Domain migration does not automatically update these touchpoints.
Worked example: a fictional 220-URL shop
Suppose 180 product paths remain unchanged. Of 25 articles, 17 remain separate and eight are merged into three new guides. Fifteen expired campaigns have no relevant replacement.
The map contains 197 one-to-one equivalents, eight merge mappings and fifteen deliberate removals. The resulting site has 200 relevant canonical pages in this simplified example. A merged article that takes an extra redirect hop remains an open correction until the mapping is direct.
These are illustrative numbers, not an OmniTechs customer migration or predicted search result.
Monitor the move without promising traffic retention
Verify the new search property and retain access to the old one. Google's Change of Address tool applies to supported domain or subdomain moves after redirects are prepared; it is not the tool for a path-only change.
Follow crawling and indexing observations, redirect errors, missing pages, traffic by destination and key form or checkout tasks. Assign one owner to the URL map, test results and go/no-go decision. Do not cancel the old domain while its required redirect function is still needed.
Correct mapping problems before assuming a ranking change has another cause. A technically sound move can still involve temporary or lasting traffic changes; this plan cannot guarantee retained positions.
Separate the move from content restructuring
If page questions are also changing, assess search intent before merging or removing content. For a new site, use website development. For an evidence-led review of the inventory and search implications, see SEO services.