robots.txt 很小，但它站在最前面
蜘蛛進入一個站点，第一步往往不是讀首頁，而是先取回 robots.txt。這份文件通常只有几十行，却决定了後面所有工作的起点：哪些目錄可以被訪問，哪些地址连看都不用看。很多站点的問题不是「没寫」，而是寫了之後長期没人回头看，規則随着改版、目錄調整、运营策略變化逐渐失真，最後變成一份與實际站点结构對不上的歷史文档。
下面這份清單适合在改版後、目錄調整後、或者例行维護时跑一遍。它不复杂，但需要耐心逐條核對。
第一步：確認文件本身能正常取回
- 訪問 https://域名/robots.txt，確認返回 200，而不是 404、403 或跳轉到首頁。
- 確認返回的内容類型是 text/plain，而不是 text/html。有些框架會把不存在的内容统一渲染成 HTML 頁面，這时蜘蛛看到的是一堆标簽，規則等于没寫。
- 如果站点同时存在 www 與非 www、主域與子域，確認每個可訪問的域名下都有對應文件，而不是只维護了一份。
- 確認 CDN 或頁面缓存没有把舊版本的 robots.txt 長期缓存住，導致規則改動迟迟不生效。
這几項看起来基础，但在實际排查中，光是「文件取不回来」和「取回来的是 HTML」就占了相当比例的問题。
第二步：逐條核對 Disallow 規則
Disallow 的寫法本身不难，难的是判断某條規則到底屏蔽了什么。建议把現有規則一條條抄出来，在測試工具里對照真實 URL 驗證，而不是凭文件名猜测。
容易被誤伤的几類目錄
- 站内搜尋结果頁：通常是動態參數地址，屏蔽是合理的，但要確認規則没有把承载正文的頁面一起卷進去。
- 标簽頁與聚合頁：如果它們承担了栏目入口的作用，直接屏蔽可能切断新内容的發現路径。
- 静態资源目錄：屏蔽 js、css、图片目錄是常见做法，但要注意部分搜尋蜘蛛需要讀取這些资源才能還原頁面样式與结构。
- 接口與临时目錄：這類地址屏蔽没問题，但要確認前缀没有寫得太宽，比如用 / 開头的一條規則覆盖了整站。
一個稳妥的做法是：屏蔽規則尽量寫具体，能寫到目錄层級就不要用宽泛的前缀；每加一條規則，都想清楚它到底影响了哪些真實存在的 URL。
第三步：不要把 robots.txt 当成隐藏開關
Disallow 表達的是「請不要抓取」，並不等于「頁面不會被收錄」。如果该地址在站外還有其他連結指向，它仍然可能以無描述的形式出現在结果中。真正想让某個頁面從索引里消失，應该配合 noindex，或者干脆让頁面返回 410。
這個区別在草稿頁、測試頁、促销临时頁上尤其重要。运营同学有时會习惯性地往 robots.txt 里加一條屏蔽就当作「下线處理」，结果頁面依然存在，只是抓取被挡住了，問题被推迟而不是被解决。
第四步：確認與 Sitemap 声明一致
robots.txt 里通常會寫一行 Sitemap 地址。检查两点：地址是否還能正常打開；声明的位置是否是目前實际维護的那份。如果站点有多個 Sitemap 索引文件，最好在 robots.txt 中只保留主索引，避免多份声明互相干扰。
同时留意規則之間的逻辑冲突：如果某個目錄已经在 Disallow 列表里，又出現在 Sitemap 中，那這份 Sitemap 的參考價值就會被打折扣。两者要么统一放開，要么统一排除。
第五步：改完之後一定要驗證
- 用搜尋引擎官方提供的 robots.txt 測試工具，輸入几個代表性 URL，確認放行與拦截结果符合预期。
- 改動後观察服務器日誌，看目标目錄的抓取频次是否出現预期變化，而不是只看工具提示。
- 给改動留出几天观察期，再决定是否需要微調，避免一天之内反复修改让抓取行為持續波動。
把 robots.txt 纳入改版检查清單，和跳轉、狀態碼、Sitemap 放在同一級別對待。它不需要频繁調整，但每次調整都值得留一條记錄：改了什么、為什么改、驗證结果如何。這样下次出問题时，至少能快速定位到是哪一次改動带来的影响。