📍 WDQWDWQD987AAAAA:216.73.217.111
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b2cb8228f853.html
📄

robots.txt：移动端与桌面端怎样检查差异

检查 robots.txt 在移动端与桌面端的差异，核心不是看文件内容是否不同，而是确认两端请求到的是不是同一份文件、是否被不同规则拦截、以及抓取工具拿到的响应是否一致。最直接的做法：分别用移动端 User-Agent 和桌面端 User-Agent 请求同一个 /robots.txt 地址，对比状态码、响应头和正文；如果正文一致且都是 200，说明两端读到的是同一份规则，差异通常出在访问路径或 CDN 层。

先确认两端请求的是不是同一个资源

很多人以为移动端和桌面端会各自有一份 robots.txt，实际上标准做法是共用一个文件。但在实际部署中，以下情况会让两端拿到不同结果：

• 移动站点使用独立子域，例如 m.example.com，而 robots.txt 只放在主域根目录，子域没有对应文件。
• CDN 或反向代理按 User-Agent 做了分流，移动端被导向另一台源站，那台源站的 robots.txt 内容不同或缺失。
• 移动端页面通过独立路径提供，但 robots.txt 的 Disallow 规则只写了桌面路径，没有覆盖移动路径。

判断方法：用移动端 UA 和桌面端 UA 各请求一次，比较返回的正文是否逐字一致。如果一致，问题不在文件本身，而在规则是否覆盖了移动端 URL。

用不同 User-Agent 实际请求并对比

这是本题最关键的一步，也是多人协作时最容易被跳过的一步。不要只打开浏览器看 robots.txt，因为浏览器发的是桌面 UA，看不到移动端分流后的结果。

可执行步骤：

1. 准备两个 User-Agent 字符串，一个代表常见移动端爬虫，一个代表桌面端爬虫。具体字符串以各搜索引擎官方文档为准，不要凭记忆写。
2. 用 curl 分别请求，例如：curl -A "移动UA" -I https://example.com/robots.txt，再换成桌面 UA 请求一次。
3. 对比三项：HTTP 状态码、Content-Type、正文内容。任何一项不同，都要记录为待查差异。
4. 如果状态码是 301 或 302，跟随跳转后再对比最终地址的正文，确认跳转目标在两端是否一致。

判断结果：两端正文完全一致且状态码为 200，说明文件层没有差异；若移动端返回 404 或 403，说明移动端访问路径存在问题，需要先修访问，再谈规则。

检查规则是否覆盖了移动端 URL

即使两端读到同一份 robots.txt，规则仍可能只针对桌面 URL 生效。常见差异点：

• Disallow 写的是 /pc/ 目录，而移动端内容在 /m/ 目录下，移动端实际未被限制或限制方式不同。
• Allow 与 Disallow 的优先级在两端路径长度不同时，匹配结果会不一样。
• 通配符 * 和结尾 $ 的写法，在移动端带参数 URL 上可能产生不同匹配。

核对方法：把移动端和桌面端各自的典型 URL 列出来，逐条套用 robots.txt 规则，确认允许或禁止的结果是否符合预期。这一步适合在协作中作为交付检查项，由写规则的人和验证的人分别执行一次。

验证与维护时固定检查项

规则修改后，两端都要重新验证，不能只测一端就上线。建议固定以下检查项：

• 移动 UA 与桌面 UA 请求同一 robots.txt，正文与状态码一致。
• 移动端关键 URL 未被误 Disallow，桌面端同样未被误放行。
• robots.txt 地址本身返回 200，不是 404 或 5xx。
• 若使用子域或独立移动站，确认各自主机根目录都有可访问的 robots.txt。

需要明确：robots.txt 的抓取限制不等于可靠的索引移除。被 Disallow 的 URL 仍可能出现在搜索结果中，只是爬虫不再抓取内容。若目标是移除索引，应使用对应的移除工具或 noindex 方案，而不是只改 robots.txt。

多人协作时，把上述请求命令、UA 字符串、对比结果写进交付记录，后续复查可以直接复用，减少因环境不同导致的返工。

下一步

选一个你负责的站点，用移动端和桌面端 UA 各请求一次 robots.txt，把状态码、响应头和正文差异记录下来；如果发现移动端路径未覆盖，先补规则再重新验证两端结果。