收录提交：功能开关导致页面变化时怎样记录版本状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b9cd80b400da.html
📄
收录提交：功能开关导致页面变化时怎样记录版本状态
当页面由功能开关控制、同一 URL 会随开关状态呈现不同内容时，记录版本状态的关键不是保存每次页面快照，而是把「开关状态 + 生效时间 + 该状态下可被抓取的可见内容特征」绑定成一条可追溯记录。只存 HTML 快照会很快失效，只存开关配置又无法证明当时页面实际输出过什么。
先判断你的开关属于哪一类，再决定记录粒度
两种条件对应两种完全不同的记录方式，选错会让后续排查失去参照。
- 条件一：开关只影响局部模块，例如某个推荐位、价格区块或评论区的显示与隐藏，主体内容不变。此时记录粒度可以停在「开关名 + 状态值 + 切换时间 + 受影响的 DOM 区域标识」。
- 条件二：开关会改变主体内容或渲染路径，例如整页走不同模板、不同数据源，甚至服务端渲染与客户端渲染切换。此时必须额外记录该状态下页面首屏可抓取的正文特征，比如标志性标题文本、结构化数据字段值、关键链接集合的哈希。
判断依据很简单：如果关掉开关后页面正文与之前高度重合，属于条件一；如果关掉后正文、内链甚至状态码都可能变化，属于条件二。条件二下，仅记录开关配置不足以还原当时给抓取端呈现的内容。
把版本记录做成「状态指纹」而非快照堆叠
可用的记录应包含四类字段：开关标识与取值、状态生效的起止时间、该状态下页面抓取可见内容的指纹、以及采集指纹时使用的 UA 与是否执行 JS。
指纹不必是完整 HTML。对条件一，取受影响区域的文本摘要加链接列表即可；对条件二，取正文首段文本、主标题、canonical 值、结构化数据类型与关键内链路径集合。把这几项拼成一个稳定字符串再做哈希，体积小且便于比对。
实施动作示例：在开关切换的发布流程里加一步，切换后由采集脚本以固定 UA 请求该 URL，提取上述字段并写入版本日志，字段包括时间戳、开关名、取值、指纹哈希、采集方式。这样当后续出现「页面内容与预期不符」时，你能直接回答「在某个时间点、某个开关状态下，抓取端看到的是哪一版」。
这一步的结果会直接影响下一步判断：如果指纹与当前线上一致，说明问题出在开关未按预期生效或缓存层；如果指纹与当前线上不一致，说明页面输出确实变了，需要回到开关发布记录里找变更点。
区分「抓取端可见」与「用户可见」两种记录
功能开关常配合前端渲染，用户看到的内容可能依赖登录态、地域或 A/B 分桶，而抓取端拿到的往往是默认分支。记录时必须明确标注采集条件，否则两份数据会互相污染。
建议至少维护两条记录线：一条是默认抓取条件下的指纹，用于和收录提交流程对齐；另一条是带特定上下文（如登录、指定分桶）的指纹，仅用于排查用户侧反馈。不要把带登录态的页面内容当作收录提交依据，两者适用条件不同。
例外情况：如果页面主体内容完全由客户端异步加载、且默认抓取条件不执行 JS，那么默认指纹可能只包含骨架。此时应在记录中注明「未执行 JS」，并额外记录执行 JS 后的指纹作为对照，但不要用后者替代前者去判断抓取端实际可见内容。
提交与复核时如何使用这些记录
当你准备对变化后的页面做收录提交，先核对当前开关状态对应的指纹是否已入库。若缺失，先补记再提交，否则提交后无从判断返回结果对应哪一版。
复核阶段，把提交时间点前后的指纹做对比：
- 提交前指纹与提交后指纹一致，且页面输出未变，说明变化未发生，应检查开关是否真的切换成功。
- 提交前指纹与提交后指纹不同，说明页面确实变了，此时再结合抓取日志判断抓取端是否已获取新版。
- 指纹相同但抓取日志显示旧内容，优先怀疑缓存或 CDN，而不是开关本身。
需要提醒的是，抓取量或某类请求归零并不能单独证明处理正确，它也可能来自抓取预算调整、站点整体流量波动或 robots.txt 限制变化；站点地图存在也不保证收录。这些信号只能作为辅助，最终判断仍要回到「开关状态与页面可见内容是否对应」这条主线上。
假设一个短例子：某页面开关控制价格表显示，开关 A 关闭时价格表隐藏。你在关闭状态下记录指纹为 H1，随后提交。三天后发现抓取端仍返回含价格表的版本。此时对比指纹，若当前抓取指纹等于开启状态下的 H2，说明开关未生效或被缓存覆盖，下一步应检查开关发布链路与缓存刷新，而不是重复提交。
把版本状态记录挂到开关发布流程里，而不是事后补记，才能在页面随开关变化时始终保留一条可对照的证据链，让收录提交的每一步都有据可查。
