搜索引擎不收录 怎样排除缓存造成的假象 - 缓存排查清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a60d332179a6.html
📄
搜索引擎不收录 怎样排除缓存造成的假象 - 缓存排查清单
要排除缓存造成的假象，核心是同时查三件事：搜索引擎结果页显示的是不是旧版本、抓取工具拿到的是不是旧响应、源站是否真的已经更新。三者中只要有一处仍返回旧内容，就不能把“不收录”认定为索引问题。下面按观察、判断、处理、复查四步展开，适合多人协作时直接作为交付清单使用。
观察：先分清三种“看起来没收录”
多人协作时最常见的问题是各自看的地方不同。有人看搜索结果页，有人看抓取工具，有人看服务器日志，结论自然对不上。先把现象归到下面三类之一：
- 搜索结果显示旧标题或旧摘要，但页面本身已改。这通常是结果页缓存，不是索引未更新。
- 抓取工具返回旧内容，源站直接访问却是新内容。这通常是CDN、反向代理或页面级缓存。
- 源站、抓取工具、搜索结果页都返回旧内容。这更可能是发布流程没生效，而不是缓存。
判断依据是“同一时刻、同一URL、不同位置拿到的内容是否一致”。如果只在一个位置看到旧内容，先不要动索引相关设置。
判断：用可复现的方式确认缓存层
不要凭感觉说“应该是缓存”。用下面这组检查项逐条确认，每项都记录时间、URL、执行人和结果，方便交接：
- 直接在浏览器无痕窗口打开目标URL，查看页面源码中的关键字段（标题、正文首句、更新时间）。这是源站或边缘节点的实际响应。
- 在抓取工具的“查看抓取内容”或等效功能里，对比同一URL返回的HTML。如果这里与无痕窗口不一致，缓存层基本可以定位。
- 检查响应头中的缓存相关字段，例如
Cache-Control、Age、X-Cache、CF-Cache-Status。出现较大的Age或命中标记，说明响应来自缓存。 - 用带随机查询参数的URL访问，例如在地址后加
?v=20240601。若带参数返回新内容、不带参数返回旧内容，说明缓存键没有随内容更新。
这里要区分“可能原因”和“已经定位的原因”。Age 较大只能说明响应经过缓存，不能直接断定是CDN还是页面插件造成的。需要继续看响应头来源或逐层绕过，才能确定具体缓存位置。
处理：按缓存层级依次清理
确认缓存层后，按由外到内的顺序处理，避免一次改动多处导致无法归因：
- CDN或边缘缓存：对该URL执行刷新或清除，只清目标URL，不要一上来全站清除。
- 反向代理或页面缓存插件：清除单页缓存，并检查缓存规则是否把更新后的页面继续标记为可长期缓存。
- 对象存储或静态资源层：如果HTML本身托管在对象存储上，确认发布流程是否覆盖了旧文件。
- 浏览器本地缓存：用无痕窗口或强制刷新验证，排除本地因素。
清理后立即用第2步的抓取工具重新获取一次。如果返回内容已更新，说明问题在缓存；如果仍未更新，继续查发布流程和源站文件，而不是继续清缓存。
复查：确认收录状态而不是只看一次
缓存清理不等于收录完成。复查时注意三点：
- robots.txt 的抓取限制不等于可靠的索引移除，反过来，放开抓取也不保证马上收录。
- 站点地图不保证收录，它只帮助发现URL，不能替代抓取和索引判断。
- HTTPS 不保证安全无漏洞或排名，它只是传输层条件，与缓存假象无关，不要混进本次排查。
复查动作：在清理缓存后的不同时间点，分别用抓取工具和搜索结果页核对同一URL的标题与摘要。如果抓取工具已返回新内容、结果页仍显示旧摘要，属于结果页展示延迟，继续等待并保持URL可抓取即可。如果抓取工具也返回旧内容，回到处理环节，检查是否还有未清理的缓存层。
多人协作时的交付方式
为减少返工，把每次排查写成一条记录：URL、发现时间、各位置返回的内容版本、执行的清理动作、复查结果、下一步负责人。判断标准只有一条：同一URL在源站和抓取工具中返回的内容是否一致。一致但未收录，才进入索引相关排查；不一致，就继续处理缓存。下一步可以直接用这份清单跑一遍目标URL，把结果填进记录再决定是否上报索引问题。
