Diagnose migration traffic loss

Compare old and new URL visibility while checking redirects, canonicals, indexing, sitemaps, and timing.

Directional evidence Partially automatable Advanced

Some Search fluctuation is expected while Google crawls and processes changed URLs. A persistent or concentrated migration loss is not something to explain away with timing. Compare the old and new URL populations, validate mappings and destination indexability, and determine whether the loss follows a specific implementation defect.

The first question is whether the migration changed user-visible URLs. A domain, protocol, subdomain, or path change requires URL mapping and redirects. A hosting or CDN move with unchanged URLs requires DNS, availability, firewall, and server-capacity checks instead.

Freeze the migration facts

Record:

launch date and time zone;
old and new properties, hosts, protocols, and path patterns;
whether content, design, internal linking, rendering, or information architecture also changed;
complete old-to-new URL map;
baseline clicks, impressions, indexed URLs, crawl activity, and top pages;
release, redirect, sitemap, canonical, DNS, and Change of Address dates;
known rollback criteria and owners.

Combining a domain move, URL redesign, content rewrite, navigation change, and rendering migration makes attribution difficult. Google recommends changing one major thing at a time where possible.

Quantify the loss across old and new scope

For a domain or subdomain move, retain verified Search Console properties for both sides. A single property may not contain the complete before-and-after history in the way stakeholders expect.

Build a daily or weekly view of:

old-property Web clicks and impressions;
new-property Web clicks and impressions;
combined old + new performance;
old URLs still receiving impressions;
new destinations gaining impressions;
losses by old directory, template, country, and device;
important unmapped or removed URLs.

The expected transfer pattern is declining old visibility and increasing new visibility. Diagnose combined performance: looking only at the new property can make a normal transition appear as total loss, while looking only at the combined total can hide a failed directory.

Use complete data and equivalent comparisons. Separate Web from image, video, News, Discover, and Google News.

Join performance to the URL map

The URL map is the migration’s primary diagnostic dataset. For each important old URL, store:

intended new URL or explicit retirement decision;
old baseline clicks and impressions;
current redirect chain and final status;
destination canonical and indexability;
internal-link and sitemap status;
current old/new impressions and clicks;
last Googlebot request where logs are available.

Prioritize by historical clicks, business value, external links, and template coverage. A small number of high-value broken mappings can explain most of a traffic loss.

Audit redirects as mappings, not just status codes

For each old canonical URL:

use a permanent server-side 301 or 308 when content moved permanently;
redirect directly to the closest equivalent destination;
avoid chains and loops;
do not mass-redirect unrelated retired pages to the homepage;
preserve paths and parameters only where they map meaningful content;
return a genuine 404 or 410 when no replacement exists;
keep old infrastructure able to serve redirects.

A spreadsheet showing “301” is insufficient. Crawl the old URL set and record every hop, final URL, final response, and content equivalence.

Google recommends permanent server-side redirects for permanent URL moves. Temporary redirects can signal that the original URL should remain the Search URL.

Verify every destination can replace its source

Sample top URLs and every new template in URL Inspection. Confirm that each destination:

returns a stable 200;
is not blocked by robots.txt, authentication, firewall, or bot protection;
has no accidental noindex meta tag or HTTP header;
renders the intended primary content;
declares an appropriate self-canonical;
is not canonicalized back to the old URL or an unrelated destination;
appears in updated internal links and XML sitemaps;
preserves necessary structured data and hreflang relationships;
does not behave as a soft 404.

Staging environments often use sitewide noindex or robots blocks. Removing only one of several launch controls can leave the new site unindexable.

Compare indexed evidence with the live test. A healthy live destination may still be waiting for recrawl; an unhealthy live result is an active launch defect.

Check canonical and internal signals

After a URL-changing migration, preferred signals should point forward:

old URL permanently redirects to new;
new URL self-canonicalizes;
sitemaps list new canonical URLs;
internal links use new URLs directly;
hreflang, structured data, feeds, and alternate relationships use the new host/path;
external campaign and navigation links avoid old redirect chains where controllable.

Conflicting canonicals can keep the old URL selected or consolidate a new page elsewhere. Internal links that still target old URLs force users and Googlebot through redirects and blur the intended architecture.

Use old and new sitemaps deliberately

Submit a sitemap of new canonical URLs. Google’s migration guidance also describes retaining an old-URL sitemap during transition so movement can be monitored: old indexed counts should decline while new indexed counts rise. Redirect warnings for the old sitemap are expected during the move.

