Domain migration indexing checklist

Why did your last domain move wipe out organic traffic for months while pages sat in an unindexed limbo? Because treating a site move as a routine DNS flip ignores how Googlebot actually reconciles architectural identity. If you are executing a site move, you need an airtight domain migration indexing checklist that forces search engines to crawl legacy paths, discover target destinations, and update the index without splitting your link signals.

When a migration goes wrong, it is rarely due to bad luck. It fails because someone left an old canonical tag in the header, killed the old hosting environment prematurely, or set up sweeping wildcard redirects that turned thousands of deep product pages into useless homepage visits. Google does not automatically trust your new brand name just because you changed the registrar. The search engine treats the destination as completely unproven until direct page-to-page equivalence is mathematically verified through redirect responses, sitemap signaling, and structural parity.

Let us walk through the exact technical mechanics required to migrate without losing your index footprint.

Pre-Migration Inventory and Signal Baselining

You cannot verify what you do not catalog. The single biggest mistake engineering teams make is treating the current site as a theoretical collection of clean database records instead of an organic, messy web of legacy URLs that search engines have crawled for a decade.

Start by running a full crawl using Screaming Frog or Sitebulb. Do not just crawl internal links from the homepage; export every live URL from your production database, pull every URL with at least one session from Google Analytics over the past twelve months, and dump every URL that received an impression in Google Search Console. Merge these lists, deduplicate them, and crawl the composite collection. This gives you your true historical footprint, catching orphaned landing pages, forgotten campaign assets, and legacy redirects that still direct traffic.

Composite URL List = Internal Crawl ∪ Database Dump ∪ GA Sessions (12mo) ∪ GSC Impressions (12mo)

Next, snapshot your critical performance metrics. Log your baseline crawl stats from GSC: average response time, pages crawled per day, and total crawl requests. You will need these baselines post-launch to evaluate whether Googlebot is stalling or hitting throttles.

Export your current backlink profile from Ahrefs or Semrush. Flag high-equity target URLs—the top five to ten percent of your content driving ninety percent of external referring domains. These specific URLs must receive precise, one-to-one redirect mapping. If an automated script defaults a backlink-heavy legacy URL to an irrelevant parent category, you destroy the equity that keeps your rankings intact.

Finally, document every external tracking integration, payment webhook, API endpoint, and third-party login system tied to the legacy domain. While these are not pure SEO assets, having a checkout funnel break at launch forces emergency code rollbacks that disrupt indexing pipelines mid-stream.

The Definitive Domain Migration Indexing Checklist

To keep your indexation healthy during a move, you have to coordinate actions across the old server, the new host, and Search Console. Run through these phases strictly in order.

1. Verify both domains in Google Search Console: Ensure both legacy and destination domains have Domain-level properties (DNS verification) set up. You will need administrative control over both to process the official change of address tool.
2. Freeze CMS content publishing: Implement a complete content freeze across your production environments at least seventy-two hours prior to cutover to prevent database discrepancies.
3. Map 1-to-1 redirect targets: Construct a granular mapping file covering every active, orphaned, and traffic-bearing legacy URL. Group by path architecture, ensuring exact semantic alignment between old and new targets.
4. Update hardcoded internal links on staging: Scan your new codebase for absolute URLs referencing the old host. Convert these to relative paths or rewrite them to explicitly target the new domain.
5. Adjust environment canonical tags: Confirm staging headers and page templates generate self-referential canonicals reflecting the new domain protocol and host string.
6. Deploy valid SSL certificates to both hosts: Ensure your source hosting platform retains an active SSL certificate. Browsers and Googlebot abort redirect lookups if the old URL triggers a protocol or certificate warning.
7. Deploy server-side 301 redirects: Implement rewrite maps at the edge (Cloudflare Workers, CloudFront) or web server level (Nginx, Apache). Test header responses explicitly using curl -IL.
8. Submit dual XML sitemaps: Push a legacy URL sitemap to the old GSC property and a clean target sitemap to the new GSC property.
9. Execute the GSC Change of Address tool: Submit the site move notification directly inside the legacy property settings dashboard.
10. Monitor indexing velocity and server logs: Track 301 consumption rates on the old host and 200-OK discovery crawls on the new host to catch stuck clusters.

