Migration Audit Example: Day 14 Post-launch Recovery Tracking
This example shows the aiwebpageseo Site Migration Audit at day 14 after replatforming saas.example.com to new.example.com. Traffic is -18% versus baseline (within expected dip range). 1,847 URLs migrated, 162 with 301 mapping gaps, indexation at 47% of baseline, and 38 top-100 ranks temporarily lost. Recovery tracking to full baseline by week 8.
| Source URL pattern | Old URLs | Mapped | Status |
|---|---|---|---|
| /blog/* | 342 | 342 | ✅ Complete |
| /products/* | 180 | 180 | ✅ Complete |
| /docs/* | 520 | 462 | ⚠ 58 unmapped |
| /help/* | 410 | 289 | 🔴 121 unmapped |
| /legacy-content/* | 395 | 0 | 🔴 All 404 — needs decision |
/help/* — 121 URLs returning 404
121 old help URLs have no 301 destination. Combined backlinks: 847 from 312 referring domains — every one of which now points at a 404, so the referral traffic is being thrown away and Google will eventually drop the URLs from the index. Fix today by mapping each old help URL to its closest equivalent in /docs/.
Redirect chains on top-traffic pages
18 high-traffic URLs go via 2-hop chains: /old-blog/post → /blog/post → /new-blog/post. Hops do not lose equity — Google has stated no PageRank is lost through a 301 or 302. They cost latency, wasted fetches, and fragility, since Google abandons a chain after roughly ten hops. Collapse to a single 301 from origin to final URL.
Product schema missing on 78 PDPs
New platform did not migrate Product schema. 78 product pages now have no JSON-LD, so product rich results will drop out as those pages are recrawled — the timing follows recrawl, not a CrUX cycle, which measures field performance data and has nothing to do with structured data. Rebuild Product schema generation in new template.
| Week | Traffic vs baseline | Indexed URLs | Top-100 ranks | Status |
|---|---|---|---|---|
| Week 0 (launch) | -22% | 38% | -52 | 🔴 Expected dip |
| Week 1 | -28% | 41% | -58 | 🔴 Deeper than expected |
| Week 2 | -18% | 47% | -38 | ⚠ Recovering |
| Week 4 (forecast) | -10% | 72% | -20 | ℹ Tracking to baseline |
| Week 8 (forecast) | +2% | 91% | -5 | ✅ Full recovery |
A traffic drop after a replatform is expected. Google has to recrawl every changed URL, follow every redirect and reconcile what it now sees with what it knew before, and on a site of any size that takes weeks. Two weeks in, an 18% dip on its own tells you almost nothing.
What tells you something is the shape of the loss. Spread evenly across every section, it is recrawl lag and the correct response is patience. Concentrated in one place — as it is here, with 121 orphaned help URLs — it is a defect, and no amount of waiting repairs a defect. The percentage is a headline; the distribution is the diagnosis.
Watch the right metric while you wait, too. Sessions confound recrawl progress with seasonality, campaigns and everything else that moves traffic. Indexed-URL counts and impressions for the new URLs isolate the thing you actually want to know: is Google finding and understanding the new site?
Almost everything a migration breaks can be repaired later without permanent loss. Titles can be rewritten, schema rebuilt, internal links repointed, performance regained. Unmapped URLs are the exception, and they are the reason this item sits at the top of the report.
Those 121 help pages carry 847 backlinks from 312 domains. Every one of those links now delivers a real person to a 404. That traffic is being discarded today, and it will keep being discarded until somebody maps the URLs. Over time Google will drop the old URLs from the index entirely, and whatever they had accumulated goes with them — at which point a redirect added later inherits nothing, because there is nothing left to inherit.
301 each old URL to its genuine equivalent
One hop, from the origin URL directly to the final destination. Build the map from a full crawl of the old site, your server logs and your backlink data — the logs will surface URLs the crawl missed, and the backlink data tells you which ones are worth the most.
Redirect to the most specific relevant section
Not the homepage. A homepage redirect is not a relevant destination for someone who wanted a help article, and Google frequently treats such redirects as soft 404s regardless, so you gain nothing and confuse the visitor.
410, and remove it from the sitemap
An honest 410 is better than a dishonest redirect. Just make sure the sitemap agrees — a sitemap that keeps nominating a URL you have declared permanently gone is two of your own systems contradicting each other.
Eighteen high-traffic URLs now resolve through two hops, and the advice to collapse them is correct. The justification usually attached to it is not, and it is worth correcting because it leads teams to do the wrong triage.
Redirect hops do not leak ranking value. Google has said that no PageRank is lost through a 301 or a 302; the choice between those codes affects which URL is indexed, not how much value is transferred. The "each hop loses ten to fifteen percent" figure is a survival from an older model and does not describe current behaviour.
The real costs are concrete. Every hop is another round trip that a user on a mobile network waits through, on a page they wanted immediately. Every hop is a fetch spent on a redirect rather than on a page you want crawled, which matters when a migration has just handed Googlebot thousands of new URLs to get through. And every hop is one more link in a chain that grows, silently, across successive site changes — until it exceeds the roughly ten hops Google is willing to follow and the destination becomes unreachable with nobody noticing.
So collapse the chains to a single hop from origin to final URL, and repoint the internal links at the destination so the redirect is a safety net rather than the primary path. Do it for the users and the crawler. Not for an equity leak that does not exist.
Seventy-eight product pages arrived on the new platform with no JSON-LD. Product rich results will drop out of the search listings for those pages as they are recrawled — the timing follows recrawl, not any fixed cycle, and nothing is being penalised. The listings simply become plainer, and on commercial pages that is a visible commercial cost.
Rebuild schema generation on the new platform, and then do the thing migrations habitually skip: verify that the values match the rendered page. A replatform reintroducing Product schema from a cached or stale data source is worse than one that ships no schema at all, because price or availability that contradicts what the shopper sees is grounds for item disapproval in Google's shopping surfaces. A missing enhancement costs you a feature. A false one costs you the listing.
While you are there, check what else the platform quietly dropped. Canonical tags, hreflang annotations, robots meta directives and structured data are the four things migrations most often lose, because they are invisible in a browser and nobody clicks them during UAT. A single crawl of the new site comparing them against the old will find all four in an afternoon.
Map the 121 help URLs
The only item that is losing something you cannot get back. Everything else on this report can wait a week without permanent damage.
Rebuild Product schema, and verify it against the rendered page
Commercial pages first. Accuracy matters more than coverage — markup that contradicts the page is a defect, not a partial win.
Collapse the chains and repoint internal links
Latency, crawl efficiency and fragility. Cheap, mechanical, and it makes the recrawl go faster, which is the thing you are waiting on.
Monitor indexed URLs and impressions, not sessions
They isolate recrawl progress from everything else. If the new URLs are being indexed and impressions are climbing, patience is the correct action. If they are not, waiting will not save you.
And for the next migration: the redirect map is built before launch, from a full crawl of the old site plus the server logs plus the backlink data, and it is tested against a staging environment before anybody switches DNS. Almost every bad migration is a missing redirect map, discovered afterwards. It is the one part of the work that cannot be done later.
Is an 18% traffic drop two weeks after a migration normal?
A dip is expected and its depth is not a reliable diagnostic on its own. Google has to recrawl every changed URL, follow every redirect, and reconcile the new URLs with what it knew about the old ones, and on a site of any size that takes weeks rather than days. What separates a normal dip from a broken migration is not the percentage — it is whether the loss is spread evenly or concentrated. Even loss across all sections is usually recrawl lag. A collapse in one section, as here with /help/*, is a defect, and no amount of waiting fixes it.
Do redirect chains lose ranking value?
No. Google has stated that no PageRank is lost through a 301 or a 302, and the difference between them concerns which URL ends up indexed rather than how much value passes. The commonly quoted figure of ten or fifteen percent lost per hop describes an old model and not current behaviour. Chains still deserve fixing, for reasons that are real: each hop is another round trip a user waits through, another fetch that could have gone to a page you want crawled, and another link in a chain that Google will abandon after roughly ten hops. Collapse them to one hop, and point your internal links at the final URL rather than at the redirect.
What should happen to the 121 orphaned help URLs?
Map each one to the closest genuinely equivalent page on the new platform and 301 it there. Where no equivalent exists, redirect to the most specific relevant section — not the homepage, which is not a relevant destination for the visitor and which Google frequently treats as a soft 404 anyway. Where the content is truly gone, return 410 and remove the URL from the sitemap. The urgency comes from the 847 backlinks: those are real people clicking real links from 312 other sites and landing on nothing, and that traffic is being discarded every day the mapping is missing.
Should I keep the old site's redirects forever?
Keep them for as long as anything still points at the old URLs, which in practice means indefinitely for any URL with external links. Redirects are cheap to serve and expensive to remove: the day you delete them, every backlink pointing at an old URL starts returning 404, and you have thrown away the value of a migration you paid for. The one thing worth doing over time is collapsing chains — as new redirects accumulate over successive site changes, a two-hop chain becomes a five-hop chain, and it is the chain length, not the age of the rule, that eventually breaks.
When should I expect traffic to recover?
There is no reliable timeline, and any consultant offering one to the week is guessing. Recovery follows recrawl, which follows crawl demand and your server's responsiveness, and it varies enormously with site size. What you can do is monitor the right thing: watch indexed-URL counts and impressions for the new URLs rather than sessions, because sessions confound recrawl progress with seasonality and campaign activity. If the new URLs are being indexed and impressions are climbing, the migration is working and patience is the correct action. If they are not, waiting will not help.
The new platform dropped our Product schema. How urgent is that?
Urgent on commercial pages, because product rich results disappear as those pages are recrawled and that has a direct effect on how the listings appear in search. It is worth being precise about the mechanism, though: nothing is being penalised, and the timing is governed by recrawl rather than by any performance-data cycle. Rebuild schema generation on the new platform, and when you do, verify that the values match the rendered page — a migration that reintroduces schema with stale prices is worse than one that ships none at all, because price or availability that contradicts the visible page is grounds for item disapproval in Google's shopping surfaces.
What is the single most common cause of a migration going badly?
An incomplete redirect map, which is exactly what has happened here. Everything else — schema, titles, internal links, performance — can be repaired at leisure with no permanent loss. Unmapped URLs, on the other hand, are actively bleeding: external links break, users hit 404s, and Google eventually drops the old URLs entirely, at which point whatever they had accumulated is gone and cannot be recovered by fixing the map later. Build the map from a full crawl of the old site plus your server logs plus your backlink data, before launch, and check it after.
Related Demo Reports
Run Site Migration Audit on Your Own Site
Get your real migration audit with pre-launch baseline, 301 mapping validation and 90-day post-launch recovery monitoring.