Site Migration: Moving to a New Domain

What Is a Domain Migration?

A domain migration changes the URLs of an existing site from one domain or hostname to another—for example, from old.example to new.example. The content and organization may remain largely the same, but users, crawlers, links, applications, and services must learn the new addresses.

A migration is not the same as transferring a domain registration between registrars. A registrar transfer changes administrative control while the public URLs can remain unchanged. A domain migration changes the URLs visitors and search systems use.

Google recommends changing one major thing at a time. Moving domains while simultaneously replacing the CMS, redesigning templates, rewriting content, changing navigation, and consolidating sections makes failures harder to isolate and increases the number of signals that must be processed.

No “zero SEO loss” promise is credible: Google expects temporary ranking fluctuation during significant moves. Careful execution reduces avoidable errors; it cannot guarantee identical rankings, traffic, or processing time.

Should You Move to a New Domain?

A domain move can be justified by a rebrand, merger, trademark issue, international strategy, security problem, acquisition, or a clearer long-term name. It should not be undertaken solely because another domain has a higher third-party authority score.

Before deciding, compare:

Brand, legal, and customer benefits
Quality and history of the destination domain
Current organic traffic, links, email, referrals, and offline uses
Engineering, content, support, and communication cost
Ability to keep the old domain and redirects operating long term
Risk of email interruption, impersonation, and customer confusion
Clean alternatives such as changing branding without changing URLs

Audit a previously registered destination through the complete domain-vetting process. Google specifically advises checking a recently purchased destination for previous manual actions and URL removals.

The Five Phases of a Safe Domain Migration

1. Inventory

Collect URLs, content, traffic, links, systems, DNS, email, owners, verification, and business dependencies.

Output: Baseline and complete migration scope.

2. Mapping

Assign every old URL and asset a valid new equivalent, consolidation target, or honest removal status.

Output: Version-controlled URL decision file.

3. Build and test

Prepare the new site, redirects, canonicals, internal links, sitemaps, analytics, security, DNS, and monitoring outside production.

Output: Signed-off release candidate.

4. Launch

Publish the new site, activate direct permanent redirects, validate critical journeys, and submit search signals.

Output: Working old-to-new transition.

5. Monitor

Track errors, logs, indexing, traffic, conversions, mail, external links, and support issues on both domains.

Output: Resolved defects and documented completion.

Build a Complete Pre-Migration Inventory

Start from several sources because no single list is complete:

Current XML and media sitemaps
CMS and database URL exports
Internal crawl results
Server and CDN logs
Analytics landing pages and conversions
Search Console pages, queries, links, and indexing data
Backlink-provider target URL exports
Image, video, PDF, JavaScript, CSS, feed, and API endpoints
Paid campaigns, email templates, QR codes, apps, integrations, and offline materials

Save a baseline with date and timezone: status codes, canonical, robots directives, title, primary heading, word count, structured data, hreflang, internal links, organic clicks and impressions, sessions, conversions, and important backlinks. The baseline tells you whether the new result changed unexpectedly.

How Should You Map Old URLs?

Create one row per old URL and include old status, historical purpose, traffic, links, new URL, decision, redirect type, owner, test result, and notes.

Equivalent page exists

Map old product, article, category, or asset to its genuine equivalent on the new domain.

Response: Direct 301 or 308 to the final new URL.

Several pages consolidated

Map them to one new page only when that page substantively covers the former content and satisfies users.

Response: Individual permanent redirects to the relevant consolidation target.

Content intentionally removed

No relevant successor exists and the user should not be sent elsewhere.

Response: 404 or 410 with a useful site experience.

Unsafe or legally restricted history

Old content is hacked, deceptive, infringes rights, or should not transfer.

Response: Do not redirect solely to capture signals; document legal and security decisions.

Google warns against sending many old URLs to one irrelevant destination such as the new homepage because this can confuse users and may be treated as a soft 404. Use the detailed URL-mapping workflow.

Prepare the New Domain and Site

Before launch:

Confirm ownership, registration term, recovery contacts, MFA, registrar lock, and auto-renew.
Audit historical use, DNS, links, security warnings, blocklists, trademarks, manual actions, and URL removals.
Issue and test TLS certificates for required hostnames.
Replicate or deliberately update content, images, downloads, metadata, structured data, and accessibility.
Use new-domain URLs in internal links, canonical tags, hreflang, feeds, manifests, Open Graph, and structured data.
Prepare production robots rules and remove development noindex directives.
Create sitemaps containing only canonical new URLs that return 200.
Verify all relevant old and new Search Console properties.
Configure analytics to preserve continuity while allowing old-versus-new comparison.
Load-test the new site and redirect infrastructure for increased crawler traffic.

Test the new site without exposing an indexable duplicate. Authentication or restricted network access is safer during development than relying only on robots.txt. Blocking crawling does not reliably prevent URL indexing, and a leftover production block can derail launch.

How Should Redirects Be Implemented?

Prefer server-side permanent redirects using 301 or 308 for a permanent domain move. Point each old URL directly to the final destination. Google supports multiple redirect types but recommends permanent server-side redirects where possible.

Test all variants:

HTTP and HTTPS
www and non-www
Uppercase, trailing slash, and parameter behavior where relevant
International, mobile, and legacy hostnames
Images, PDFs, feeds, downloads, and other linked assets

Avoid chains such as old HTTP → old HTTPS → new HTTP → new HTTPS. Send the first request to the final canonical URL. Check for loops, mixed protocols, lost query parameters, malformed encoding, and redirects that return 200 error pages.

Our 301 versus 302 guide explains redirect semantics and testing.

Plan DNS, Email, and Service Continuity

A website move is also an operational change. Inventory DNS records and lower TTLs ahead of launch only where useful. Preserve mail flow on the old domain and configure SPF, DKIM, DMARC, MX, and sending systems for the new domain deliberately.

Update and test:

Transactional and support email
Identity providers, OAuth callbacks, SSO, and password resets
Payment providers, webhooks, APIs, and CORS policies
CDNs, WAFs, DNSSEC, monitoring, and certificate automation
Cookie scope, consent, analytics, tag managers, and affiliate tracking
Apps, feeds, marketplaces, advertising accounts, and social profiles

Keep the old domain’s email and security posture controlled. Abandoning it can expose staff and customers to impersonation or missed communications.

Launch-Day Sequence

Freeze unrelated releases and take tested backups.
Confirm monitoring, staffing, escalation contacts, and rollback criteria.
Publish the new site and confirm critical new URLs return 200.
Activate old-to-new redirects.
Run automated tests across the complete mapping and manual tests for high-value journeys.
Confirm canonicals, robots, hreflang, structured data, internal links, sitemaps, and analytics use new URLs.
Submit the new sitemap in Search Console.
Use Search Console’s Change of Address tool when applicable to the domain move; it is not used for HTTP-to-HTTPS-only moves.
Request inspection for a representative set of important pages rather than attempting to submit every URL manually.
Communicate the change to users, staff, partners, and support teams.

DNS rollback alone may not reverse a migration cleanly after crawlers and users have seen redirects. Define rollback behavior for the application, redirects, database writes, email, and user sessions before launch.

What Should You Monitor After Launch?

Monitor both domains and segment reports by old and new URLs:

HTTP status, redirect destination, latency, and loops
Server and CDN errors, resource saturation, and crawler activity
Search Console indexing, canonicals, sitemaps, manual actions, security issues, clicks, and impressions
Analytics sessions, landing pages, channels, engagement, and conversions
Rankings and third-party estimates as supporting—not primary—evidence
Broken internal and external links
Email authentication, delivery failures, and customer replies
Paid campaigns, feeds, apps, integrations, and support incidents

Compare like dates and account for seasonality. Temporary movement is expected while old and new URLs are crawled and processed. Investigate patterns: a drop confined to one directory, device, country, or template often points to an implementation problem.

A Migration Diagnostic Order

Availability: Are DNS, TLS, server, CDN, and origin reliable?
Redirects: Does every important old URL reach one relevant final destination?
Indexability: Are new pages crawlable, 200, canonical to themselves, and free from accidental noindex?
Content parity: Did important text, media, structured data, and functionality transfer?
Discovery: Are internal links and sitemaps using new URLs?
Signals: Are hreflang, canonicals, links, feeds, and Change of Address aligned?
Measurement: Did analytics or consent configuration change?
External factors: Did demand, competition, security, or ranking systems change at the same time?

Fix verified defects before making broad content changes. Otherwise the diagnosis becomes another uncontrolled migration.

How Long Should You Keep the Old Domain and Redirects?

Google advises keeping redirects in place generally for at least one year, and from a user and security perspective it is often wise to retain the old domain and redirects much longer. Links, bookmarks, emails, documents, apps, and printed materials can continue sending people for years.

Keep renewing and securing the old domain. Monitor certificates, DNS, mail, abuse reports, and redirect availability. If redirects are eventually retired, base the decision on remaining requests, links, user risk, contractual obligations, and brand security—not an arbitrary calendar date.

Should External Links Be Updated?

Redirects handle old links, but update high-value links you control: profiles, major partners, advertising, directories, apps, documentation, and email templates. For editorial backlinks, contact a limited set of important publishers with a concise correction only when the new page is genuinely equivalent.

Do not run a mass outreach campaign demanding every link update. Preserve redirects regardless; many publishers will not change historical content.

Common Domain Migration Mistakes

Changing domain, CMS, design, content, and architecture at once
Failing to audit a previously owned destination domain
Building the URL inventory from the sitemap alone
Redirecting every old URL to the new homepage
Creating chains, loops, temporary redirects, or irrelevant targets
Leaving development noindex or crawl blocks in production
Keeping old-domain URLs in canonicals, hreflang, internal links, or sitemaps
Forgetting images, PDFs, feeds, APIs, email, and third-party integrations
Monitoring only rankings instead of indexing, traffic, conversions, logs, and user journeys
Dropping the old domain and redirects too soon

Primary Sources

Bottom line: Inventory before changing anything, map every old URL to a relevant outcome, test the new property and infrastructure, launch direct permanent redirects, align all internal and search signals, and monitor both domains long enough to find page-level defects and protect users.