Reviewing a comprehensive domain change indexing checklist alongside this workflow will help you isolate edge cases before DNS records are touched.

DNS Routing and Edge Redirect Architecture

The actual cutover comes down to DNS records and edge routing. When you change domains, your legacy web server cannot simply be decommissioned. It must stay alive, serving fast HTTP 301 status codes.

Where should redirects live? Handling redirects directly inside application code (like a PHP, Ruby, or Python controller) introduces avoidable latency and consumes origin resources. Under heavy migration re-indexing passes, Googlebot will hit your old domain with significant concurrency. If your origin application throttles or runs out of worker threads, Googlebot receives 503 Service Unavailable errors and pauses crawling, delaying the migration indefinitely.

Client Request -> DNS -> CDN / Edge (Evaluates 301 Map) -> Direct 301 Location Header
(Origin server is never touched for legacy URLs)

The correct strategy is executing redirects at the edge via a Content Delivery Network like Cloudflare, Fastly, or CloudFront. By handling rewrite maps at the edge, responses return within milliseconds without stressing your origin databases.

# Example Nginx server block for the legacy domain
server {
    listen 80;
    listen 443 ssl http2;
    server_name old-domain.com www.old-domain.com;

    ssl_certificate /etc/letsencrypt/live/old-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/old-domain.com/privkey.pem;

    # Point robots.txt to live config
    location = /robots.txt {
        root /var/www/legacy-redirects;
    }

    # Custom mapping include or explicit return
    location / {
        return 301 https://new-domain.com$request_uri;
    }
}

Keep your DNS TTL (Time to Live) values adjusted properly. Seven days prior to migration, lower TTL settings across all A, AAAA, and CNAME records on both domains to 300 seconds (5 minutes). This allows for rapid rollback if catastrophic application errors occur during deployment. Once stability is proven post-migration, restore standard TTL durations (such as 86400 seconds).

If your project also includes a security switch, review our notes on https migration indexing to verify your TLS negotiation doesn’t introduce handshake latency during high-volume recrawls.

Canonicalization, Host Directives, and Signal Synchronization

A domain migration is a battle for signal alignment. If your server sends a 301 redirect to page B, but the HTML on page B says canonical is page A, search bots enter an indeterminate state. They will slow down crawling, withhold indexation, or keep the old URLs visible in search results.

Every single indexable page on the new domain must feature an explicit, self-referential canonical tag using the new domain name and protocol:

<!-- Correct canonical implementation on the new domain -->
<link rel="canonical" href="https://new-domain.com/category/product-slug" />

A common disaster scenario occurs when dev teams copy the production database and staging environment over to the new domain without updating application environment variables. The new site loads fine, but its <head> elements output legacy canonical tags. In our experience auditing stalled migrations, this single misconfiguration accounts for a huge portion of indexation failures. Google honors the canonical, pauses migration processing, and leaves search queries pointed to the old domain which is redirecting, causing a complete collapse in visibility.

Pay close attention to host variations. If your legacy site operated on a non-www structure and your new domain uses www, you must normalize this immediately at the edge. Review our analysis on www vs non www indexing to ensure you are not chaining redirects unnecessarily.

Bad Chain:  http://old.com/page -> https://old.com/page -> https://new.com/page -> https://www.new.com/page
Good Route: http://old.com/page -> 301 -> https://www.new.com/page

Every single permutation of your old URL—HTTP, HTTPS, non-www, and www—must resolve directly to the destination URL in a single 301 hop. Redirect chains dilute PageRank transmission and blow through Googlebot’s per-crawl redirect depth thresholds.

Search Console Diagnostics and Crawl Budget Acceleration

Once redirects are verified, link the properties through official channels to explicitly tell Google that the entity has moved.

First, verify that both the old and new hosts exist as Domain Properties in Google Search Console. Navigate to the legacy property’s Settings menu, click Change of Address, and follow the validation steps. Google will run automated pre-flight checks: verifying that redirects are operational on the homepage and confirming verification statuses.

