刚做完一次大改版（新模板、新结构、可能改了 URL）2-4 周后，Search Console 报告 Indexed 页数掉了 20-60%。心慌之前先搞清楚：改版后头一个月的下降是正常的，Google 在重新评估。但 8 周后还在跌就是结构性问题。
下面是怎么区分两种情况，以及对结构性问题的精准修法。
症状
- Pages 报告改版后 2-4 周内 Indexed 下降 20%-60%
- 部分 URL 被重分类为 “Crawled - currently not indexed”
- 部分 URL 直接掉了（变 “URL is not on Google”）
- Performance 流量同期下降但幅度不一定一致
快速结论
改版会触发整站重新评估。前 4-8 周下降是正常的；8 周后仍持续下降说明有结构性问题。
常见原因
1. URL 改了但没有 301 到新等价 URL
最致命也最高发。从 /blog/2024/post-name/ 改到 /articles/post-name/ 后：
- 老 URL 收录 → 现在 404 → Google 移除
- 新 URL 没历史信号 → 排名打回 0
如何判断：
# 抽样老 URL 看状态
for url in "/old/url1" "/old/url2"; do
echo "$url: $(curl -sI "https://yourdomain.com$url" | head -1)"
done
# 期望 301 到新 URL；404 / 200 都是问题2. title / H1 / meta 变得更通用 / 更弱
模板重做时常见错误：
旧 H1: "Astro 部署 Vercel 完整指南：17 分钟搞定"
新 H1: "完整指南" ← 通用化
旧 title: "Astro Deploy Vercel — 17 minute walkthrough | YourSite"
新 title: "Article | YourSite" ← 模板化Google 重新评估时认为新版本信息密度不足，降权。
3. 内链结构被压扁或削弱
- 原来”相关文章”区列 5 条 → 新模板列 2 条
- 原来面包屑链分类页 → 新模板用面包屑文字
- 原来 sidebar 列最新 20 篇 → 新模板没 sidebar
每减少一处内链，对应文章的”重要性投票”减一票。
4. 新模板引入薄页面
新模板加了”作者主页”、“tag 页”、“按月归档页”等大量低质量页。它们抢走 crawl budget，正经文章被降优先级。
5. Robots.txt 或 noindex 规则被过度应用
改版时一次性加了大量 noindex / robots 规则，本意是清理薄页，结果不小心把真正想收录的页也屏蔽了。
如何判断：
# 看 robots.txt 变了多少
diff <(curl -s old-robots.txt) <(curl -s new-robots.txt)6. JS 渲染 SEO 化倒退
旧模板是 SSR / SSG，新模板换成 CSR React → Google 看到的所有页都是空 HTML，大规模降权。
7. CSS / JS 资源被 robots.txt 屏蔽
新模板用了新的 CSS / JS bundle 路径，但 robots.txt 还在屏蔽老路径——Google 抓不到样式，判定页面”破损”。
最短修复路径
Step 1：导出改版前后的 Pages 报告
Search Console → 页面 → 导出 → CSV
分别导出改版前 7 天和改版后 4 周
diff 两份 CSV 找出掉的 URL如果之前没存改版前数据，去 Wayback Machine 抓你 Search Console 截图，或用 ahrefs / Semrush 历史曲线。
Step 2：对每个掉的 URL 验证 HTTP 状态
# 把掉的 URL 列在 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：要么补回页面，要么 301 到等价新 URL
- 301：检查目标 URL 是不是真等价 + 是不是 200
- 200：技术上没问题，看 Step 3
Step 3：对比改版前后的 title / H1 / meta
# 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[^>]*>[^<]+'
# 对比当前
curl -sL "https://yourdomain.com/article" | grep -oE '<title>[^<]+'
curl -sL "https://yourdomain.com/article" | grep -oE '<h1[^>]*>[^<]+'标记变得更通用 / 更弱的 → 补回原版风格。
Step 4：审受影响 URL 的内链数量
# 用 rg 看新模板下，掉的 URL 还有多少内链
while read url; do
count=$(rg -c "href=\"$url\"" src/ | wc -l)
echo "$url $count"
done < lost-urls.txt内链数比改版前少 → 在相关页面恢复内链。
Step 5：检查 robots.txt + noindex 是否过度
# 看 robots.txt 现在屏蔽哪些
curl -s https://yourdomain.com/robots.txt
# 看 noindex 在多少页面上
for url in $(head -20 lost-urls.txt); do
noindex=$(curl -sL "https://yourdomain.com$url" | grep -c noindex)
echo "$url noindex=$noindex"
done意外的 noindex → 删除 → Request indexing。
Step 6：检查 SSR/SSG 倒退
# 关 JS 看页面
curl -sL "https://yourdomain.com/article" > raw.html
wc -c raw.html
# 内容大小 < 5KB 多半是空壳
grep -c "<article" raw.html
# 0 = 内容不在初始 HTML如果是，重做 SSR 或 pre-render。
Step 7：等 4-8 周再做精准修复
修完 Step 1-6 的明确问题后，等。改版后头 4-8 周的下降是正常的重新评估期，频繁改动会让归因不可能。
8 周后还跌：
- 重新跑诊断
- 看是不是 Core Update 同期叠加
- 考虑回滚某些改动
哪些情况可能不是你操作错了
改版后头一个月 20-30% 临时下降是正常的，会随 Google 重爬恢复。耐心 + 不再叠加改动是最好的修复。
容易误判的情况
- 一慌就再次改版：叠加改动让诊断不可能
- 以为流量降一定要回滚：先等 4-8 周
- 改 robots / canonical 跟改版无关：除非诊断指向那里
- 以为 Request indexing 能加速：每天配额 10 个 URL，整站 1000+ 杯水车薪
预防建议
- 改版分阶段：先结构，再视觉，再内容模板，不要一次全改
- 上线前把每个旧 URL 映射到新 URL，重定向清单进版本控制
- 改版前 export Search Console 当前数据，便于后续对比
- 改版前后 7 天关键页面跑 Lighthouse + 抓取 + curl 验证
- 给改版留 8 周观察窗，期间避免大规模再改
FAQ
Q：掉页就回滚吗？ A：不要——先等 4-8 周。回滚也要付一次重新评估周期。
Q：需要重交 sitemap 吗？ A：要——尤其是 URL 改了。删旧 sitemap，提交新 sitemap。
Q：改版同时 Core Update 上线怎么办？ A：糟糕的运气。把改版受影响 URL 和 Core Update 期间的曝光变化分开归因——通过对比改版前后 URL 的 status，以及对比时间窗口。