网站抓取规则 - 用可复查证据定位抓取异常
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3307af6b5a4e.html
📄
网站抓取规则 - 用可复查证据定位抓取异常
要取得可复查的状态证据，核心是把“谁在什么时候请求了什么、服务器怎样回应、规则文件是否允许”这三类信息固定下来，形成带时间戳、可重复验证的记录。不要只凭后台截图或一句“抓取正常”下结论，而应保留原始日志、HTTP响应头和规则文件快照，让任何人按相同步骤都能得到相同结果。
先明确要查的抓取主体与规则文件
网站抓取规则通常由 robots.txt、页面级 meta 指令、HTTP 响应头中的 X-Robots-Tag，以及服务器访问控制共同决定。取证第一步是确认你关心的是哪个抓取者：搜索引擎蜘蛛、站点地图抓取器、还是第三方监测工具。不同抓取者的 User-Agent 不同，规则文件里针对它们的段落也可能不同。
- 查什么：robots.txt 中与目标 User-Agent 匹配的 Disallow 和 Allow 行。
- 怎么查：用命令行
curl -A "目标UserAgent" https://你的域名/robots.txt，保存完整输出和响应头。 - 结果说明什么：若目标路径被 Disallow，抓取者按规则不应请求；但这不是索引移除的可靠手段，已收录页面仍可能因外部链接出现在结果中。
用服务器日志固定每一次抓取请求
日志是最接近“实际发生了什么”的证据。你需要拿到包含时间、客户端 IP、User-Agent、请求方法、请求路径、状态码和响应字节数的原始日志行，而不是只看统计图表。
- 查什么：目标抓取者在指定时间窗口内对目标路径的请求记录。
- 怎么查：用
grep过滤 User-Agent 关键字，再按时间排序；例如grep "目标UA片段" access.log | grep "/目标路径"。 - 结果说明什么：有请求且状态码为 200，说明服务器返回了内容；状态码为 403 或 429，说明请求被拒绝或限流；完全没有记录，可能是抓取者未请求，也可能是日志未覆盖该时段或请求打到了其他节点。
注意区分“可能原因”和“已经定位的原因”。日志里没有记录，可能是抓取者没来，也可能是负载均衡后只保留了部分节点日志。要排除后者，需核对日志覆盖范围。
检查 HTTP 响应头与页面级指令
服务器返回的响应头比页面内的 meta 标签更早被处理，两者冲突时以响应头为准。取证时应保存完整响应头，而不是只记录状态码。
- 查什么：
X-Robots-Tag、Content-Type、Cache-Control、Vary等字段。 - 怎么查：
curl -I -A "目标UserAgent" https://你的域名/目标路径，把输出重定向到文件并记录执行时间。 - 结果说明什么：若
X-Robots-Tag含noindex，即使 robots.txt 允许抓取，页面也不应被索引；若Content-Type与页面实际内容不符，抓取者可能按错误类型处理。
HTTPS 只表示传输层加密，不保证页面没有漏洞，也不直接决定抓取或排名结果。把它当作独立检查项，不要与抓取规则混为一谈。
用站点地图和内部链接做交叉验证
站点地图是发现 URL 的辅助手段，不保证收录，也不保证抓取频率。它的价值在于提供一份可对照的 URL 清单，帮助你判断抓取者是否访问了预期页面。
- 查什么：站点地图中列出的 URL 是否与日志中实际被抓取的 URL 一致。
- 怎么查：下载站点地图，提取 URL 列表，与日志中同一时间窗口的请求路径做差集。
- 结果说明什么：差集过大说明部分页面未被抓取，需回到 robots.txt、响应头或服务器可用性排查；差集很小说明抓取覆盖与声明基本一致。
把证据整理成可复查的记录
可复查意味着别人能按你写的步骤重放。建议每条证据包含：采集时间、采集命令或工具、原始输出文件、目标 User-Agent、以及你对结果的判断和判断依据。
一个假设例子：你发现某栏目页面未出现在搜索结果中。先保存 robots.txt 快照，确认该路径未被 Disallow；再过滤日志，发现抓取者请求该路径时返回 503；最后用 curl -I 复现，确认服务器在特定时段返回 503。此时可定位为服务器可用性问题，而不是规则文件问题。若日志显示 200 但页面仍未被索引，则需继续检查响应头中的 noindex 和页面内容质量，不能直接断言是抓取规则导致。
下一步：选定一个具体抓取者和一个具体路径，按上述清单采集一轮证据，把原始输出保存到带日期的目录中，再根据状态码和规则文件的对应关系写下你的判断。
