Domain migration is the process of moving a website from one domain name to another, transferring all content, functionality, and ideally all accumulated SEO equity and link juice from the old domain to the new one. A company rebranding from oldname.com to newname.com undergoes a domain migration. A business consolidating multiple acquired domains under one primary domain executes a domain migration. An organisation moving from a ccTLD to a gTLD: or from .com to a new TLD: performs a domain migration.

The word migration captures both what is happening and why it is challenging, content, users, search rankings, backlinks, and brand recognition all need to move together from the old domain to the new one. Unlike moving physical objects, which are simply absent from one place and present in another after the move, domain migration requires a transition period during which both the old and new domains must function simultaneously. The old domain must remain accessible and redirect visitors correctly while the new domain is established and the transition propagates across the internet.

Done correctly domain migration is a manageable process that preserves most of the accumulated value of the old domain. Done incorrectly it can cause dramatic traffic drops, loss of search rankings, broken links, confused visitors, and months of recovery work. The difference between a successful and unsuccessful migration almost always comes down to planning, redirect configuration, and monitoring.

Why domains are migrated

Domain migrations happen for several reasons, each with different urgency, scope, and technical requirements.

Rebranding: a company changes its name and needs its online presence to reflect the new identity. oldcompanyname.com becomes newcompanyname.com. This is the most common reason for domain migration and often the highest-stakes, the brand equity built under the old name must transfer correctly to the new domain while communicating the rebrand to existing customers, partners, and the market.

Mergers and acquisitions: when companies merge or one acquires another the combined entity typically consolidates under one primary domain. The acquired company’s domain migrates to the acquirer’s domain or to a new combined brand domain. Both domains may have significant accumulated SEO value and backlink profiles that need to be preserved through the migration.

TLD change: moving from one TLD to another while keeping the same or similar second-level domain. A company on brand.net acquiring brand.com and migrating the primary site to .com. A technology startup moving from brand.com to brand.io for industry positioning. A business adding a country-specific domain, moving the UK operation from brand.com/uk to brand.co.uk.

Platform or hosting migration with URL changes: moving from one CMS or hosting platform to another sometimes changes URL structures even when the domain itself stays the same. Technically this is a URL migration rather than a domain migration but the redirect management requirements are similar, old URLs must redirect to new URLs.

Consolidation of multiple domains: an organisation that has accumulated multiple active domains, through acquisitions, product lines, or historical decisions, consolidates content under a single primary domain. Each secondary domain migrates its content to the primary with appropriate redirects.

Security or reputation reasons: a domain that has been compromised, penalised by search engines, or associated with negative events may need to be abandoned in favour of a fresh domain. This is migration under duress, the goal is to preserve as much legitimate value as possible while distancing from the problematic domain.

The SEO stakes of domain migration

Domain migration is one of the highest-risk SEO operations a website can undergo. The accumulated authority, rankings, and traffic of the old domain are tied to those specific URLs, moving to a new domain is asking search engines to update years of accumulated signals overnight. Understanding the SEO stakes clarifies why careful planning and execution matter.

Link juice at risk: every backlink pointing to the old domain contributes to its authority and rankings. After migration those backlinks still point to the old domain. Permanent redirects transfer link juice from old URLs to new ones, but the transfer is not perfect. Each redirect hop loses a small amount of equity. Chains of redirects lose more. Pages redirected to irrelevant destinations on the new domain transfer less equity than pages redirected to equivalent content.

Rankings during transition: search engines need time to discover the new domain, crawl its content, process the redirect signals, and update their index. During this transition period rankings for the new domain are lower than they will eventually become, the domain is new and has not yet accumulated the signals that the old domain had. Temporary ranking drops during migration are normal. The question is how deep and how long.

Indexation timing: Googlebot and other crawlers need to discover the new domain, crawl all its pages, and index them before they can rank. Crawling and indexing a new domain takes time, days to weeks depending on crawl frequency, site size, and authority. During this period the new domain may be invisible in search results even for its own brand name.

Backlink profile inheritance: the old domain’s backlink profile cannot be directly transferred. Backlinks from external sites point to old URLs. Permanent redirects are the mechanism for capturing that value, but only for links the crawlers can follow and for as long as the redirects remain in place. Removing redirects prematurely cuts off the link equity flowing from the old domain.

