robotstxt：同一地址因设备或登录状态返回不同内容怎样对照，先固定变量：把“设备不同”拆成可复现的请求
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ef644fc30e6b.html
📄
robotstxt：同一地址因设备或登录状态返回不同内容怎样对照，先固定变量：把“设备不同”拆成可复现的请求
不能把“同一 URL 内容不同”直接当成 robots.txt 规则写错。先要把差异归因到三类来源：请求头（User-Agent、Cookie、Accept-Language）、网络出口（IP、地区、CDN 节点）、以及服务端对登录态或设备判定的分流。只有排除了前两类，剩下的差异才值得用 robots.txt 去解释或调整。下面用一个假设情境把决策过程走完。
先固定变量：把“设备不同”拆成可复现的请求
假设你负责一个内容站，发现手机端和桌面端访问同一篇文章地址时，手机端返回的是精简版正文，桌面端返回完整正文。你怀疑是 robots.txt 对某类爬虫放行不同路径导致。这个怀疑在第一步就不成立，因为 robots.txt 只控制抓取许可，不控制返回内容。真正需要先做的是把“设备”还原成请求头。
具体动作：用同一台机器、同一网络出口，只改 User-Agent 和 Cookie 两个变量，各发一次请求，保存响应状态码、响应体长度和正文首段。结果如果只有 User-Agent 改变时正文变化，说明是服务端按 UA 分流；如果只有 Cookie 改变时正文变化，说明是登录态或会话分流。这两种情况都和 robots.txt 无关，下一步应去查服务端模板或缓存策略，而不是改规则文件。
再排除登录态与缓存：两类差异常被误判成规则问题
登录状态造成的差异最容易被误读。同一地址在未登录时返回摘要，登录后返回全文，这在会员站、论坛、文档站都常见。判断依据不是内容长短，而是响应头里是否有会话标识、Vary 头是否包含 Cookie。如果 Vary 含 Cookie，说明缓存层已经按登录态区分，抓取工具看到的通常是未登录版本。
缓存和 CDN 也会制造“同址不同内容”。同一 URL 在不同节点可能命中不同缓存版本，尤其在内容刚更新或灰度发布期间。可区分的证据是：连续多次请求同一节点结果稳定，换节点后结果变化；或者带缓存绕过参数时结果一致。这类差异的下一步是清缓存或调整缓存键，不是改 robots.txt。
假设情境：三种返回结果，怎样决定是否动规则文件
下面是一个明确标注为假设的例子，用来演示对照方法，不代表任何真实站点。
假设某地址返回三种结果：桌面未登录返回完整正文；手机未登录返回精简正文；登录后两种设备都返回完整正文。你手上有一次抓取记录，显示抓取工具只拿到精简正文，于是你想在 robots.txt 里放开某个路径。这个动作在逻辑上跳步了。
- 先确认抓取工具发出的 User-Agent 是否被归入“手机”分支。如果是，差异来自服务端模板，改 robots.txt 不会让正文变完整。
- 再确认该地址是否要求登录才能看到完整正文。如果是，抓取工具天然拿不到登录态内容，这时要考虑的是内容可访问性设计，而不是规则许可。
- 只有当前两步都排除，且确认是某条 Disallow 规则挡住了包含完整正文的路径时，调整规则才有意义。
这个顺序的价值在于：它把“改规则”从第一反应降到最后手段。动作的结果会直接改变下一步——如果差异来自模板或登录态，下一步是改服务端或调整内容策略；如果差异来自规则，下一步才是最小化修改并复查。
规模化后出现例外：样本成立不等于可以照搬
个别样本对照成功，不代表整套方法可以批量套用。常见例外有三类。第一，同一 URL 因地区或语言返回不同内容，这类差异由 IP 或 Accept-Language 触发，和 robots.txt 无关，规模化对照时需要按地区分别取样。第二，部分路径只在特定 UA 下被重定向，重定向目标可能不在原规则覆盖范围内，这时要看的是重定向链而不是规则文本。第三，站点地图里列出的地址和实际返回内容的地址不一致，站点地图本身不保证收录，也不能作为内容差异的证据。
适用条件是：你能够控制请求变量并保存响应证据。如果做不到固定出口和固定请求头，对照结果会被缓存和分流污染，此时应先搭建可复现的请求环境，而不是继续扩大样本量。
对照完成后，哪些结论不能直接下
即使确认差异来自 robots.txt 规则，也要注意边界。抓取限制不等于索引移除：放开或收紧规则影响的是抓取许可，不保证内容被收录或从索引中消失。不同搜索引擎对规则的支持和解释需要分别核查，不能用一个引擎的表现推断另一个。HTTPS 与内容差异无关，也不保证安全或排名，不要把它拉进这个对照流程。
可执行的最小动作是：保存修改前的规则原文和修改后的响应记录，隔一段时间复查同一组请求变量下的返回结果。如果返回内容变化但请求变量未变，优先怀疑缓存或发布流程，而不是规则本身。这一步的结果决定了你是回滚规则，还是转去排查服务端。