Do not put redirects, errors, duplicates, or noncanonical destinations into the new canonical sitemap. Segment large migrations by directory or template so indexing changes can be attributed.

Sitemap submission is a discovery signal, not proof that every destination will be indexed.

Use Change of Address only when it applies

The Search Console Change of Address tool supports qualifying moves from one domain or subdomain to another after redirects are implemented.

Do not use it for:

HTTP to HTTPS;
path-only moves within a site;
www to non-www on the same domain;
hosting or CDN changes with unchanged visible URLs.

The same Google account must own the applicable old and new properties. Domain moves can require separate requests for subdomain variants.

Maintain redirects for at least 180 days and longer while Google Search traffic still reaches them. Google also recommends retaining control of the old domain for at least a year to prevent abuse.

The tool supports signal transfer; it does not repair broken mappings or make blocked destinations indexable.

Separate URL-changing and hosting-only failure modes

URL-changing migration

Prioritize redirects, URL mapping, new indexability, canonicals, sitemaps, internal links, Change of Address applicability, and old/new Search performance.

Hosting or CDN migration without URL changes

Prioritize:

DNS propagation and TTL planning;
certificate and hostname coverage;
firewall, WAF, rate-limit, and bot behavior;
origin/CDN cache correctness;
response latency and 5xx rates;
server logs from both old and new providers;
preservation of Search Console verification;
removal of staging crawl/index blocks.

Google notes that a temporary crawl-rate drop after hosting change can be normal, followed by recovery over the next few days. Keep old hosting available until its logs show traffic has reached zero.

Read common migration patterns

Pattern	Strong starting hypothesis
Entire new site has near-zero impressions	Property view, global block, availability, or Change of Address/setup issue
One directory failed to transfer	Mapping, template, sitemap, canonical, or internal-link defect
Old URLs retain visibility; new do not	Redirect/canonical conflict or destinations not processed/indexable
Both old and new lose combined visibility	Technical failure, removed content, demand/ranking change, or broad redesign impact
Clicks fall while impressions transfer	CTR, snippet, intent, or result-presentation change
Googlebot `5xx` rises after launch	Capacity, CDN, origin, DNS, or firewall issue
Old URL redirects to homepage	Non-equivalent mapping and possible soft-404 behavior
Live tests pass but indexed old URLs persist	Processing time, inconsistent signals, or insufficient recrawl

Patterns narrow investigation; they do not prove cause without URL and server evidence.

Set expectations without normalizing defects

Google states that medium-sized site moves can take weeks to process and larger sites longer. The speed depends partly on URL count and server responsiveness because Googlebot must visit old and new URLs.

Normal movement includes:

temporary ranking fluctuation;
old and new URLs coexisting in results;
old sitemap indexed counts falling while new counts rise;
increased crawling of new infrastructure.

Not normal enough to “wait out”:

widespread redirect errors;
destinations returning 5xx, 403, 404, soft 404, or noindex;
important pages with no mapping;
canonicals pointing backward or elsewhere;
a directory absent from internal links or sitemaps;
exhausted server capacity;
combined visibility continuing to fall with a defect-shaped pattern.

Fix confirmed defects promptly, then allow recrawling and reprocessing.

Recovery workflow

Rank lost old URLs by historical clicks and business importance.
Group failures by shared redirect, template, canonical, or infrastructure cause.
Fix the shared cause in staging and test representative URLs.
Deploy with monitoring and a rollback plan.
Recrawl the old URL map and new canonical set.
Live-inspect representative destinations.
Update sitemaps and internal links.
Annotate the fix date.
Monitor combined old/new performance and server logs.
Close only when critical mappings work and finalized visibility stabilizes.

Request indexing for a small number of critical corrected destinations if useful. Do not submit thousands of individual requests; sitemaps and crawlable links are the scalable discovery mechanisms.

Common migration mistakes

Measuring only the old or only the new property.
Launching without a complete URL map.
Checking only that a redirect exists, not where it ends.
Redirecting unmatched URLs to the homepage.
Leaving staging noindex, robots, authentication, or firewall rules in production.
Canonicalizing new pages to old URLs.
Keeping old URLs in navigation and new sitemaps.
Using Change of Address for an unsupported move.
Shutting down old hosting before crawlers stop reaching it.
Combining a redesign, content purge, platform change, and domain move without separate baselines.
Assuming every loss is normal migration volatility.