你在 robots.txt 里写下放行，回头跟同事说门开了。过几天翻日志，爬虫压根没进来。你把文件来回看了三遍，一个字都没写错。
问题不在文件，在文件管不到的地方。robots 只是一张告示，它约束的是守规矩的爬虫，不是门禁。真正拦人的几道关都在服务器那一侧，任意一道没过，纸面上写得再客气也白写。
别只信文件，拿不同标识实测一遍
判断法不复杂，别盯着配置文件看，拿几种不同的爬虫标识去请求同一个地址，把三样东西一起记下来，状态码、响应体字节数、响应头里有没有那项禁止收录的标记。三样都干净才算数，少看一样都会漏。
为什么不能只看状态码，因为有些防护页本身就返回 200，你一路绿灯，实际拿到的全是「请稍候，正在验证」的空壳。这种只能靠响应体长度和开头几十个字符认出来。
robots 之外有四道关，出问题时你查 robots 查不出来，得逐道自查。
| 哪一道 | 典型现象 | 怎么确认 |
|---|---|---|
| 边缘防护的默认策略 | 只有某一类爬虫拿不到，或在边缘就被 403 | 去控制台看策略，别只信配置文件 |
| 服务器里的标识拦截规则 | 连搜索引擎的标识也一起被挡 | 拿搜索引擎标识单独请求一次 |
| 请求频率限制 | 前几页 200，后面变成 429 或 503 | 连续请求 20 次，看第几次开始变 |
| 响应头里的收录标记 | 页面能开、内容完整，但就是不收录 | 看响应头，页面源码里搜不到这一层 |
本站把四道都实测过一遍
这四道本站逐一验过，结论是没有按爬虫标识、来源地址、请求频率设拦截，没有边缘层的拦截开关，响应头里那一项也清掉了。这些不是翻配置文件翻出来的，是拿 18 种爬虫标识逐个请求，连不带标识的那种也一起测了，全部返回 200。
那份清单把 44 组 UA 逐个列开，全放行。看着像多此一举，它到底图什么，下面说。
别人怎么做，按证据分三档
公开能查到的说法大致三档，混着看会出事。
一档有规范原文撑着，可以当依据。RFC 9309 第 2.2.1 节写明，没有匹配的规则时不施加限制，第 2.2.2 节讲最具体匹配优先，RFC 9110 定义 301 与 410。顺着这里能得出一个不太讨喜的结论，一条通配放行在协议层就够了，把几十种爬虫名字逐个列出来显式允许并非必需。44 组 UA 的真实价值在防模板继承、防回归、方便日后审计和单独收紧，不在放行本身。
一档是行业里普遍在做、却拿不出公开验证的。逐个 UA 写显式允许的模板到处都是，理由多半是防模板继承，也有人把一份清单勾选完就当验完了。这类只归纳做法，不当依据，不写效果倍数，不点名任何服务商。
还有一档已经有公开反例或明确争议，是把纸面放行当成验收的终点，拿一两次抓取记录就宣布门开了、可见性上去了。公开研究指出同一组提示重复跑，出来的品牌列表高度不稳定，一次截图当不了基线。放行只解决门口没拦，抓取活跃和被引用之间还隔着一整段实测，这层不能省。监管通报与 2026 年 8 月发布的可信传播团体标准都把效果承诺列为治理对象，这类话只能写进不适用，不能写进承诺。
什么时候不必这么做
需要登录才能看的内容、靠大量前端脚本才渲染出内容的页面、付费接口和私有数据，这三类改 robots 一点用都没有，别在这儿绕。只有后台发文权限、动不了服务器配置、看不到响应头、也拿不到公网抓取工具的团队，四道关里大半验不了，做到把通配放行写对、把站点地图写成绝对地址就够了，硬凑边缘层没意义。全站走 CDN 又拿不到边缘日志的，源站记录不等于真实流量，先把日志接上再谈。
一句话的判断标准
别问文件写没写对，问拿不同标识从公网实测，状态码、内容长度、响应头三项是不是都干净。三项都过才算门真开了，缺一项就回去查对应的那道关。
想把放行这件事拆开看，爬虫放行清单与四道关核查的技术文档给了分组口径、逐项验收清单和一套能当场跑的验证方法，可以拿自己的站复算一遍。