要取得可复查的状态证据,核心做法是把“谁在什么时候看到什么配置、得到什么响应”记录下来,并让另一个人能按同样路径复现。对搜索引擎爬虫控制来说,证据不是一句“已经设置了”,而是 robots.txt 的原始内容、HTTP 状态码、响应头、抓取日志片段以及变更时间线的组合。适用前提是团队能访问服务器、CDN 或日志系统,并且愿意把检查步骤写成可重复的命令或清单。
多人协作返工,往往是因为把不同层面的证据当成同一件事。建议分开记录:
只有配置证据,无法证明爬虫真的被限制;只有行为证据,无法解释为什么被限制。可复查的状态证据至少要让两类证据互相印证。
每次检查都保存命令和输出,而不是只截图。下面是一个假设示例,域名用 example.com 代替,实际使用时替换成自己的域名:
curl -sS -D headers.txt -o body.txt https://example.com/robots.txt
这条命令把响应头和正文分别保存。检查时重点看:
text/plain 一类可读文本;如果返回 HTML,说明可能被错误页面接管。User-agent、Disallow、Allow、Sitemap 行。对具体页面,还要检查 X-Robots-Tag 响应头。可以用 curl -I 查看头部,但注意 HEAD 请求与 GET 请求在某些服务上可能返回不同结果,必要时用 GET 并只读取头部。
robots.txt 的抓取限制不等于可靠的索引移除。一个常见误区是:在 robots.txt 里禁止某个目录后,就认为该目录下的页面会从搜索结果消失。实际上,如果页面已经被索引,禁止抓取可能让搜索引擎无法读取页面上的 noindex 指令,反而使移除流程更复杂。可复查的证据应当分别记录:
noindex,该响应是否能被爬虫正常抓取到。站点地图不保证收录,它只是发现 URL 的辅助入口。把站点地图提交成功当成“已收录”的证据,会导致验收结论错误。
从日志中取证据时,至少保留四列:时间、请求路径、user-agent、响应码。可以用下面的思路筛选,具体命令按自己日志格式调整:
grep -i "googlebot" access.log | grep "/private/" | tail -50
这只是假设示例,用于说明筛选逻辑。判断时注意:
一份可复查的交付物,建议包含以下内容,并按时间顺序排列:
验收信号是:另一位同事拿到这份记录后,不需要询问上下文,就能用相同命令得到相同或可解释的结果。如果只能得到截图而无法复现,就还不算可复查的状态证据。
下一步,选一个当前正在调整的路径,按上面的格式做一次最小记录:保存 robots.txt 响应、保存该路径的响应头、从日志中取最近若干条对应爬虫请求,然后把三者放在同一份变更说明里交给协作者复核。