爬虫控制：功能开关导致页面变化时怎样记录版本状态
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /11653048b44a.html
📄
爬虫控制：功能开关导致页面变化时怎样记录版本状态
结论是：把“开关状态”当作独立版本维度记录，而不是只记录代码提交或页面快照。具体做法是，每次开关变更都生成一条包含开关名、取值、生效时间、影响URL范围和验证方式的记录，并与当时的响应头、渲染后HTML、robots规则一起存档。这样多个角色对“页面是否被允许抓取”的分歧，可以落到同一份可核对的时间线上。但有一个反例会让这套记录失效：如果开关由外部配置中心按用户或按地域动态下发，而你只记录了站点级默认值，那么日志里看到的差异可能来自另一套分流规则，此时版本记录反而会误导判断。
先定义“版本状态”里必须包含什么
功能开关变化后的页面版本，不等于代码版本。至少需要四个字段才能复查：开关标识、取值、生效时间、作用范围。作用范围要写清是全站、某个目录、某类模板，还是特定UA或地区。缺少作用范围，后续核对时不同角色会各自假设一个边界，分歧无法收敛。
建议在记录里同时保存两类证据：一类是开关本身的状态，另一类是页面对外表现。对外表现包括HTTP状态码、响应头中的抓取相关指令、渲染完成后的可见内容摘要。只保存开关状态，无法证明页面实际发生了什么；只保存页面快照，又无法解释为什么变化。
把开关变更写成可核对的项目记录
不要用“已修复”“已调整”这类描述。每条记录应能被第三方按步骤复现。可以采用下面的最小结构：
switch_id：开关的唯一标识，与配置中心或代码中的名称一致。value_before / value_after：变更前后的取值，布尔值也照实写。effective_at：生效时间，注明时区。scope：影响的URL模式或模板，写具体路径前缀，不写“相关页面”。evidence：验证时抓取的响应头、渲染后HTML片段或日志查询条件。
一个假设例子：某分类页模板受开关render_list_v2控制，取值从false改为true后，列表由服务端输出改为客户端渲染。如果记录只写“列表改为前端渲染”，后续有人看到抓取量下降，可能归因于robots规则或服务器限流。若记录中写明作用范围是/category/前缀、生效时间是变更当天、证据是渲染后HTML中列表节点为空，那么排查方向就会先落到渲染环节，而不是先改robots。
不同角色对同一事实理解不一致时，先对齐证据类型
开发、SEO、运维对“页面变了”的判断依据通常不同：开发看配置值，SEO看抓取到的HTML，运维看访问日志。这三者不是同一层证据，直接比较会得出互相矛盾的结论。可行的做法是先约定一个共同核对点，例如“以变更后24小时内、同一URL、同一UA的渲染后HTML为准”，再各自补充自己那层的记录。
如果日志显示某类URL的抓取请求减少，不能直接判定是开关导致。合理解释还包括：该目录本身内容减少、内部链接结构变化、站点地图更新滞后、对方抓取配额调整。要排除这些，需要把开关记录与URL清单、内链变更、站点地图提交记录放在同一时间轴上比对。缺少其中任何一项，减少这一现象都只能算线索，不是结论。
同样，robots.txt中的抓取限制不等于可靠的索引移除。即使开关变更后你临时在robots中屏蔽了某目录，已经存在的索引状态也不会因此立即消失。记录版本状态时，应把robots规则变更单独列为一条，不要和功能开关混为一条，否则后续无法判断是页面内容变化还是抓取规则变化造成了差异。
什么情况下这套记录方法不适用
反例是灰度发布或按用户分流的开关。此时同一URL对不同访问者可能返回不同版本，站点级记录无法代表所有分支。若仍按单值记录，后续核对时会把“部分用户看到新版本”误读为“全量已切换”。遇到这种情况，应改为记录分流规则和抽样验证结果，并注明抽样条件，而不是强行给一个全局版本号。
下一步动作可以这样落地：在下一次开关变更前，先确定一个负责人维护版本记录表，变更后立即用固定UA抓取受影响URL，保存响应头与渲染后HTML，并把记录链接附在变更说明中。如果抓取结果与预期不符，先检查作用范围和分流规则，再决定是否回滚；如果相符，则把该记录作为后续排查的基线，而不是重新从日志倒推。
