Week Six: Normal Volatility or Hangover in Progress?
Objective: Given a real 5,280-page Search Console indexing export six weeks after a migration, determine which of the four not-indexed reasons is normal settling and which needs escalation today, using the lesson's own volatility-vs-hangover thresholds.
StoneCo just moved its merchant-education hub, Stone Educa, from a standalone subdomain to a subfolder of stone.com.br ahead of a broader Latin America merchant push. Six weeks post-launch, someone asks in standup whether the dip they're seeing is normal migration volatility or a hangover in progress. You have the Search Console indexing export to answer that.
Four passes over one export: check for leftover missing redirects, check whether the robots.txt block is intentional or a staging leftover, judge the largest bucket against the lesson's volatility timeline, and check for a canonical fight between the old subdomain and the new subfolder.
Six weeks after this migration, which of four not-indexed problem buckets is normal settling and which needs escalation today?
Before you start
What you'll need
- —Familiarity with reading a Search Console indexing export broken down by reason
- —Understanding of the difference between a redirect problem, a blocking problem, and a canonical/duplication problem
- Change of Address Tool
- a Search Console feature used when a site moves domains or subdomains, that tells Google explicitly which property is the new home; the old property should stay registered, not be deleted, since Google still needs to see it.
Free path (everything below is enough to finish)
Free, and the only tool that shows Google's own per-URL indexing classification and historical trend.
Free for up to 500 URLs, sufficient to verify both the robots.txt and redirect findings directly against the live site.
Paid upgrades (optional, faster/deeper)
This diagnostic is fully completable on the free path.
The free path is complete for diagnosing the indexing export; Ahrefs is a useful add-on to confirm link-equity transfer, not required to complete this diagnostic.
The process
4 steps
Step 01 of 04
The lesson names missing or many-to-one redirects as the single biggest cause of ranking loss. Six weeks after a migration that supposedly shipped a complete redirect map, any nonzero 404 count is a signal the map had gaps.
94 pages (6.8% of the 1,389 not-indexed pages) return 'Not found (404)' six weeks post-launch. For a migration with a supposedly complete redirect map, what does this nonzero count mean, and what's the fastest way to find exactly which 94 URLs these are?
Procedure
- Open the Not found (404) report and export the list of 94 affected URLs
- Cross-reference each URL against the original redirect map to confirm whether it was ever included
- Separate URLs that were missed entirely from URLs where a redirect was added but broken
- Prioritize fixing missed URLs first, since those never had a redirect attempt at all
gsc-indexing-export.csv, Not found (404) bucket Total pages: 94 (6.8% of 1,389 not-indexed) Cross-reference against original redirect map (sample of 10) 7 of 10: never appeared in the redirect map at all (missed entirely) 3 of 10: appeared in the map, but the destination URL itself now also 404s (broken redirect target)
Healthy
Zero 404s from the migrated section, or a documented, shrinking list actively being closed out.
Unhealthy
94 pages sitting in the 404 bucket for six weeks with nobody having checked whether they were ever in the redirect map.
What this means
A migration with a truly complete 1:1 redirect map should show close to zero 404s from the migrated URLs. Finding that 70% of a sample were never mapped at all means the original redirect map had real gaps, not just a few edge cases missed.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| 94 pages have sat in the 404 bucket since launch with no owner assigned | Export the full 94-URL list today and assign it to dev as a same-week fix, prioritizing the never-mapped subset | half day |
| Nobody checked the original redirect map for completeness before launch | Add a pre-launch step: crawl the old site fully and confirm every indexed URL appears in the redirect map before go-live, for the next migration | 30 min |
Step 02 of 04
The lesson's most common fatal mistake: a noindex tag or Disallow rule that was correct on staging but never got removed for production, deindexing pages silently with no error message anywhere.
412 pages (29.7% of not-indexed) show 'Blocked by robots.txt.' Six weeks after launch, is this an intentional, scoped rule or a leftover staging blanket-block, and what's the one-file check that answers it definitively?
Procedure
- Open the live production robots.txt file
- Export the 412 blocked URLs from the indexing report
- Check whether the Disallow rule is scoped to a specific, intentional path or written broadly enough to catch the whole migrated section
- If broad, confirm with the dev team whether it was meant to be temporary (a staging leftover) or permanent
Live robots.txt (excerpt) User-agent: * Disallow: /educa/ 412 blocked URLs, sample check 10 of 10 sampled URLs fall under /educa/, the entire migrated merchant-education section Dev team confirms: this rule was added on staging to prevent premature indexing before launch, and was never removed.
Healthy
A robots.txt rule scoped narrowly enough that it doesn't block the entire migrated section, confirmed as intentional if it exists at all.
Unhealthy
A blanket Disallow rule blocking the entire new section, sitting unnoticed for six weeks because nobody checked whether it was meant to be temporary.
What this means
412 pages, nearly 30% of the not-indexed total, all falling under one Disallow rule that the dev team confirms was a staging leftover is exactly the lesson's most common fatal mistake. This is the single highest-priority fix in the whole export.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| 412 pages are blocked by a rule confirmed to be a staging leftover | Remove the Disallow: /educa/ rule from production robots.txt today, then request re-crawling via Search Console | 5 min |
| No pre-launch checklist step currently catches staging-only rules before they ship to production | Add 'diff staging robots.txt against production robots.txt' as a mandatory pre-launch checklist item | 5 min |
Step 03 of 04
The lesson's explicit threshold: normal post-launch volatility is a 10-30% dip settling within 2-6 weeks. Anything still falling after 4 weeks needs intervention now, not next quarter.
690 pages (49.7% of not-indexed, the single largest bucket) are 'Crawled, currently not indexed.' At week 6 post-launch, does a bucket this large still fall inside 'normal settling', or does it cross into hangover territory needing escalation today?
Procedure
- Pull the week-2, week-4, and week-6 Crawled-not-indexed counts from saved exports (or Search Console's historical trend)
- Compare the week-6 count against the lesson's 2-6 week normal-settling window
- If the count is still the largest bucket and hasn't meaningfully shrunk by week 6, treat it as a hangover in progress
- Escalate rather than wait for 'next quarter's review'
Crawled, currently not indexed, trend since launch Week 2: 740 pages Week 4: 705 pages Week 6: 690 pages (still 49.7% of all not-indexed pages) 6.8% decline over 4 weeks is far short of the lesson's normal-settling pace; the bucket is still the largest one in the export at week 6.
Healthy
A bucket that shrinks substantially week over week, on track to normal levels by week 6-8.
Unhealthy
A bucket that barely moves (6.8% over a month) while still being described in standup as 'normal migration volatility.'
What this means
A 6.8% decline over four weeks, on a bucket that's still the single largest problem in the export, doesn't match the lesson's definition of normal settling. This is the escalation the standup conversation needed, not another 'let's keep watching it' cycle.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| The team has been calling this 'normal migration volatility' for six weeks without checking it against the lesson's actual thresholds | Present the week 2/4/6 trend in today's standup as evidence this has crossed into hangover territory | 30 min |
| No investigation has started into why these specific 690 pages aren't indexing | Sample-check 10-15 of the 690 URLs for content thinness, duplicate content, or missing internal links, the likely root causes | half day |
Step 04 of 04
The lesson's launch-day guidance: if the domain (or in this case, subdomain) changed, use Search Console's Change of Address tool and keep the old property registered, since Google still needs to see the redirects from it.
182 pages (13.1%) are 'Duplicate, no user-selected canonical.' For a subdomain-to-subfolder move, what does a bucket this size suggest about the old subdomain's current status, and what's the two-part fix?
Procedure
- Check whether the old educa.stone.com.br subdomain still resolves live, or whether it's fully redirecting
- Confirm both the old subdomain and new domain are registered as separate Search Console properties
- If the old subdomain still serves live content instead of redirecting, treat that as the root cause of the canonical confusion
- Fix the redirect gap, then re-verify the Change of Address setup covers the subdomain properly
Old subdomain check educa.stone.com.br/pix-para-comerciantes/ still returns 200 (live), not a 301 to stone.com.br/educa/pix-para-comerciantes/ Search Console properties stone.com.br: registered educa.stone.com.br: registered, Change of Address not yet configured
Healthy
The old subdomain fully 301-redirects to its new subfolder equivalent, and both properties are registered with Change of Address configured.
Unhealthy
The old subdomain still serves live, duplicate content in parallel with the new subfolder, leaving Google to guess which one is canonical.
What this means
182 duplicate-canonical pages with the old subdomain still resolving live is a direct match: Google is seeing two live copies of the same content and hasn't been told which one wins. This is fixable in one deploy, redirect the old subdomain, then it's a matter of waiting for re-crawl.
So what do I do about it?
| Symptom | Action | Effort |
|---|---|---|
| The old subdomain still serves live content six weeks after the 'migration' supposedly completed | Deploy 301 redirects from every old subdomain URL to its new subfolder equivalent this week | half day |
| Change of Address was never configured for the subdomain-to-subfolder move | Configure Change of Address in Search Console once the redirects are live, and keep the old subdomain property registered rather than deleting it | 30 min |
Analyze your findings
What to look for
- Trend, not snapshot
- Is a bucket shrinking meaningfully week over week, or has it plateaued while still being called 'normal volatility'?
- Confirmed vs. assumed intent
- Has a robots.txt rule actually been confirmed as intentional or leftover, or is that just being assumed?
- Mapped vs. unmapped 404s
- Within a 404 bucket, does the URL trace back to being missed from the redirect map entirely, or to a redirect that points at another broken URL?
- Old-domain live status
- Does the old subdomain still serve live content in parallel with the new location, or does it fully redirect?
Make the call
At week 6, the 'Crawled, currently not indexed' bucket has declined only 6.8% since week 2 (740 to 690 pages) and is still the largest bucket in the export. The team has been calling this normal migration volatility. Is that assessment correct?
Recommendation · Priority: High
“Escalate today: the 690-page 'Crawled, currently not indexed' bucket has crossed from normal volatility into a hangover in progress by the lesson's own 4-week threshold, and needs a content-quality sample check this week. In parallel, remove the confirmed staging-leftover robots.txt Disallow rule blocking 412 pages (the single highest-priority fix, since dev has already confirmed it was never meant to reach production), close the 94-page 404 gap starting with the 70% that were never in the original redirect map, and deploy the missing 301 redirects from the old subdomain, which is still resolving live and causing the 182-page canonical conflict.”
Common mistakes
What trips people up
Calling any decline in a bucket's size 'on track', regardless of pace — the lesson's threshold is about the rate and timing of the decline, not whether the number went down at all; 6.8% over four weeks on the largest bucket is a hangover, not progress.
Assuming a robots.txt Disallow rule is intentional without confirming with the team that wrote it — a blanket rule blocking an entire migrated section is exactly the pattern the lesson calls the most common fatal migration mistake, and needs explicit confirmation, not an assumption either way.
Treating all 94 of the 404 pages as the same problem — URLs never included in the redirect map at all need a different fix (add them) than URLs whose redirect target itself now 404s (fix the destination).
Deleting the old subdomain's Search Console property once the new one is set up — the lesson is explicit that the old property should stay registered since Google still needs to see the redirects coming from it.
Final deliverable
A week-6 migration-health memo ranking all four problem buckets by urgency: the confirmed staging robots.txt leftover (highest priority), the stalled 690-page bucket now crossing into hangover territory, the 94 unmapped 404s, and the old-subdomain redirect gap behind the 182 duplicate-canonical pages.
See a reference example
Applying the same four-step triage to a different fintech's own subdomain consolidation (illustrative, TAC Security moving its research hub under the main domain): the 'Blocked by robots.txt' bucket turned out to be intentional and correctly scoped, closing that line of inquiry in ten minutes, while the Crawled-not-indexed bucket was the real problem, traced to a batch of pages that lost their original publish dates during the CMS move.
Success criteria
You're done when you can:
- Correctly identifies the leftover robots.txt Disallow rule (412 pages, confirmed via dev team) as the single highest-priority fix
- Judges the 690-page 'Crawled, currently not indexed' bucket as having crossed into hangover territory using the week 2/4/6 trend, not just its raw size
- Distinguishes never-mapped 404s from broken-redirect-target 404s within the 94-page bucket
- Connects the 182 duplicate-canonical pages to the old subdomain still resolving live, not a vague 'canonical issue'
Key takeaway
A post-migration health check across four buckets each needs a different verification: is a decline actually on pace against a real threshold, is a block confirmed intentional or just assumed, does a 404 trace back to a mapping gap or a broken target, and is the old domain actually gone or still live. Treating any one bucket's raw count as self-explanatory, without this deeper check, misses the difference between normal settling and an active problem.