robots txt怎么写：移动端与桌面端怎样检查差异
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1568b766af53.html
📄
robots txt怎么写：移动端与桌面端怎样检查差异
要检查 robots.txt 在移动端与桌面端的差异，不能只看同一份文件在浏览器里能否打开。正确做法是分别用移动端 User-Agent 和桌面端 User-Agent 请求同一个 robots.txt URL，比较返回状态、正文内容、重定向链和抓取限制规则；如果两端访问的是不同主机或不同路径，还要把主机名和路径一起核对。移动端与桌面端规则不一致时，最容易出现的误解是：以为一份 robots.txt 会天然对所有端生效，或者以为桌面端能抓取，移动端也一定能抓取。
为什么同一份 robots.txt 会出现两端差异
robots.txt 的检查结果取决于请求所用的 URL、主机、协议和 User-Agent。站点如果为移动端配置了独立子域，例如 m.example.com，而桌面端使用 www.example.com，那么两个主机各自可能有一份 robots.txt，规则不一定相同。即使两端共用同一主机，服务器也可能根据 User-Agent 返回不同内容，或者把移动端请求重定向到另一个地址。此时“桌面端能访问”不能证明“移动端也能访问”。
另一个常见原因是缓存与 CDN 配置。边缘节点可能对某个 User-Agent 返回旧版本，或者对移动端返回精简版。检查时要记录请求时间、返回状态码、最终 URL 和响应正文，不能只截一张浏览器页面图作为交付依据。
分别请求两端 robots.txt 的可执行步骤
- 列出需要核对的完整地址：桌面端使用的 robots.txt URL 和移动端使用的 robots.txt URL。若移动端有独立子域，要分别写出。
- 用命令行工具分别发起请求，显式指定 User-Agent。例如桌面端可先用常见桌面浏览器标识，移动端用常见移动浏览器标识；具体字符串按团队约定记录，不要凭印象填写。
- 保存每次请求的状态码、最终 URL、响应头和正文。重点看是否出现 301、302、403、404 或 5xx。
- 比较两份正文中的
User-agent、Disallow、Allow和Sitemap行。逐行对照，不要只看总行数。 - 如果两端返回相同正文，再检查它们是否实际来自同一主机和同一路径；如果不同，分别记录差异点。
一个短例子：假设桌面端请求返回 200，正文包含 User-agent: * 和 Disallow: /search；移动端请求返回 301，最终跳到另一个主机上的 robots.txt，正文包含 Disallow: /。这说明两端规则并不一致，移动端可能被整体限制抓取。这里的“可能”需要结合最终 URL 和响应正文确认，不能只凭重定向就下结论。
检查时容易踩的坑
- 只看浏览器打开结果：浏览器通常使用桌面标识，不能代表移动端请求。
- 忽略重定向后的最终地址：robots.txt 规则以最终返回正文为准，重定向链本身也要记录。
- 把抓取限制当成索引移除：robots.txt 禁止抓取不等于页面会从搜索结果中移除，两者机制不同。
- 把站点地图当成收录保证：robots.txt 中写 Sitemap 只是提供发现线索，不保证收录。
- 默认所有搜索引擎行为一致：不同搜索引擎对 robots.txt 的支持和解释可能不同，涉及具体搜索引擎时要分别核查其官方文档。
多人协作时怎样交付检查结果
交付物至少应包含：两端请求的完整 URL、使用的 User-Agent、请求时间、状态码、最终 URL、响应正文差异摘要，以及结论所依据的行。若两端规则不同，要写明差异是主机不同、路径不同、重定向造成，还是服务器按 User-Agent 返回了不同内容。不要把“桌面端正常”直接写成“两端都正常”。
如果移动端与桌面端必须使用不同规则，应在 robots.txt 中分别写明对应的 User-agent 段，并确保每段规则只作用于目标抓取器。规则写完后，重新按上述步骤分别请求两端，确认修改后的正文与预期一致。对于 HTTPS、安全漏洞或排名问题，robots.txt 检查不能替代其他专项检查。
下一步：把两端请求命令和返回正文整理成一份对照表，交给负责发布 robots.txt 的人复核；如果发现移动端被整体禁止，先确认该主机是否真的需要被禁止，再决定修改规则还是调整主机配置。
