一个本来收录、有排名、带流量的页面，某天突然消失。site:yourdomain.com/that-url 搜不到，URL Inspection 显示 “URL is not on Google”，而且不是 noindex、不是 404、也没有被 robots.txt 屏蔽。这是 Google 主动把它移出了索引（deindex）。
最快的判断路径：在 Search Console 的 URL Inspection 里查这个 URL，看它给的确切状态。如果是 Excluded by 'noindex'、Not found (404) 或 Blocked by robots.txt，那就是技术回归——修好服务端/模板，再点 “Request indexing”，通常一两天内会重新抓取。如果显示 Crawled - currently not indexed，或者只有一句 URL is not on Google 而没有任何技术原因，那就是质量/算法层面的判定，唯一真正有效的办法是把页面做得确实更好，然后等上几周。
这跟”从未收录”完全是两回事。它以前能进、现在进不去，意味着要么你改了什么，要么 Google 对你整站的评估变了。下面的排查会帮你快速分清这两种情况，再分别修。
先确认：是不是 2026 年这波 deindex 潮
在怀疑自己代码之前，先看时间点。截至 2026 年 6 月，有一波被广泛报告、仍在持续的 deindex 现象：
- March 2026 Core Update（2026 年 3 月核心更新）于 3 月 27 日开始推送、4 月 8 日完成——多个 SEO 监测方称它是有记录以来最剧烈的核心更新之一。
- 从 2026 年 4 月底起，大量站长报告原本稳定的页面集体翻成
Crawled - currently not indexed或Excluded，既没有 manual action 也没有抓取错误。这波讨论由前 Google 员工 Pedro Dias 发起，他问大家是不是也看到 deindex 比例升高，结果几乎一边倒地说”是”。 - Google 的态度：John Mueller 在 Bluesky 上说 “Some sites go up, some sites go down. I don’t see anything exceptional there.”（有的站涨、有的站跌，我没看到什么异常。）Google 没有承认索引行为有任何变化。
对你的意义：如果是很多页面在这些日期附近同时掉，且没有 noindex/404/robots 的原因，就把它当成算法问题，而不是一个等着打补丁的 bug。不要批量给页面加 noindex、不要改 URL 路径、不要为了”重置”而重建站点结构——这些动作可能把暂时的下滑变成永久性损伤。动手之前，先把你掉页的日期和 Google 更新列表 以及 searchengineroundtable.com 对一下。
常见原因
1. 技术回归：noindex / 404 / redirect 意外加上
最容易漏掉，也最容易修。常见场景：
- 模板改动加了
<meta name="robots" content="noindex">，但没人发现 - 某次部署改了服务端配置，这个 URL 现在 301 到别处
- CMS 升级后这一类页面默认变成 draft / private
- canonical 被改成指向另一个 URL
如何判断：
# 看页面是否真的可访问且 200
curl -sI https://yourdomain.com/that-url | head -5
# 看有没有 noindex（同时检查 X-Robots-Tag 响应头）
curl -sL https://yourdomain.com/that-url | grep -i noindex
curl -sI https://yourdomain.com/that-url | grep -i x-robots-tag
# 看 canonical 是不是指向自己
curl -sL https://yourdomain.com/that-url | grep -oE '<link rel="canonical" href="[^"]+"'
# 看 robots.txt 是否屏蔽
curl -s https://yourdomain.com/robots.txt | grep -E "Disallow.*your-url"这里任意一项有问题就是根因。注意：noindex 既可能在 HTML head 里，也可能放在 X-Robots-Tag HTTP 响应头里——上面第二条命令就是为了抓后者。只看网页源代码是发现不了头部里的 noindex 的。
2. 合并 / 重组时选了别的 URL
如果你最近合并了相似文章、改了 URL 结构、做了大量 301——Google 在重新评估时，可能把你某个想保留的 URL 标成”合并到 X”，然后移除原 URL。
如何判断：Search Console → URL Inspection → 看 “Google-selected canonical”。如果它指向另一个 URL，就是 Google 把它合并了。
3. 全站质量评估变化（核心更新）
Google 每年做几次大规模更新（核心更新、垃圾内容更新；独立的 “Helpful Content Update” 已在 2024 年并入核心排名系统）。如果很多页面同时 deindex，且时间点对得上某次已知推送，那就是算法层面的重新评估，不是 bug。
如何判断：去 Google Search Status Dashboard 或 searchengineroundtable.com 查最近的推送，和你 deindex 的日期对比。
4. 内容被判为 “unhelpful / 低价值”
跟 #3 相关，但更具体。最容易中招的页面：
- 大量 AI 批量生成、没人编辑也没核实的内容
- 跟其他站（或跟你自己其他页面）高度雷同的内容
- 第一段就是泛泛而谈的套话
- 没有第一手信息、独有数据或真正的专业度
5. 域名被罚（Manual Action）
少见但严重。Search Console → 安全和手动操作 → 手动操作。这里有任何提示，都是人工下发的处罚。常见诱因：买外链、cloaking、薄附属内容、不自然链接。手动操作会写明具体原因并带一个 “Request Review” 按钮——算法降权从来不会有。
6. 服务器持续 5xx 错误
如果某段时间你的服务器频繁返回 500/503/504，反复抓取失败会让 Google 暂时移除页面。错误停止后，通常 1-2 周内自动恢复。
如何判断：Search Console → 设置 → 抓取统计信息 → 看”按响应”里是不是有一波 5xx。
7. 重复内容被合并到别处
跟 #2 类似，但场景是”你的页面跟别的站太像”，于是 Google 选了别人作为 canonical。常见于联合发布或被抓取后转载的内容。
最短修复路径
Step 1：用 URL Inspection 看 Google 给的确切状态
打开 Search Console → 顶部搜索框 → 输入丢失的 URL → 等结果出来。看：
- Page indexing——什么状态？
- Last crawl——上次抓取是什么时候？
- User-declared canonical 对比 Google-selected canonical——两者是否不一致？
- Indexing allowed?——是不是 “No”？
按状态对应修法：
| URL Inspection 里的状态 | 可能原因 | 修法 |
|---|---|---|
Excluded by 'noindex' | 你加了 noindex（head 或 X-Robots-Tag） | 删掉这个标签/响应头 |
Not found (404) | URL 真坏了 | 修服务端 / 恢复路由 |
Blocked by robots.txt | robots.txt disallow | 改 robots.txt |
Alternate page with proper canonical tag | 你自己的 canonical 指向别处 | 修 canonical |
Duplicate, Google chose different canonical | 被合并到另一个 URL/站点 | 加强信号，或接受合并 |
Crawled - currently not indexed | 质量 / 价值判定 | 加深页面，见 Step 6 |
URL is not on Google（无明确原因） | 核心更新评估 | 整站质量改进 |
Step 2：检查 server / canonical / robots.txt 三个技术点
# 一键检查脚本
URL="https://yourdomain.com/lost-page"
echo "=== HTTP 状态 ==="
curl -sI "$URL" | head -3
echo "=== noindex（HTML + 响应头）==="
curl -sL "$URL" | grep -i noindex || echo "HTML 里无"
curl -sI "$URL" | grep -i x-robots-tag || echo "无 x-robots-tag 头"
echo "=== canonical ==="
curl -sL "$URL" | grep -oE '<link rel="canonical" href="[^"]+"' || echo "无"
echo "=== robots.txt 是否屏蔽 ==="
PATH_PART=$(echo "$URL" | sed 's|https\?://[^/]*||')
curl -s "$(echo $URL | grep -oE 'https?://[^/]*')/robots.txt" | grep -E "Disallow.*$PATH_PART" || echo "未屏蔽"这里任何一项异常都先修这一项，再去假设质量问题。
Step 3：对比丢失 URL 的内容与历史版本
打开 Wayback Machine，把丢失之前的快照和现在的页面对比：
- 字数减少了吗？
- 主题变了吗？
- 关键信号（H1、title、主图）改了吗？
如果某次重写把页面改薄了、或换了主题，那很可能就是 deindex 的直接原因。把丢掉的实质内容补回来。
Step 4：核对核心更新的时间窗
把 Google 最近 90 天的公告和你的 deindex 日期对照：
- March 2026 Core Update（2026 年 3 月 27 日 – 4 月 8 日）
- 状态面板 上任何垃圾内容更新或未公告的排名波动
如果你的 deindex 日期落在某次推送窗口内（核心更新一般持续 1-3 周），就按算法问题处理。技术修复对它没用，只有整站质量改进才有效。
Step 5：如果是技术回归，修完再 Request indexing
删掉 noindex、修好 canonical、或恢复 404 的路由之后，先在 URL Inspection 里点 “Test Live URL” 确认页面现在能通过，再点 “Request indexing”。Google 通常一两天内重新抓取。（Request indexing 有每日配额，所以把它用在真正重要、已修好的 URL 上，别整站乱点。）
Step 6：质量问题靠的是几周，而不是一个按钮
如果是 Crawled - currently not indexed 或核心更新导致的掉页，没有捷径。Google 自己的说法：改进”可能几天就生效，也可能要几个月”；如果几个月后仍无变化，你可能得等下一次核心更新——而且没有保证。具体做法：
- 把最薄的那 20% 页面合并或加
noindex，让抓取力气集中到值得留的页面上 - 给保留的页面加上只有你能提供的东西：原创案例、独有数据、第一人称经验、真实的对比表
- 收紧内链，让保留页面距离首页不超过 2-3 次点击
- 拿 3-5 条相关的新外链
- 查 Core Web Vitals（Search Console → 核心网页指标，外加 PageSpeed Insights），修掉糟糕的 LCP / CLS——这是一个便宜又真实的清理信号
实际情况是：掉的页面里有相当一部分往往要等到下一个抓取周期或下次更新才会回来——通常是 4-12 周，而不是几天。
怎么确认已经修好
- 对受影响的 URL 重新跑一次 URL Inspection。技术修复的话，“Test Live URL” 现在应该显示 “URL is available to Google”。
- 点完 “Request indexing” 后过一两天，状态应变成
URL is on Google（或Submitted and indexed）。 site:yourdomain.com/that-url又能搜到这个页面了。- 在 Search Console → Indexing → Pages 里，已收录页面数停止下滑并开始回升。
如果 URL Inspection 的实时测试能通过、但页面过了两周还是进不了索引，那原因就是质量/算法，而不是技术——回到 Step 6。
预防建议
- 每周看一次 Search Console → Indexing → Pages → 已收录数量趋势；跌幅超过 10% 就要排查
- 每次部署后对关键页面做冒烟测试：curl 验证 200 + 无
noindex（head 和响应头都查）+ canonical 正确 - CMS 升级或模板改造前，先备份当前的 sitemap 和已收录数量，事后好做对比
- 加一个每日 CI 健康检查：抽样约 50 个生产 URL，断言 200 + 无
noindex - 每次 Google 核心更新公告都记下日期，将来掉页时方便归因
常见问题
“deindex” 等于被处罚吗？ 不等于。处罚（manual action）会在 Search Console → 安全和手动操作里给出明确提示，带原因和一个 “Request Review” 按钮。2026 年大多数 deindex 是算法层面的——是一种质量判定，没有提示，也没有复审按钮。
我的页面正好在 March 2026 核心更新前后掉的，要赶紧改东西吗？
不要。Google 和大多数从业者都反对那种应激式动作，比如批量加 noindex、改 URL、或为了”重置”页面而重建结构——它们可能把暂时的下滑变成永久的。先确认没有技术回归，把最弱的页面认认真真改好，然后等推送结束。
修好的页面多久能回来？ 技术修复加上 “Request indexing”，通常一两天内重新抓取。质量恢复要按周算：Google 说从几天到几个月不等，你甚至可能得等下一次核心更新，且没有保证。
如果原因是质量，“Request indexing” 有用吗？ 几乎没用。它只是催 Google 重新抓取，但如果页面被判为低价值，抓完还是会被丢掉。先把页面做好，再请求收录。
为什么只有部分页面掉了，其他没事？ 算法质量评估是页面级、栏目级的。薄的、重复的、模板化严重的页面先掉；有原创深度和外链的页面活下来。这个分布本身就是在告诉你该往哪里投入。
怎么检查那种在源代码里看不到的 noindex？
noindex 可以通过 X-Robots-Tag HTTP 响应头下发，而不是 HTML meta 标签。跑 curl -sI https://yourdomain.com/that-url | grep -i x-robots-tag 就能抓到。