robots.txt 常被当成一個開關：要么全站放行，要么把某些目錄關掉。實际用起来，它更像是给蜘蛛划出的一條路线邊界——能挡住一部分 URL，也能给出抓取节奏的提示，但它不保證任何頁面被收錄。寫错的时候，問题往往不是少收錄几個頁面，而是蜘蛛在整站范围内的抓取行為被改變。
一、robots.txt 不是提交入口
先明确一点：robots.txt 只做限制，不做推荐。把 Sitemap 地址寫在 robots.txt 里，是告诉蜘蛛站点地图在哪，方便它找到這份清單；但不代表寫進去的 URL 會被優先抓取，更不代表會出現在搜尋结果里。同理，没寫進 Sitemap 的頁面也不會因為 robots.txt 放行而自動获得抓取優先級。
很多人把這两件事混在一起，于是出現一種典型誤判：站点地图提交了，robots.txt 也放行了，但新頁面還是没動静，就去反复改 robots.txt。真正的原因可能在別處——内鏈没有指向它、頁面返回了非 200 狀態、或者服務器响應時間太長，蜘蛛拿不到内容。先分清是發現环节還是抓取环节出了問题，比改規則更有效。
二、Disallow 的匹配方式最容易踩坑
用 Disallow 时，路径是前缀匹配，不是目錄精确匹配。這带来几個常见的连鎖問题：
- 寫 Disallow: /search 會同时挡住 /search、/search-page、/searching 等所有以 /search 開头的路径。
- 通配符和结尾符需要先確認蜘蛛是否支持。主流搜尋引擎支持，但不确定时應先用少量路径驗證效果，再决定是否大面积使用。
- 顺序問题：不同爬虫對 Allow 與 Disallow 冲突时的處理並不完全一致，稳妥做法是別让两條規則指向同一路径。
還有一種容易被忽略的情况：誤伤静態资源目錄。頁面本身可以抓，但样式和脚本被挡住，蜘蛛拿到的就是一份不完整的頁面，内鏈和正文都可能看不全。
三、Crawl-delay 只能减速，不能提速
有些运营想通過 Crawl-delay 让蜘蛛抓快点，這個方向是反的。這個字段表達的是两次請求之間請等一會，只會拉低频率。它在部分搜尋引擎身上不一定生效，而且同一台服務器上如果同时存在多個站，硬性拉長延迟可能让抓取预算消耗在排队上，而不是頁面本身。
如果日誌里看到蜘蛛請求密集、服務器吃不消，先看的應该是响應時間和错誤率，而不是急着寫 Crawl-delay。5xx 和超时堆积时，蜘蛛自己就會降速，這是服務器稳定性的問题，不是速度設定的問题。等服務器恢复平稳，再观察抓取节奏是否自然回升。
四、屏蔽之後的连鎖反應
被 robots.txt 挡住的 URL，蜘蛛不會去讀頁面内容，于是會出現几種连带效果：
- 该頁面上的出鏈不再被發現，原本靠它传導的内鏈路径断掉一截。
- Sitemap 里如果還留着這些 URL，日誌會看到蜘蛛反复尝试又反复放弃，形成大量無意义請求。
- 之前已被抓取的頁面若突然被屏蔽，索引中的舊版本可能長期保留，内容更新传達不出去。
- 頁面在搜尋结果中即使仍有展現，用戶点進去看到的也可能與摘要不一致，影响後續行為資料。
五、從日誌核對的顺序
發現抓取異常时，可以按下面的顺序核對，避免一上来就改規則：
- 確認 robots.txt 可訪問、返回 200、内容類型正常，且没有被 CDN 缓存成舊版本。
- 在日誌里筛出目标路径，看蜘蛛是没来還是来了被挡。没来时查内鏈和 Sitemap；来了被挡时，對照規則逐條比對前缀。
- 检查 Sitemap 與 robots.txt 是否互相矛盾：Sitemap 收錄的 URL 却被 Disallow 挡住，這是最常见的浪費。
- 確認没有把關键目錄誤寫成全站屏蔽，也確認静態资源目錄没有被誤伤。
- 改完規則後，观察日誌中的請求分布和狀態碼變化，而不是只看某一天的總量。
robots.txt 是一條邊界，不是一個開關。它决定蜘蛛走到哪里為止，不决定蜘蛛會不會喜欢你。邊界画错，後面的 Sitemap、内鏈和抓取节奏都會跟着走偏。
六、寫規則时的几個习惯
- 規則尽量少而明确，避免一條通配挡掉一大片路径。
- 測試环境與线上环境的 robots.txt 分開管理，別让測試規則被带上线。
- 改動前先拉一段日誌做基线，改動後再對比，判断影响范围。
- 把 robots.txt 纳入上线检查清單，和重定向、Sitemap 一起看。
抓取這件事本身變量很多，robots.txt 只是其中一层。把它寫清楚，至少能保證蜘蛛看到的是你希望它看到的入口，而不是在门口就掉头。