Domain change indexing: the complete checklist

Most teams we see lose between 15% and 40% of their organic traffic during a site move. I’ve managed migrations for sites with 50,000 URLs and others with 5 million. The delta between a successful move and a disaster usually comes down to how you handle domain change indexing. It isn’t just about moving files; it’s about forcing Google to acknowledge that the old property is dead and the new one is the rightful successor. If you’ve failed at this before, it’s likely because you treated the migration as a technical task rather than a signal-transfer operation.

The 1:1 Redirect Map Strategy

Wildcard redirects are the enemy of recovery. If you have 10,000 pages on the old domain, you need a CSV file with 10,000 rows. A wildcard redirect—where everything on old-site.com/about goes to new-site.com/—is a soft 404 in disguise. Google’s algorithms look for content parity. If a user was looking for a specific product and ends up on your homepage, they bounce. Google tracks that bounce, sees a mismatch in intent, and devalues the redirect. Map your high-traffic pages first. If you have legacy content that doesn’t exist on the new site, redirect it to the most relevant category page, not the homepage. Do not use 302 redirects; they tell Google the move is temporary, and the indexing signals will not transfer. Use 301s, period.

When you build your mapping CSV, include a column for ‘Page Type’ and ‘Monthly Traffic’ from GA4. This allows you to prioritize the migration of pages that actually drive revenue. If you have a budget constraint or a massive site, prioritize the top 20% of your URLs that drive 80% of your traffic. For the remaining 80% of long-tail pages, if you must use a partial map, ensure the most critical category and sub-category paths are covered. Never leave a high-traffic URL orphaned.

Pre-Migration Audit of the Old Site

Before you touch the DNS, you need a clean inventory. Run a crawl of your old domain using Screaming Frog or Sitebulb. Filter for 404s, 403s, and redirect chains. If you migrate broken URLs, you are just moving trash to a new house. I typically spend three days cleaning up the old site’s internal link structure. If you have internal links pointing to redirected pages, update those to the final destination URLs on the new domain before the move. This reduces the latency Google experiences when it finally starts hitting the new domain. Ensure your XML sitemap on the old domain is perfectly accurate and submitted to GSC.

Furthermore, look for ‘orphan’ pages—pages that don’t have internal links pointing to them. These pages are often overlooked during migration mapping. If you don’t know they exist, you won’t redirect them, and they will turn into 404s on the old domain, which will eventually be dropped from Google’s index. Extract your full URL list from GSC and compare it against your crawler’s list. If there are URLs in GSC that the crawler didn’t find, find out why. Are they hidden in JavaScript? Are they buried in deep sub-directories? Fix the internal navigation to surface these pages before you migrate.

Handling the Robots.txt and Tagging

The most common mistake is leaving a noindex tag or a disallow rule in your development environment when you push to the new domain. Check your robots.txt immediately upon deployment. I’ve seen developers leave Disallow: / in their staging environment, push it to production, and then wonder why their traffic hit zero overnight. Use a tool like curl -I to verify headers for your top 50 landing pages. Ensure that the new site is not blocking Googlebot. Verify that your canonical tags on the new site point to the new URLs, not the old ones. If you leave the old canonicals pointing back to the old site, you are effectively telling Google to ignore the new one.

Beyond noindex, check your meta robots tags. Sometimes CMS templates have global settings that default to noindex for custom post types. Audit your header templates specifically. Also, ensure your sitemap.xml is dynamic. If you move the site and the sitemap still references the old domain, you are creating a massive trust issue. Your sitemap should be updated to point to the new domain immediately upon launch. Verify that your new domain’s sitemap is submitted as a new property in the new GSC profile.

The Google Search Console Change of Address Tool

The Change of Address tool in GSC is not magic, but it is a vital signal. You must have both the old and new domains verified in GSC. Once the 301s are live, go into the old property in GSC and use the tool to notify Google of the move. This tells the algorithm that the site migration is intentional. I advise waiting until the new site is fully accessible and the 301 map is verified before clicking ‘submit’. If you use this tool too early, before the redirects are functioning, you’re sending conflicting signals. Monitor the ‘Move Report’ in GSC daily for the first two weeks; it will tell you if Google is struggling to map specific pages.

Note that the Change of Address tool is only for domain-level changes (e.g., from old.com to new.com). If you are moving to a subdomain or changing protocols (HTTP to HTTPS), the tool behaves differently. Always ensure that the user-agent strings are consistent. If you are using a proxy or a CDN like Cloudflare, make sure the original IP of the new server is whitelisted and not being rate-limited by the CDN’s own security settings. A common failure point is the CDN blocking Googlebot because the new site looks like a ‘new’ site with no reputation.

Managing Server-Side Redirect Chains

Redirect chains are a silent killer of crawl budget. If old-site.com/page redirects to old-site.com/new-page which then redirects to new-site.com/new-page, you have introduced an extra hop. Googlebot might stop at the second hop, especially if the site is large. When mapping your redirects, ensure the destination URL is the final, non-redirecting URL on the new domain. If you are on a platform like Shopify or BigCommerce, you might be limited in how you handle server-side redirects. In those cases, use a dedicated redirect app or Cloudflare Workers to manage the mapping at the edge. Edge-level redirects are significantly faster than application-level redirects.

