很多站点在排查“新頁面為什么迟迟不被發現”时，會先去看内鏈、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，往往能省下後面大量的排查時間。