Planning a domain migration

Thorough planning before executing a domain migration is the single most important factor in its success. Migrations that fail almost always fail due to insufficient planning, missing redirects, broken functionality, inadequate monitoring, or premature decommissioning of the old domain.

Audit the old domain completely: before making any changes create a complete inventory of the old domain. Crawl every URL using a site crawl tool. Export all pages from the CMS. Check server logs for URLs that have received traffic in the past 12 months. Pull a backlink report to identify which URLs have the most valuable inbound links. Export all current DNS records. Document every piece of functionality, forms, APIs, third-party integrations, and where they are hosted.

Map old URLs to new URLs: for every URL on the old domain determine the corresponding URL on the new domain. This is the redirect map, the document that drives the entire migration. For a simple domain change where only the domain changes and all paths remain the same the map is straightforward, olddomain.com/path maps to newdomain.com/path. For migrations that also change URL structure, new CMS, new navigation, new content organisation, each URL must be individually mapped to its most relevant equivalent.

Prioritise the redirect map by URL importance. URLs with significant backlinks, high traffic, or high rankings deserve individual mapping to their most relevant equivalent. Lower-traffic URLs can be mapped to the nearest parent page or caught by a fallback redirect to the homepage.

Prepare the new domain: the new domain must be fully ready before the migration executes. All content migrated. All functionality working. SSL certificates provisioned. DNS configured. Google Search Console property created for the new domain. XML sitemap prepared. The new domain should be completely functional and verified before the old domain begins redirecting to it.

Lower DNS TTL in advance: reduce the TTL on the old domain’s DNS records to 300 seconds or less at least 24 to 48 hours before the migration executes. Low TTL ensures that DNS changes during the migration propagate quickly, minimising the window during which some visitors are routed to old infrastructure. After the migration is stable the TTL can be raised again.

Prepare redirect infrastructure: configure redirect rules before the migration day. All rules should be tested in a staging environment. The redirect map should be imported as a bulk redirect set and verified. Every redirect in the map should be checked to confirm the destination returns 200 OK. Redirect chains, destinations that themselves redirect, should be identified and collapsed to direct rules.

Executing a domain migration

With planning complete the execution phase is about implementing changes in the correct sequence and monitoring closely for problems.

Sequence of changes: the order of migration steps matters. Making changes in the wrong sequence causes gaps where visitors encounter errors.

First verify the new domain is fully functional and indexed, or at least crawlable. Submit the new domain’s sitemap to Google Search Console. Allow time for initial crawling.

Second configure redirect rules from the old domain to the new domain, in the redirect management infrastructure, ready to activate.

Third update DNS records for the old domain to point to redirect infrastructure rather than the old web server. With low TTL in place this change propagates in minutes.

Fourth verify redirect infrastructure is receiving traffic from the old domain and firing rules correctly. Check server logs, analytics, and redirect management dashboards.

Fifth submit a change of address notification in Google Search Console, using the Change of Address tool to explicitly signal the domain migration to Google. This accelerates the indexation update.

Sixth monitor intensively, checking crawl errors, indexation status, ranking movements, and traffic levels across both domains.

Migration timing: execute migrations during low-traffic periods, nights and weekends when visitor volume is lower. Problems discovered during migration have less impact on fewer visitors. Avoid migrating immediately before major business events, product launches, marketing campaigns, peak shopping seasons, that depend on search traffic.

Rollback planning: have a clear rollback plan. If critical problems emerge during or immediately after migration the ability to revert DNS changes and redirect infrastructure quickly limits damage. With low TTL DNS changes the rollback can take effect within minutes. Without a clear rollback plan a migration that goes wrong may take hours or days to recover.

Redirect configuration for domain migration

The redirect configuration is the technical core of domain migration, the rules that connect every URL on the old domain to its equivalent on the new domain.

Complete coverage: every URL that has received traffic or has backlinks needs a redirect rule. The redirect map from the planning phase drives rule creation. Bulk import of redirect rules from a CSV file is the most efficient way to deploy hundreds or thousands of rules simultaneously.