The secret to accelerating a migration lies in XML sitemap management across both consoles:

[Old GSC Property] <--- Submit legacy sitemap containing ALL old URLs (now returning 301)
                             │
                             ▼
                    Googlebot crawls old URLs
                             │
                             ▼
                    Discovers 301 Redirects
                             │
                             ▼
[New GSC Property] <--- Submit new sitemap containing ALL new URLs (returning 200 OK)
                             │
                             ▼
                    Validates canonical targets

Submit the legacy XML sitemap to the old property. Why? Because under normal conditions, Googlebot visits deep legacy pages infrequently based on historical PageRank calculations. By submitting an active sitemap of legacy URLs after deploying the redirects, you force Googlebot to pull those URLs into the high-priority crawl queue. It hits the URL, receives the 301 response, follows the destination header, and queues the target URL for immediate indexing.

Concurrently, submit the clean, canonical-only XML sitemap inside the new Search Console property. If your teams miss these steps, you will end up wondering why your domain change indexing is failing, watching crawl activity drag on for six months instead of resolving in three weeks.

Monitor the Crawl Stats report under Settings in both properties. You should observe a dramatic spike in legacy crawl requests, followed shortly by an exponential increase in target host discovery crawls. If legacy requests flatline while the Change of Address is active, check whether upstream firewalls (such as Cloudflare Super Bot Fight Mode or AWS WAF) are blocking Googlebot IPs.

Post-Cutover Audit: Resolving Indexation Deadlocks

The first seventy-two hours post-cutover determine whether a migration stays on track or requires emergency intervention. You need to crawl the legacy mapping file directly against production headers.

Using Screaming Frog, switch the mode to List and paste your list of legacy URLs. Under Configuration > HTTP > Redirects, uncheck “Follow Redirects.” Crawl the entire dataset. You are looking for absolute uniformity: every single URL must return an HTTP status of 301 Moved Permanently.

Investigate the following failure modes immediately:

• URLs returning 404 or 410: These represent dropped redirects. The authority associated with these historical URLs is evaporating with every hour they remain unresolved.
• URLs returning 200 OK on the old host: The redirect failed to bind. The old server is still rendering content, generating massive cross-domain duplicate content and splitting search equity.
• URLs returning 302, 307, or 308: The web server or CDN is utilizing temporary redirection logic. Update server rules to explicit 301 headers immediately.
• Redirect chains (301 -> 301 -> 200): Consolidate these paths directly to the terminal target.
• URLs pointing to the homepage (Soft 404s): If a legacy product page redirects to the new domain’s homepage, Google will classify the redirect as a Soft 404 and strip indexing value. Ensure deep URLs point to their exact equivalents or the most direct parent category.

If your discovery crawls freeze, study the steps in why your new content indexing checklist is failing to identify whether edge rendering, JavaScript hydration issues, or meta robots conflicts are blocking the new templates from rendering in headless search environments.

Log File Forensics: Tracking the Authority Handshake

Search Console metrics lag behind reality by roughly two to three days. When a migration is in flight, waiting seventy-two hours to see aggregate data inside Search Console is too slow. Server log files are the only real-time source of truth.

You must capture and parse raw web server access logs across both hosting environments. Run log analysis daily using tools like Loggly, ELK stack, or standalone log analyzers. Filter user-agent strings specifically for verified Googlebot IP ranges (using reverse DNS lookups to prevent spoofed bot noise).

Watch for these specific behaviors:

[Day 1-7]   Old Server: High Googlebot 301 Hits / Low 200 OK
            New Server: Spike in Googlebot 200 OK Discovery
[Day 8-21]  Old Server: Tapering 301 Requests
            New Server: Broad Crawl Coverage Across Deep Architecture
[Day 22+]   Old Server: Minimal Background Crawl (Residual verification)
            New Server: Normal Crawl Frequency Matching Site Updates

