You shipped a major redesign (new templates, new structure, possibly new URLs) and 2-4 weeks later the Pages report in Search Console shows the Indexed count down 20-60%. Before you roll anything back: a drop in the first 4-8 weeks is normal — Google is re-crawling and re-evaluating the whole site. If it is still falling after week 8, you have a structural problem.
Fastest fix: the single most common cause is old URLs that now 404 instead of doing a clean 301 to their new equivalent. Pull your dropped URLs, run curl -sI on each, and fix anything that is not a single-hop 301 to a relevant 200 page. That one check resolves the majority of post-redesign coverage drops. The rest of this page covers how to tell normal re-evaluation from real damage and how to diagnose the other six causes.
Symptoms
- The Pages report shows -20% to -60% Indexed pages over 2-4 weeks after launch.
- URLs reclassified into the Why pages aren’t indexed table as
Crawled - currently not indexed. - Some URLs drop out entirely (
URL is not on Googlein the URL Inspection tool). - Performance (clicks/impressions) is down in the same window, but by a different proportion than the index count.
Quick verdict: normal or structural?
| Signal | Probably normal re-evaluation | Probably structural damage |
|---|---|---|
| Time since launch | First 4-8 weeks | Still dropping after week 8 |
| Old URL HTTP status | Clean single-hop 301 → 200 | 404, 410, redirect chain, or soft-404 |
| Not-indexed reason | Crawled - currently not indexed (some pages) | Page with redirect, Not found (404), Blocked by robots.txt, Excluded by noindex spiking |
| Raw HTML | Title, H1, body text present | Empty shell, content only after JS runs |
| Scope | A slice of pages, recovering week over week | Broad, monotonic, no recovery |
If most rows land in the left column, the fix is patience — do not stack more changes. If rows land on the right, work the causes below.
Common causes
1. URLs changed without a 301 to the new equivalent
Most fatal, most common. Going from /blog/2024/post-name/ to /articles/post-name/:
- Old URL was indexed → now returns 404 → Google drops it, and
Not found (404)climbs in the Pages report. - New URL has no historical signal → it starts ranking from zero.
A clean 301 fixes both: as of June 2026 Google transfers effectively all ranking signal (PageRank) through a 3xx redirect, but only on a single hop to a relevant destination. Chains (/old → /temp → /new) and redirects to an irrelevant page (e.g. everything pointing at the homepage) leak or discard that signal. Full canonical consolidation typically takes 1-4 weeks of crawling.
How to confirm:
# Sample old URLs and show the full redirect chain + final status.
# -L follows redirects; -w prints each hop and the final code.
for url in "/blog/2024/post-name/" "/old/url2"; do
echo "=== $url"
curl -sIL "https://yourdomain.com$url" -o /dev/null \
-w '%{num_redirects} hop(s) -> %{http_code} (final: %{url_effective})\n'
done
# Want: "1 hop(s) -> 200". 404, 410, 0 hops on a moved URL, or 2+ hops are all problems.2. Title / H1 / meta got more generic or weaker
A common template-rebuild mistake — the new layout hardcodes a fallback instead of the per-page value:
Old H1: "Astro Deploy to Vercel: Complete 17-Minute Setup"
New H1: "Complete Guide" <- genericized
Old <title>: "Astro Deploy to Vercel - 17-minute walkthrough | YourSite"
New <title>: "Article | YourSite" <- templated fallbackDuring re-evaluation Google reads lower information density on these pages and is more likely to leave them as Crawled - currently not indexed.
3. Internal link structure flattened or weakened
- “Related articles” used to show 5 links; the new template shows 2.
- Breadcrumbs used to link the category page; the new template renders plain text.
- A sidebar used to list 20 recent posts; the new template has no sidebar.
Every internal link removed is one fewer relevance/importance vote for the destination, and fewer crawl paths to reach it.
4. New template introduced thin pages
The redesign auto-generates low-value pages — author pages, tag pages, paginated monthly archives. They dilute crawl budget and internal-link equity, so your real articles get deprioritized and slip into Crawled - currently not indexed.
5. robots.txt or noindex over-applied
While cleaning up thin pages during the redesign you added noindex or Disallow rules in bulk and caught pages you actually wanted indexed. These surface as Excluded by 'noindex' tag or Blocked by robots.txt in the Pages report.
How to confirm:
# What changed in robots.txt? (keep an old copy, or pull one from Wayback)
diff <(curl -s https://web.archive.org/web/2026id_/https://yourdomain.com/robots.txt) \
<(curl -s https://yourdomain.com/robots.txt)6. SSR/SSG regression (empty HTML on first fetch)
The old template was server-rendered or static; the new one switched to client-side React, so the initial HTML is an empty shell. Google indexes in two waves: Wave 1 reads the raw HTML immediately; Wave 2 (the Web Rendering Service) runs your JS later — the gap is anything from hours to weeks. If content only exists after JS executes, large parts of the site sit unrendered and demote. As of June 2026, plain client-side React/Vue without SSR or prerendering is not a safe default for indexable content.
7. CSS/JS resources blocked by robots.txt
The new template ships new CSS/JS bundle paths, but robots.txt still Disallows the directory (or blocks a CDN path). Google can’t fetch the styles, renders a broken page, and downgrades it. Confirm with URL Inspection → Test live URL → View tested page → More info → Page resources and look for resources marked “blocked.”
Shortest path to fix
Step 1: Export the pre- and post-redesign Pages report
Search Console -> Indexing -> Pages -> Export (top right) -> CSV/Google Sheets
Export the "Why pages aren't indexed" table now, and again in 4 weeks.
Diff the two URL lists to find what dropped.If you never saved a pre-redesign baseline, reconstruct the old URL list from your prior sitemap, the Wayback Machine, or historical curves in Ahrefs / Semrush.
Step 2: Verify HTTP status for each dropped URL
# Put dropped URLs (one per line) in lost-urls.txt
while read -r url; do
status=$(curl -sIL "https://yourdomain.com$url" -o /dev/null -w "%{http_code}")
hops=$(curl -sIL "https://yourdomain.com$url" -o /dev/null -w "%{num_redirects}")
echo "$url -> $status (${hops} hop(s))"
done < lost-urls.txt > status.txt- 404 / 410: restore the page, or 301 it to the equivalent new URL.
- 301 with 2+ hops: collapse the chain to a single hop.
- 301, 1 hop: confirm the target is genuinely equivalent and returns 200.
- 200: technically fine — go to Step 3.
Step 3: Compare title / H1 / meta before vs. after
# Pull the pre-redesign snapshot from the Wayback Machine (id_ = raw archived HTML).
WB="https://web.archive.org/web/2026id_/https://yourdomain.com/article"
curl -sL "$WB" | grep -oiE '<title>[^<]+|<h1[^>]*>[^<]+'
# Compare with the current page
curl -sL "https://yourdomain.com/article" | grep -oiE '<title>[^<]+|<h1[^>]*>[^<]+'Anything that got more generic or shorter → restore the per-page, descriptive version.
Step 4: Audit internal link counts on affected URLs
# Count how many internal links point to each dropped URL in the new template.
while read -r url; do
count=$(rg -o "href=[\"']$url[\"']" src/ | wc -l)
echo "$url $count"
done < lost-urls.txtIf the count dropped versus the old design, add links back from genuinely related pages (related-posts block, in-body links, breadcrumbs).
Step 5: Check robots.txt + noindex over-application
# What robots.txt currently blocks
curl -s https://yourdomain.com/robots.txt
# Check BOTH the meta tag AND the X-Robots-Tag HTTP header (grep on the body alone misses the header).
while read -r url; do
hdr=$(curl -sI "https://yourdomain.com$url" | grep -i 'x-robots-tag')
meta=$(curl -sL "https://yourdomain.com$url" | grep -io 'name=["'\'']robots["'\''][^>]*noindex' | head -1)
echo "$url | header: ${hdr:-none} | meta: ${meta:-none}"
done < <(head -20 lost-urls.txt)Accidental noindex → remove it → use URL Inspection → Request indexing to re-queue (see the FAQ on quota before you spray hundreds of these).
Step 6: Check for an SSR/SSG regression
# Fetch the raw HTML with no JS execution (this is roughly what Wave 1 sees).
curl -sL "https://yourdomain.com/article" > raw.html
wc -c raw.html # a few KB of mostly markup = likely an empty shell
grep -c "<article" raw.html # 0 = your main content is not in the initial HTMLIf the content isn’t in raw.html, confirm with URL Inspection → View crawled page (Google’s rendered snapshot). Fix by re-introducing SSR or prerendering for article routes.
Step 7: After Steps 1-6, hold for 4-8 weeks
Once the clear problems are fixed, stop changing things. The first 4-8 weeks of decline is normal re-evaluation, and frequent edits make attribution impossible — you won’t know which change helped.
Still dropping after week 8:
- Re-run the diagnostics above.
- Check whether a Google Core Update landed in the same window (compounding effect — verify against the Search Status Dashboard).
- Consider rolling back the specific change your diagnostics point to, not the whole redesign.
How to confirm it’s fixed
- Old URLs now return a single-hop 301 to a relevant 200 page (re-run Step 2).
- The
Not found (404)/Page with redirect/Excluded by 'noindex'counts in the Pages report stop rising and start falling. - URL Inspection on a recovered URL shows URL is on Google with the redesigned page in the rendered snapshot.
- The Indexed count flattens, then trends back up over subsequent weeks.
Easy to misdiagnose
- Panic-redesigning again: layered changes make diagnosis impossible.
- “Traffic dropped, so roll back”: wait 4-8 weeks; a rollback costs another full re-evaluation cycle.
- Editing robots / canonical reflexively: only touch these if a diagnostic points there.
- Expecting Request indexing to accelerate recovery: the quota is roughly 10-12 URLs/day per property (rolling 24h), so it’s useless for a 1000-URL recovery — fix the structural cause instead.
Prevention
- Redesign in stages: structure first, then visual, then content templates — never all at once.
- Map every old URL to a new URL before launch and keep the redirect list in source control; prefer single-hop 301s.
- Export the current Pages report and your live sitemap before the redesign for later comparison.
- Run a pre/post crawl plus
curland Lighthouse checks on your most important pages. - Reserve an 8-week observation window after launch and avoid large further changes.
FAQ
Q: Should I roll back if pages drop? A: Not in the first 4-8 weeks — that decline is expected. A rollback triggers another re-evaluation cycle and resets the clock. Only roll back a specific change a diagnostic implicates.
Q: Do I need to resubmit my sitemap?
A: If your sitemap file lives at the same URL (the usual case), you don’t have to delete and re-add it — Google re-fetches it and discovers the new/changed URLs on its own. Do update each entry’s lastmod when the URL or main content actually changed, and resubmit once after a big URL migration to nudge a fresh crawl. Don’t expect deleting the old sitemap to remove pages from the index — it doesn’t; redirects and noindex do that. (Google retired the sitemap ping endpoint back in 2023, so a ping is a no-op.)
Q: How long until a 301 transfers the old page’s ranking? A: Google follows the redirect on the next crawl, but full canonical/signal consolidation typically takes 1-4 weeks as of June 2026. Single-hop redirects to a relevant page consolidate fastest; chains slow it down.
Q: What if a Core Update launches during my redesign? A: Bad timing, but separable. Compare each URL’s status (301 vs 404 vs noindex) for redesign damage, then compare impression changes across the Core Update window in the Performance report to isolate algorithmic impact. The two leave different fingerprints.
Q: Crawled - currently not indexed spiked — is that the redesign?
A: Often yes. It means Google fetched the page but judged it not worth indexing — usually thinner content, weaker titles/H1, or fewer internal links after the rebuild (causes 2, 3, 4). Strengthen those signals; don’t just spam Request indexing.
Related
External references: Page indexing report (Search Console Help), Redirects and Google Search.
Tags: #SEO #Google #Search Console #Indexing #Troubleshooting #Site redesign #Deindex