Path-preserving redirects: for simple domain changes where URL paths remain the same a single wildcard redirect rule, olddomain.com/* → newdomain.com/*: handles the entire migration. The wildcard preserves the path, handling every URL with one rule. This is the cleanest migration redirect configuration.

Individual path mapping: for migrations that also change URL structure individual rules map specific old paths to specific new paths. olddomain.com/old-path → newdomain.com/new-path. The redirect map from the planning phase drives these individual rules. The most important pages, highest traffic, most backlinks, get precise individual rules. Less important pages are caught by section-level wildcard rules or the global fallback.

Fallback redirect: a global fallback rule catches any URL not matched by more specific rules, sending visitors to the new domain’s homepage rather than to a 404. During migration many edge-case URLs may not have been explicitly mapped. The fallback ensures no visitor hits a dead end, even if they are sent to the homepage rather than the most relevant page.

301 permanent redirects throughout: all migration redirects should use 301 permanent redirects. The migration is permanent, the old domain is being retired. 301s transfer SEO equity to the new domain. Using 302 temporary redirects by mistake means search engines keep indexing the old domain and SEO equity does not transfer.

HTTPS on the old domain: the old domain must have valid SSL certificates during the migration period. HTTPS visitors to the old domain must receive redirect responses, not certificate errors. Dedicated redirect management platforms provision SSL automatically for connected domains, ensuring HTTPS works throughout the migration.

Post-migration tasks

The work does not end when redirects are live. Post-migration monitoring and follow-up tasks determine whether the migration succeeds long-term.

Monitor crawl errors: Google Search Console reports crawl errors, URLs the crawler attempted to reach but found missing or broken. Post-migration crawl errors indicate redirect rules that are missing or broken. Address crawl errors quickly, adding missing rules or fixing broken ones, to ensure maximum link equity transfer.

Monitor indexation: track how quickly new domain URLs appear in search results. Indexation of new URLs typically takes days to weeks depending on crawl frequency. Slow indexation indicates the new domain needs more crawling, submitting the sitemap, ensuring internal linking is strong, and verifying no technical barriers are blocking crawling.

Monitor rankings and traffic: some ranking drop during migration is normal, temporary drops of 10 to 30 percent are common even for well-executed migrations. Monitor daily for the first few weeks. Significant drops that persist beyond two to four weeks suggest problems, missing redirects, indexation issues, or technical problems on the new domain.

Update internal links: after migration update all internal links throughout the new site to point directly to new domain URLs rather than going through redirects. Redirects on internal links add unnecessary latency and are a sign of incomplete migration work. Internal links should be clean direct links to canonical new domain URLs.

Notify key partners: reach out to high-value external sites that link to the old domain, asking them to update their links to point to the new domain directly. Updated external links eliminate reliance on redirects for link equity transfer and provide cleaner signals to search engines.

Maintain old domain redirects indefinitely: the most common post-migration mistake is decommissioning the old domain too soon. External sites take months or years to update their links. Some links, in PDFs, cached content, offline materials, may never be updated. Old backlinks continue passing equity through redirects for as long as the redirects are maintained. Maintain the old domain registration and redirect rules for at least two to three years after migration, longer for domains with significant backlink profiles.

Common domain migration mistakes

Missing redirects for important pages: the redirect map is incomplete and high-value pages on the old domain have no corresponding redirect rule. Backlinks to those pages hit 404 errors and pass no equity. Regular crawl error monitoring during migration identifies missing rules quickly.

Using 302 instead of 301: temporary redirects during a permanent migration. SEO equity does not transfer. Old domain stays indexed. Search engines do not update their index to the new domain. Always use 301 for domain migration redirects.

Redirect chains from old infrastructure: old server redirects compound with new redirect rules creating chains. Old server redirects from HTTP to HTTPS on the old domain combine with the migration redirect to create two-hop chains. Audit all redirect paths for chains before and after migration and collapse them to direct single-hop rules.

Decommissioning old domain too early: removing the old domain registration or redirect infrastructure before external sites have updated their links. Immediately loses all link equity from the old domain’s backlink profile. Keep redirects running for years.

Not updating Google Search Console: failing to use the Change of Address tool in Search Console delays Google’s recognition of the migration. Submit the change of address notification as soon as redirects are live.

Migrating without staging: executing the migration directly in production without testing in staging first. Problems discovered in production affect real visitors and real rankings. Stage the redirect configuration, test thoroughly, then execute in production with confidence.