新页面发布之后，最常见的动作就是去搜索框里查一下，没看到就开始怀疑是不是被屏蔽了。这个动作本身没错，但判断标准往往是错的。搜索索引是一个异步过程，页面从被发出到出现在索引里，中间要经过发现、抓取、渲染、质量判断、入队等多个环节，任何一个环节慢一点，最终呈现的时间就会往后推。
所以真正需要先回答的问题不是为什么没收录，而是现在这个时间点，没看到到底算不算异常。把观察窗口定清楚，能省掉很多无效折腾。
索引流程本身就是异步的
一个 URL 从存在到进入索引，大致会经历下面几步：
- 被发现：通过内链、站点地图、外链或提交接口进入待抓取队列。
- 被抓取：蜘蛛实际取到服务器返回的内容，这一步可能失败或延后。
- 被渲染：如果是脚本渲染页面，还要走一遍渲染，渲染结果才参与后续判断。
- 被评估：和站内其他页面比较，判断是否是重复、薄弱或低价值版本。
- 被索引：进入索引库，才可能出现在 site 查询和索引报表里。
这几步没有一步是提交后立即完成的，尤其对权重一般、抓取频率不高的站点，队列排队的时间可能比抓取本身长得多。
延迟的正常区间大概是什么样
没有一个统一数字，但可以按站点情况估一个大致范围，作为观察窗口的参考：
- 抓取频繁、更新活跃的站点：新页面几小时到一两天进入索引比较常见。
- 普通内容站：几天到两周属于常见区间。
- 新站或长期不更新的站：两三周甚至更久都可能，属于抓取频率低导致的排队。
- 重要页面（首页、栏目页、有稳定内链入口的页面）：通常比深层页面快。
观察窗口建议按站点自身的历史节奏来定，而不是按别家站点。可以先翻一下过去一个月新页面的收录时间分布，取一个中位数，再往上留出缓冲。
分清延迟和漏收的核对顺序
窗口期内没看到，先按下面的顺序核对，不要跳步：
- 确认 URL 可被抓取：robots.txt、meta robots、X-Robots-Tag 三者是否放行，是否误加了 noindex。这一步是硬条件，不满足后面都不用看。
- 确认服务器返回正常：状态码是不是 200，有没有因为地域、UA、超时返回异常内容。
- 确认页面能被发现：是否有站内链接指向它，站点地图中是否包含且格式正确，链接是否是可抓取的 a 标签而非脚本事件。
- 确认内容不是重复版本：站内是否有其他 URL 承载同样正文，canonical 指向是否与预期一致。
- 看抓取记录：服务器日志里这个 URL 有没有被请求过。没被抓过，问题在发现和抓取；被抓过但没进索引，问题在评估环节。
- 交叉核对多个入口：site 查询、索引报表、抓取统计三者的口径不同，只看一个容易误判。
前四步是能不能，第五步开始才是为什么慢。
哪些信号说明真的需要动手
- 日志里完全没有抓取记录，且已经超过观察窗口。
- 服务器返回过 5xx 或大量超时，抓取被反复中断。
- 页面被明确返回 noindex，或 canonical 指向了另一个版本。
- 同类页面大多已收录，只有这一批长期没有动静，且这批页面有共同特征。
出现这些信号，才值得去改配置、补内链或调整结构。如果只是时间没到，反复提交、频繁改内容反而可能让页面看起来不稳定。
几个常见误判
- 用带引号的完整标题去搜，命中不了就判定没收录。实际上标题匹配和索引收录是两件事。
- 把 site 查询结果的数量当成精确值，用它来判断单个页面是否收录。
- 页面刚发布就反复修改标题和正文，导致蜘蛛每次抓到的都是不同版本。
- 把已发现未索引直接等同于被惩罚，忽略抓取预算和队列排队的因素。
把观察窗口定清楚，把核对顺序排好，很多没收录的焦虑会自己消失。真正需要处理的，往往只是其中一小部分。