Indexing Coverage Drops After a Site Redesign

After redesigning the site, the indexed page count drops in Search Console. What is real damage vs. normal re-evaluation.

You just shipped a major redesign (new templates, new structure, possibly new URLs) and 2-4 weeks later Search Console says Indexed page count is down 20-60%. Before panicking: the first month’s drop is normal — Google is re-evaluating. But if it’s still dropping after 8 weeks, that’s a structural issue.

Below: how to distinguish the two cases, and targeted fixes for structural issues.

Symptoms

  • Pages report shows -20% to -60% Indexed pages over 2-4 weeks post-redesign
  • Some URLs reclassified as “Crawled - currently not indexed”
  • Other URLs dropped entirely (become “URL is not on Google”)
  • Performance traffic down in same window, but proportionally different

Quick verdict

Redesigns trigger a re-evaluation of the whole site. Drops in the first 4-8 weeks are normal; persistent drops after week 8 indicate a real structural issue.

Common causes

1. URLs changed without 301 to new equivalents

Most fatal, most common. Going from /blog/2024/post-name/ to /articles/post-name/:

  • Old URL was indexed → now 404 → Google removes
  • New URL has no historical signal → ranking starts from zero

How to confirm:

# Sample old URLs and check status
for url in "/old/url1" "/old/url2"; do
  echo "$url: $(curl -sI "https://yourdomain.com$url" | head -1)"
done

# Want 301 to new URL; 404 / 200 are both problems

2. title / H1 / meta got more generic / weaker

Common template redo mistake:

Old H1: "Astro Deploy Vercel Complete Guide: 17-Minute Setup"
New H1: "Complete Guide"  ← genericized

Old title: "Astro Deploy Vercel — 17 minute walkthrough | YourSite"
New title: "Article | YourSite"  ← templated

Google’s re-evaluation flags lower information density and demotes.

  • “Related articles” used to show 5 links → new template shows 2
  • Breadcrumbs used to link the category page → new template renders text only
  • Sidebar used to list 20 recent → new template has no sidebar

Every internal link removed = one less “importance vote” for the destination article.

4. New template introduced thin pages

The new template adds lots of low-quality pages: author pages, tag pages, monthly archive pages. They steal crawl budget, your real articles get deprioritized.

5. Robots.txt or noindex over-applied

During redesign you added many noindex / robots rules to clean up thin pages, but accidentally blocked pages you wanted indexed.

How to confirm:

# How much did robots.txt change?
diff <(curl -s old-robots.txt) <(curl -s new-robots.txt)

6. SSR / SSG regression

Old template was SSR / SSG, new template switched to CSR React → Google sees empty HTML on every page, mass demotion.

7. CSS / JS resources blocked by robots.txt

New template uses new CSS / JS bundle paths, but robots.txt still blocks the old ones — Google can’t fetch styles, judges pages as “broken.”

Shortest path to fix

Step 1: Export pre-redesign Pages report

Search Console → Pages → Export → CSV
Export 7 days pre-redesign and 4 weeks post-redesign
Diff to find dropped URLs

If you didn’t save the pre-redesign data, check Wayback Machine for Search Console screenshots, or ahrefs / Semrush historical curves.

Step 2: Verify HTTP status for each dropped URL

# Put dropped URLs in lost-urls.txt
while read url; do
  status=$(curl -sI "https://yourdomain.com$url" -o /dev/null -w "%{http_code}")
  echo "$url $status"
done < lost-urls.txt > status.txt
  • 404: either restore the page, or 301 to the equivalent new URL
  • 301: check that the target is truly equivalent + 200
  • 200: technically fine, see Step 3

Step 3: Compare title / H1 / meta before vs. after

# Pull pre-redesign snapshot from Wayback Machine
WAYBACK="https://web.archive.org/web/2026*/https://yourdomain.com/article"

curl -sL "$WAYBACK" | grep -oE '<title>[^<]+'
curl -sL "$WAYBACK" | grep -oE '<h1[^>]*>[^<]+'

# Compare with current
curl -sL "https://yourdomain.com/article" | grep -oE '<title>[^<]+'
curl -sL "https://yourdomain.com/article" | grep -oE '<h1[^>]*>[^<]+'

Flag anything more generic / weaker → restore original style.

# rg to count internal links to each dropped URL in the new template
while read url; do
  count=$(rg -c "href=\"$url\"" src/ | wc -l)
  echo "$url $count"
done < lost-urls.txt

Internal link count down vs. pre-redesign → restore links from related pages.

Step 5: Check robots.txt + noindex over-application

# What robots.txt currently blocks
curl -s https://yourdomain.com/robots.txt

# Count noindex on dropped pages
for url in $(head -20 lost-urls.txt); do
  noindex=$(curl -sL "https://yourdomain.com$url" | grep -c noindex)
  echo "$url noindex=$noindex"
done

Accidental noindex → remove → Request indexing.

Step 6: Check SSR / SSG regression

# View page without JS
curl -sL "https://yourdomain.com/article" > raw.html
wc -c raw.html

# < 5KB content is mostly a shell
grep -c "<article" raw.html
# 0 = content not in initial HTML

If so, re-introduce SSR or pre-render.

Step 7: After Steps 1-6, wait 4-8 weeks

After fixing the clear problems, wait. The first 4-8 weeks of decline is normal re-evaluation. Frequent changes make attribution impossible.

Still dropping after 8 weeks:

  • Re-run diagnostics
  • Check if a Core Update happened in the same window (compounding)
  • Consider rolling back specific changes

When this is not on you

A 20-30% temporary drop in the first month is normal for any redesign. Usually recovers as Google re-crawls. Patience + not stacking changes = best fix.

Easy to misdiagnose

  • Panic-redesigning again: layered changes make diagnosis impossible
  • “Traffic drop means rollback”: wait 4-8 weeks first
  • Editing robots / canonical reflexively: only do this if diagnostics point there
  • Thinking Request indexing accelerates recovery: 10 URLs/day quota, useless for 1000+ URL sites

Prevention

  • Redesign in stages: structure first, then visual, then content templates — never all at once
  • Map every old URL to a new URL pre-launch; keep the redirect list in source control
  • Export Search Console current data before redesign for later comparison
  • Pre + post 7-day Lighthouse + crawl + curl verification on critical pages
  • Reserve an 8-week observation window post-redesign; avoid large re-changes

FAQ

Q: Should I roll back if pages drop? A: No — wait 4-8 weeks first. Rollback also costs a re-evaluation cycle.

Q: Do I need to resubmit the sitemap? A: Yes — especially if URLs changed. Delete the old sitemap, submit the new one.

Q: What if a Core Update launches during the redesign? A: Bad luck. Separate redesign-affected URLs from Core-Update-window impression changes by comparing URL status pre/post and across time windows.

Tags: #SEO #Google #Search Console #Indexing #Troubleshooting #Site redesign #Deindex