搜索引擎收录：功能开关导致页面变化时怎样记录版本状态
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /2e5a80b6f5ff.html
📄
搜索引擎收录：功能开关导致页面变化时怎样记录版本状态
当功能开关让同一 URL 的正文、链接或结构化数据发生切换时，单靠“当前页面快照”无法说明搜索引擎看到的是哪一版。可行做法是：把开关状态、生效时间、页面输出摘要和抓取证据绑定成一条版本记录，而不是只保存页面 HTML。但若开关切换发生在客户端且首屏输出不变，这套记录会失效，需要改为记录渲染后的差异。
先固定“开关状态 + 页面输出”这一对证据
功能开关本身不是收录问题的原因，无法追溯的开关状态才是。记录时至少包含四项：开关标识与取值、切换生效时间、该状态下返回给爬虫的页面输出摘要、以及对应时间的抓取响应。页面输出摘要不必保存整页 HTML，可保存正文首段、主链接列表、canonical 与 robots 元标签的取值。这样当收录表现变化时，能判断变化发生在开关切换前还是切换后。
实际动作：每次开关变更后，立即用同一 URL 请求一次并保存响应头与正文摘要，命名为“开关名-取值-时间”。结果是后续对比有基线，下一步才能判断异常是开关导致还是其他改动叠加。
服务端开关与客户端开关要分开记录
服务端开关改变的是返回给爬虫的 HTML，版本记录可以沿用上面的方法。客户端开关只改变浏览器渲染后的 DOM，原始响应可能完全一致。此时保存 HTML 摘要没有区分度，需要额外记录渲染后正文、链接和可见文本的差异，并注明该状态是否依赖脚本执行。
如果只记录 HTML 摘要，会出现两份记录完全相同、但用户与爬虫实际看到内容不同的情况。这个反例说明：记录方式必须与开关的作用层一致，否则版本状态看似完整，实际无法解释收录差异。
用时间线而不是单点快照串联版本
单个版本的记录只能回答“当时是什么”，时间线才能回答“哪次切换之后开始不同”。建议按以下顺序组织：
- 开关变更时间与操作人；
- 变更后首次抓取的时间与响应状态；
- 该次响应中的 canonical、robots 元标签与主链接；
- 若为客户端开关，补充渲染后正文摘要；
- 下一次开关变更前的最后一次抓取记录。
这样做的结果是把“页面变化”落到具体时间段，下一步排查可以缩小到某一次切换，而不是反复检查当前页面。
别把抓取限制或站点地图当成版本证据
robots.txt 的抓取限制不等于可靠的索引移除，它只能说明抓取行为受限，不能证明某个版本已被处理。站点地图也不保证收录，它更适合作为发现入口，而不是版本状态的证明。把这两类信号写进版本记录时，应标注为“辅助信号”，不能替代页面输出与抓取响应这一对核心证据。
假设某页面在开关 A 下返回精简正文，在开关 B 下返回完整正文，两次抓取都成功但记录里只写了“已提交站点地图”。这种情况下无法判断搜索引擎处理的是哪一版，站点地图提交量归零或抓取量下降也不能单独证明开关处理正确，还可能是抓取预算分配、其他 URL 竞争或响应变慢所致。
下一步：先确认开关作用层，再决定记录粒度
如果开关作用于服务端输出，按“开关状态 + 响应摘要 + 抓取时间”记录即可。如果开关作用于客户端渲染，必须增加渲染后差异记录，并确认该差异是否对爬虫可见。完成这一步后，再回看收录变化的时间点是否与某次开关切换重合；重合只能作为线索，仍需排除同期模板、链接或响应状态的其他改动。