If you observe Googlebot hitting old URLs, receiving a 301, and never requesting the corresponding URL on the new server, you have an infrastructure roadblock. This typically points to aggressive rate-limiting on the new server. When Googlebot attempts to process a high-volume batch of discovered URLs, the origin infrastructure interprets the surge as a DDoS attack and returns HTTP 429 (Too Many Requests) or drop-connect packets. Googlebot backs off, and indexing stalls.

Check for errors in your protocol setup as well. If legacy requests bounce around insecure endpoints, read our breakdown on why your https migration indexing is failing to stop handshake mismatches from polluting your log lines.

Migration Failure Modes: Architectural Comparison

Understanding the technical implications of your redirect implementation helps prioritize engineering bandwidth during the planning stage.

The following comparison table breaks down common architectural choices, their immediate SEO impact, and their long-term maintenance overhead.

Aim for granular 1-to-1 edge rewrites wherever your architecture changes. If your URL structure is completely untouched, wildcard matching at the edge is acceptable—but test every top-tier landing page before verifying completion.

Quick-Reference Migration Checklist

Use this quick-reference summary as an operational sanity check before, during, and after your deployment window.

┌────────────────────────────────────────────────────────────────────────────┐
│                    DOMAIN MIGRATION INDEXING RUNBOOK                       │
├────────────────────────────────────────────────────────────────────────────┤
│ PRE-LAUNCH PHASE                                                           │
│ [ ] Pull composite URL inventory (Crawls + GA + GSC + Backlinks)           │
│ [ ] Construct explicit 1-to-1 mapping tables for all high-equity paths      │
│ [ ] Standardize staging canonical links to output new domain host strings  │
│ [ ] Configure edge network infrastructure and stage 301 rewrite maps       │
│ [ ] Verify active SSL coverage for both origin domains                     │
│ [ ] Lower DNS TTL settings to 300 seconds                                  │
├────────────────────────────────────────────────────────────────────────────┤
│ LAUNCH & DEPLOYMENT PHASE                                                  │
│ [ ] Execute DNS cutover pointing to edge redirect engines                  │
│ [ ] Validate HTTP headers via CLI (ensure no 302, 307, or loop conditions) │
│ [ ] Test robots.txt availability (must NOT disallow legacy crawl paths)   │
│ [ ] Submit legacy XML sitemap to Old Domain GSC Property                   │
│ [ ] Submit clean target XML sitemap to New Domain GSC Property             │
│ [ ] Execute the official Change of Address tool inside Search Console      │
├────────────────────────────────────────────────────────────────────────────┤
│ POST-LAUNCH VERIFICATION                                                   │
│ [ ] Execute Screaming Frog list crawl against legacy mapping list (301 check│
│ [ ] Check for internal linking leaks pointing back to old domain names    │
│ [ ] Daily parsing of edge log files for Googlebot crawl status rates       │
│ [ ] Monitor GSC Index Coverage reports for dual-indexing convergence       │
│ [ ] Keep legacy DNS, redirects, and SSL live for a minimum of 12 months    │
└────────────────────────────────────────────────────────────────────────────┘

Never skip the maintenance phase. Many companies take their old domain offline after sixty days to save on renewal costs or server hosting fees. Doing so severs the authority connection. Google takes months to stabilize internal indexing metrics across massive websites. Keep those legacy 301 redirects running for at least a full year, and renew your old domain name indefinitely.

A successful domain migration requires meticulous planning, clean technical execution, and continuous monitoring of redirect performance. By systematically mapping URLs, aligning canonical directives, and using dual-sitemap signaling, you can transition your site to its new home without losing search visibility.

When you need to get millions of migrated URLs recognized and processed by search engines without waiting months for standard crawl schedules, InstantIndexingPro handles the heavy lifting directly through automated indexing pipelines.

Keep reading

Playbook

Why Google isn't indexing your pages (and how to actually fix it)

Indexing isn't one problem — it's a pipeline with four places to fail. Here's how to find which stage is blocking your pages, and the fix for each.

Mara Kessler October 14, 20265 min read

Guide

How to get backlinks indexed faster (so they actually count)

A backlink does nothing until the page it lives on is indexed. Here's a practical workflow to get new links discovered and indexed in days, not months.

The InstantIndexingPro Team October 9, 20262 min read