Why does this matter? Crawl budget is finite. Every extra redirect hop is an additional HTTP request that consumes server resources and time. If you have 500,000 pages, a 1-second delay per redirect means Googlebot spends 138 hours just waiting for redirects to resolve. That is time it isn’t spending indexing your content. I always recommend using a tool to check for ‘redirect loops’ as well. A loop (A to B, then B back to A) is a catastrophic error that will cause that specific URL to drop out of the index within 48 hours.

Crawl Budget and Discovery

During a migration, Googlebot will be hitting your site harder than usual to verify the new URLs. If your server is slow, you will see a drop in crawl rate, which directly impacts indexation. Before the migration, test your server response time. If you’re moving to a new host, ensure they can handle the initial spike in traffic from Googlebot. I recommend keeping the old site indexed for as long as possible while Google discovers the new one. If you remove the old site too quickly, you lose the bridge that allows Google to find the new pages. Monitor your server logs for 4xx and 5xx errors; these are your primary indicators of migration friction.

If you are using a cloud-based hosting solution, check your concurrency limits. During a migration, you may see an influx of thousands of requests per minute from various Googlebot IPs. If your server returns a 503 (Service Unavailable) error, Googlebot will back off. If this happens repeatedly, Googlebot will assume the site is unstable and stop crawling. Set up an alert for 5xx errors in your server logs. If you see them climbing, you need to increase your server capacity immediately, even if it’s just a temporary boost for the first 72 hours of the transition.

Tracking Indexation Velocity

You need a way to measure how fast the new domain is being picked up. I use a combination of GSC’s ‘Pages’ report and a custom log file analysis. Look for the ‘Crawled - currently not indexed’ status in GSC. If this number spikes, it means Google is seeing your new pages but doesn’t trust them enough to index them yet. This is usually a sign of thin content or a lack of internal linking on the new domain. I suggest building out a temporary ‘Migration Sitemap’—an XML sitemap containing only your most important pages—and submitting that separately to speed up the discovery of your core business drivers.

Beyond the standard GSC reports, use a tool to check the ‘cache’ date of your primary landing pages. If you notice the cache date is not updating on the new domain, it means Google is not re-crawling the page as frequently as it should. This is where active indexing pushes come in. By feeding the new URLs into an indexation service, you are essentially telling Google, “Hey, this is important, come look at it now.” This is especially useful for e-commerce sites where product availability and pricing updates happen frequently.

Common Domain Migration Myths Debunked

Let’s clear the air on three persistent myths. First, the ‘re-index delay’ myth: people think waiting 48 hours for Google to index the new site is normal. It isn’t. With a proper submission, you should see indexing activity within 4-6 hours. If you are waiting days, your technical foundation is flawed. Second, the ‘domain age is everything’ myth: some believe moving to a new domain resets your authority. If the redirects are perfect, the authority transfers. If it drops, it’s because the redirect structure is flawed, not because of the domain age.

Third, the ‘noindex on the old site’ myth: people think they should noindex the old site to force Google to move. Do not do this. Let the 301 redirects do the work. Noindex tags prevent Google from seeing the redirect instruction. If you noindex the old site, you are telling Google to drop the page from the index. It doesn’t tell Google that the page has moved; it tells Google the page shouldn’t exist. This is the fastest way to kill your organic traffic. Always use 301s, and keep the old site accessible until the new one is fully indexed.

Costs and Tradeoffs of Migration

Migration isn’t free. You pay in developer hours, server costs, and potential temporary revenue loss. The biggest cost is the opportunity cost of your engineering team. A poorly executed migration can cost a mid-sized e-commerce site six figures in lost revenue over a quarter. You are trading off stability for a potential gain in branding or URL structure. If you are moving domains for a rebrand, weigh the cost against the expected uplift. If you are moving because of a technical issue, ensure the new platform actually fixes those issues. Don’t migrate to a platform that is slower or harder to manage just because it’s ‘new’.

Additionally, consider the ‘redirect maintenance’ cost. You cannot simply delete your redirect table after three months. If you have legacy backlinks pointing to your site, those links will continue to send traffic to the old domain for years. You must maintain these redirects indefinitely. I’ve seen companies delete their redirect tables after a year, only to see their ‘direct’ and ‘organic’ traffic collapse because they broke thousands of old, high-value backlink paths. Budget for the long-term hosting of the legacy redirect layer.

Sustaining the New Domain Authority

Once the dust settles, don’t just walk away. Monitor your top 100 organic search terms for the first 90 days. If a specific page drops, investigate its redirect path immediately. Check your link profile in Ahrefs or Semrush to see if any high-authority backlinks are still pointing to the old site’s 404s. Reach out to those site owners and ask them to update the links to the new domain. This is a manual, tedious process, but it is necessary to solidify your new domain’s authority. Your goal is to make the transition invisible to your users and as clear as possible to the search engine.

Finally, update your off-page citations. If you have Google Business Profile links, social media profiles, or local directory listings, these all need to be updated to the new domain. While these are not direct ranking signals in the same way as a 301, they help build entity consistency. If Google sees a business entity mapped to old-site.com in one place and new-site.com in another, it creates signal noise. By cleaning up these ‘mentions’, you provide a stronger, more cohesive signal to the algorithm that the business has moved, not just the website.

The transition from an old domain to a new one is a mechanical process that rewards precision and punishes laziness. If your redirect map is clean and your GSC signals are aligned, the indexing phase will resolve itself without a permanent loss of traffic. Use tools like InstantIndexingPro to ensure your critical new pages bypass the standard queue and get indexed rapidly during the transition.

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