一次站点改版后，搜索流量突然下降。排查发现，正式环境的 robots.txt 保留了测试站使用的规则：
User-agent: *
Disallow: /
文件本身没有语法错误，却向遵守规则的爬虫发出了“不要抓取整个站点”的指令。这类问题很容易通过代码审查：文件短、规则看起来简单，真正的影响却要结合爬虫类型和 URL 路径才能判断。
本文围绕 Robots.txt Generator 和 Robots.txt Tester，梳理规则生成、匹配及部署前验证。两个工具都在浏览器本地处理输入；正式环境中的文件仍需要单独检查。
robots.txt 管的是抓取，不是访问权限
robots.txt 是站点放在根目录的一份文本文件，用于向爬虫声明哪些路径可以或不应抓取。
例如：
User-agent: *
Disallow: /search/
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml
这份规则表达了三个意思：
User-agent: *：规则适用于没有更具体匹配组的爬虫；- 两条
Disallow：不希望它们抓取/search/和/admin/下的地址； Sitemap：提供站点地图的位置。
但 robots.txt 是公开的抓取约定。它不能阻止用户直接访问 /admin/，也不能保证所有自动程序遵守规则。后台、订单或用户数据仍需要登录、鉴权和权限控制。
同样，禁止抓取不等于一定禁止索引。Google 可能从站外链接等来源发现被屏蔽的 URL，并在没有页面内容摘要的情况下展示它。需要排除索引时，应采用适合场景的访问控制或 noindex；而要让爬虫读到页面里的 noindex，通常需要允许它抓取该页面。Google 的 robots.txt 入门文档 对这一点有明确说明。
文件放在哪里，决定规则作用在哪里
正式文件通常位于：
https://example.com/robots.txt
规则的作用范围绑定到对应的协议、主机和端口。下面这些地址不能简单视为同一份规则：
https://example.com/robots.txt
https://www.example.com/robots.txt
http://example.com/robots.txt
https://example.com:8443/robots.txt
如果站点同时运行主站、图片子域和独立商店，每个入口都应检查自己的部署和访问策略。Google 对文件位置及适用范围的说明见 robots.txt 规范文档。
一个常见错误是把文件放在：
https://example.com/static/robots.txt
这不等于站点根目录的 /robots.txt。即使浏览器能打开，爬虫也不会因此把它当作该站点的根规则文件。
从简单草稿开始生成
假设希望减少搜索结果页的重复抓取，同时允许正常内容页，可以先准备：
User-agent: *
Disallow: /search/
Sitemap: https://example.com/sitemap.xml
使用 Robots.txt Generator 时，填写爬虫标识、以 / 开头的路径，以及需要公开的 Sitemap 地址。工具会生成文本草稿；它不会抓取网站，也不会替你判断某条规则是否符合实际业务。
生成后应结合真实路由审查。例如，站点的站内搜索路径可能是 /search/，也可能是 /?q=...。只写 /search/，未必覆盖后者。
匹配不是“最后一行覆盖前面”
看下面这组规则：
User-agent: *
Disallow: /products/
Allow: /products/manuals/
按更具体的匹配规则：
| 测试路径 | 匹配结果 | 原因 |
|---|---|---|
/products/item-1/ |
不允许抓取 | 匹配 /products/ |
/products/manuals/guide/ |
允许抓取 | /products/manuals/ 更具体 |
/about/ |
允许抓取 | 没有匹配到禁止规则 |
对于 Google，路径规则按匹配的具体程度确定优先级；同等具体的 Allow 和 Disallow 冲突时，Google 使用较宽松的规则。Google 的规则匹配说明 还介绍了匹配时的大小写、编码和路径细节。
测试时不仅要看到“允许”或“禁止”，还应查看哪条规则生效。否则一条宽泛规则可能恰好让测试通过，真正想检查的例外规则却从未被命中。
* 和 $ 怎么用
在 Google 支持的语法中：
*匹配零个或多个字符；- 行尾的
$表示匹配到 URL 末尾。
例如：
User-agent: *
Disallow: /*.pdf$
测试结果可以这样理解：
| URL 路径 | 是否匹配该规则 |
|---|---|
/files/manual.pdf |
匹配 |
/manual.pdf |
匹配 |
/files/manual.pdf?download=1 |
不匹配：.pdf 后面还有查询参数 |
/files/manual.pdf.html |
不匹配 |
如果业务希望同时覆盖带查询参数的 PDF 地址，规则就需要重新设计，并分别加入测试样例。不要只测一个“看起来正确”的 URL。
路径匹配还有两个容易忽略的细节：
Disallow: /private/
它针对以 /private/ 开头的路径，不能假定一定覆盖 /private、/Private/ 或其他拼写形式。实际是否需要覆盖这些地址，取决于服务器路由与重定向行为。
多个 User-agent 组如何影响结果
下面的规则对不同爬虫给出了不同指令：
User-agent: *
Disallow: /archive/
User-agent: Googlebot
Allow: /archive/public/
Disallow: /archive/private/
对 Google 来说，更具体的 Googlebot 组会被选中，不能简单假定它会与 User-agent: * 组自动合并。因此，改动专用组时，应把它需要遵守的相关规则完整写入该组，并分别测试不同爬虫。
Robots.txt Tester 可以选择爬虫或输入自定义 User-agent，再逐行测试 URL。它会显示选中的组、匹配规则和结果，适合用于人工检查。
需要保留一个边界：工具实现的是本地匹配逻辑，不能保证与每个爬虫在所有编码、复杂 User-agent 或边界条件下完全一致。遇到复杂规则，应以目标爬虫的官方文档及其提供的测试方式复核。
部署前，用一组固定样例做回归
不要等文件发布后才临时找几个 URL 测试。可以为站点维护一组固定案例：
| 测试 URL | 爬虫 | 预期 |
|---|---|---|
/ |
Googlebot | 允许 |
/articles/example/ |
Googlebot | 允许 |
/search/?q=example |
Googlebot | 根据站点策略判断 |
/admin/login |
Googlebot | 按预期规则判断 |
/assets/app.css |
Googlebot | 允许 |
/assets/app.js |
Googlebot | 允许 |
/files/manual.pdf?download=1 |
Googlebot | 根据 PDF 策略判断 |
CSS、JavaScript 和图片资源也要纳入样例。规则如果意外屏蔽页面渲染所需资源，爬虫可能无法正确理解页面。Google 对此有专门的抓取与渲染说明，相关规则仍应结合站点实际资源路径检查。
本地测试通过后，还应检查线上返回：
GET https://example.com/robots.txt
确认响应成功、正文确实是预期文本，并检查重定向、CDN 缓存及 HTTP/HTTPS、www 与非 www 等实际入口。不同状态码、网络错误和缓存会影响爬虫如何处理文件，具体行为应以目标爬虫的文档为准。
把生成和测试接进发布流程
一个实用的发布流程可以是：
整理目标爬虫和路径
→ 生成规则草稿
→ 准备允许与禁止的测试用例
→ 检查命中规则
→ 在预发布环境验证响应
→ 发布正式文件
→ 复查线上文件与缓存
对于重要站点，规则文件最好进入版本控制，并把常用 URL 和预期结果写成自动化测试。这样修改 /search/ 规则时，就能及时发现是否误伤了公开内容、渲染资源或 Sitemap。
Robots.txt Generator 适合生成草稿，Robots.txt Tester 适合检查规则如何作用到具体 URL。最终是否能达到预期，还取决于线上文件、服务器响应、缓存和目标爬虫的实际行为。
