robots txt怎么写：同一地址因设备或登录状态返回不同内容怎样对照
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6b269cb7920b.html
📄
robots txt怎么写：同一地址因设备或登录状态返回不同内容怎样对照
先给结论：不能只凭一个设备、一个登录状态下的抓取结果判断 robots.txt 是否写对。正确做法是把同一地址在“未登录 + 移动端 UA”“未登录 + 桌面端 UA”“登录态 + 桌面端 UA”几组条件下分别取回，再对比响应状态、正文主体和 robots.txt 本身是否一致。只要有一组返回了不同内容，就不能把这一条规则直接规模化套到全站。
先固定一个可复现的对照样本
取你手上真实存在的一个 URL，不要用首页代替。记录三件事：请求时使用的 User-Agent、是否携带登录 Cookie、返回的 HTTP 状态码。然后在 robots.txt 里找到覆盖这个路径的规则，确认它属于哪一条 User-agent 分组。
这一步的产出是一张对照表，而不是结论。因为同一地址返回不同内容，可能来自服务端根据 UA 做的移动适配，也可能来自登录态下的个性化模块，还可能只是缓存命中差异。三种原因的下一步处理完全不同。
用状态码和正文主体区分原因
把各组结果并排看，优先看状态码：
- 各组都是 200，但正文主体不同：多半是设备适配或登录态渲染，robots.txt 规则本身未必有问题。
- 未登录返回 200，登录态返回 302 跳转到登录页：这条规则对爬虫的可见性判断要以未登录结果为准。
- 某一组返回 403 或 429：先排查是否被防护策略拦截，不要直接归因于 robots.txt。
如果只有一个设备组合出现例外，说明这条规则可能只在特定渲染路径下成立。此时不要把该规则照搬到同类路径，而应先把例外路径单独列出，确认它是否真的需要被限制抓取。
写 robots.txt 时的适用边界
robots.txt 只能表达抓取偏好，不能保证内容被移除。一个 URL 被 Disallow 后，如果它已被索引，页面仍可能出现在结果里，只是摘要信息会逐渐变化。所以对照时要把“抓取限制”和“索引移除”当成两件事。
另外，站点地图里列出某个地址，不代表它一定会被收录；不同搜索引擎对同一份 robots.txt 的解析细节也可能不同，遇到边界写法要分别核查，而不是假设所有引擎行为一致。HTTPS 只说明传输层加密，不构成内容可见性或排名保证。
一个假设例子：把例外收敛成可执行动作
假设你有一个商品筛选页 /list?color=red，桌面未登录返回完整列表，移动端未登录返回精简列表，登录后返回带推荐位的列表。你原计划在 robots.txt 里对 /list 整段 Disallow。
对照后你发现：移动端精简列表和桌面列表的正文主体高度重合，登录态推荐位才是差异来源。此时更稳妥的动作是只限制带特定参数的组合，而不是整段屏蔽。执行后重新取回三组样本，如果未登录两组恢复一致，说明规则收敛到了正确范围；如果仍不一致，则说明差异来自渲染层而非抓取层，需要回到模板或缓存配置排查，而不是继续加 Disallow。
规模化前必须确认的前提
当个别样本通过后，不要立刻按同一模板批量生成规则。先确认三点：这些路径是否共用同一套渲染逻辑；登录态内容是否对未登录爬虫不可见；例外路径是否已被单独记录。只有三点都成立，才适合把当前规则扩展到同类路径。
如果某类路径的返回内容随设备或登录状态明显分叉，正确做法是把它当作独立对象处理，而不是塞进统一规则里。这样后续复查时，你才能分清是规则写错，还是内容本身就不该用同一条规则覆盖。
