很多站点在排查“新页面为什么迟迟不被发现”时，会先去看内链、Sitemap、服务器日志，却容易忽略一个更靠前的位置：robots.txt。搜索蜘蛛在抓取一个站点之前，通常会先请求这个文件，用它来判断哪些路径可以进入。它本身不复杂，但一旦写错，影响面往往覆盖整站。
robots.txt 能做什么，不能做什么
需要先明确它的边界。robots.txt 是一种约定，遵守它的主要是主流搜索引擎的爬虫，它控制的是“抓取”，而不是“索引”。如果页面已经被抓取并收录，事后才在 robots.txt 里禁止，页面通常仍可能留在索引里，因为蜘蛛无法再次读到页面上的 noindex 指令。反过来，如果一个页面从未被抓取，蜘蛛也无从知道它是否需要被移除。
因此，临时屏蔽和永久清理是两件事。前者可以用 robots.txt，后者更适合用 noindex、410 状态码或直接删除内容。把两者混在一起，是很多运营问题的源头。
常见的误封场景
- 整站屏蔽未撤销：上线前为了不让测试环境被抓，写了 Disallow: /，正式发布后忘记删除。这是最典型也最容易被忽略的一种。
- 误封静态资源：屏蔽 /js/、/css/、/images/ 等目录，蜘蛛虽然能拿到 HTML，却无法加载渲染所需的资源，页面内容可能无法完整呈现。
- 通配符使用过宽：Disallow: /*? 会拦掉所有带参数的 URL，包括正常的分页、筛选、追踪参数，导致大量有效页面失去入口。
- User-agent 分组写错：只写了某个特定爬虫的规则，却漏掉了其他 UA；或者写了 User-agent: * 之后又追加了不生效的规则。
- 文件本身异常：robots.txt 返回 5xx 或超时，蜘蛛可能暂时停止抓取；返回 404 则通常视为没有限制。把 robots.txt 放进需要登录的目录，也会造成类似问题。
放行与调试的实践
与其等到发现问题再改，不如把 robots.txt 纳入日常巡检。几个可以固定下来的做法：
- 确保 /robots.txt 可以直接访问，返回 200，且内容为纯文本。
- 在文件末尾声明 Sitemap 地址，使用完整 URL，多个 Sitemap 就写多行。
- 对确实需要临时屏蔽的目录，优先考虑密码保护或返回 401、403，而不是长期依赖 robots.txt。
- 预发布环境用独立域名或 IP 白名单隔离，不要和正式站共用一份 robots.txt。
- 修改规则后，用搜索引擎提供的 robots.txt 测试工具验证具体 URL 是否被放行，而不是只看文件内容。
一份排查清单
- 直接访问 /robots.txt，确认状态码和内容，排除 CDN 或 WAF 返回的干扰页。
- 搜索是否存在 Disallow: / 这类全局规则。
- 检查是否屏蔽了 CSS、JS、图片、字体等渲染依赖目录。
- 核对 User-agent 分组，确认目标爬虫落在正确的规则块里。
- 检查通配符和结尾符号的使用，避免误伤带参数的正常 URL。
- 确认 Sitemap 地址完整、可访问，并与实际提交的地址一致。
- 在服务器日志中观察蜘蛛请求 robots.txt 的频率和状态码，判断是否存在异常。
- 修改后持续观察一段时间的抓取量和新 URL 的发现情况，不要只看一天的数据。
robots.txt 禁止抓取，并不等于把页面从搜索结果中移除。需要清理的页面，应该用 noindex 或合适的 HTTP 状态码来处理。
和 URL 发现的关系
从 URL 发现的角度看，robots.txt 更像一道闸门。放行范围过窄，蜘蛛进不来，Sitemap 和内链做得再好也没有意义；放行范围过宽，又会让抓取预算消耗在筛选页、重复页和低价值参数上。合理的做法是：把真正需要被发现的内容目录、分页路径、Sitemap 明确放行，把后台、搜索结果页、购物车、会话参数等无索引价值的路径挡在外面。
它不需要写得很复杂，但值得被当成站点结构的一部分来维护。每次改版、迁移或新增栏目时，顺手确认一遍 robots.txt，往往能省下后面大量的排查时间。