每个站点都会丢已收录页面。多数时候是噪音;偶尔是某个会让你损失真实流量的问题的第一个信号——难就难在第一天里两者长得一模一样:这条 URL 昨天还被收录,今天没了。
做出正确判断需要区分四种完全不同的成因。
1. 你的变更
你发布了什么。一个有漏洞的重定向映射、一次把某栏目 noindex 的模板改动、一次 canonical 翻转、一次让爬虫看到空页面的渲染回归。这是最好的成因,因为它是你的:回滚或修复,索引几天内就会跟上。
特征:掉出的事件簇与发布时间吻合。如果你的监控只看索引,你会把自己的发布怪到 Google 头上。把部署日志放在覆盖率历史旁边。
2. 质量重评
Google 在持续重评页面。一次菜单改版后失去内链的页面、被更新页面重复的页面、一年里积累大量单薄内容的栏目——重评的落地比实际成因晚几周。
特征:掉出跨越多次抓取仍然持续,并且影响共享同一弱点的页面。孤例会回来;一整类 URL 不会。
3. Google 侧的波动
索引构成会变化。canonical 选择会被重新评估,去重决策会被重新调整,在已确认的索引事件期间,大量页面——包括健康的页面——会掉出去,几天后常常自己回来。
特征:掉出范围广、不集中在你的薄弱点,并且会反转。这就是为什么"再等一次抓取"确实是好建议——前提是你已经排除了成因 1。
4. 抓取与服务故障
爬虫上一次到访时拿到的是错误页、超时或降级渲染。页面本身没问题,是那次抓取出了问题。下一次抓取就会修复。
特征:孤立 URL、判定混杂(一些变成"已抓取暂未收录",一些变成"服务器错误")、快速自愈。
实际该做什么
按顺序:
- 先查部署日志。 把掉出时间戳与发布对齐。如果与某次发布吻合,别去翻论坛,去翻 diff。
- 数一数事件簇的规模。 五条 URL 是噪音;五百条共享同一模板的 URL 是成因 2 的信号。不分好坏全面掉出,指向成因 3。
- 看状态变化,不看快照。 一条 URL 掉出又回来两次是故障(成因 4);掉出后不回来是决策(成因 2)。任何只展示"今天状态"的报告都看不到这些——你需要逐 URL 的历史。
- 然后才动手改。 在成因 3 的波动期间做出的每一次应激的全站变更,代价都超过波动本身。
不可接受的部分
波动是正常的。**六周后才发现不是。**昂贵的场景不是掉出本身——而是某个赚钱页面在成因 2 期间掉出,直到一个月后流量图追上来才被人发现。
这正是 indexsubmit 要补的缺口:每条被监控 URL 的判定每天记录,状态变化触发告警(已收录页面掉出、或开始返回 404),30 天趋势能在你动手之前区分"Google 在洗牌"和"我们的模板坏了"。
如果你曾经靠运气发现某个关键页面死掉了,设置好告警——下一次,你会是第一个知道的人。