robots.txt 是抓取入口的第一道闸门，也是最容易被忽略的一道。它寫得越复杂，越容易出現“以為放行、實际被拦”的情况。這類問题通常不报错，只在抓取日誌里表現為某個目錄的請求量悄悄归零。下面梳理通配符與 Allow/Disallow 優先級導致的高频誤配，以及可以逐條执行的核對顺序。
先弄清匹配優先級
以 Google 公開的說明為參考，主流實現按“最長匹配優先”處理：某條規則中與 URL 路径重叠的部分越長、越具体，就優先于更短的規則；当 Allow 與 Disallow 的匹配長度完全相同时，Allow 一般获胜。
需要注意的是，這是 Google 的規則，其他搜尋引擎爬虫的實現不一定完全一致；而且只有在長度相同时才去比較 Allow 與 Disallow，長度不同时一律以更長的那條為准。很多誤屏蔽就出在“目錄級 Disallow 一定能盖住子目錄”這種直觉判断上。
高频誤配形態
目錄規則被更長的規則反超
- Disallow: /search/
- Allow: /search/help/
第二條更長，因此 /search/help/ 下的頁面會被放行。如果本意是整目錄屏蔽，這種寫法就漏了一條口子。反向的例子更常见：本意只想放行某個静態资源，结果寫了一條更長的 Disallow，把整個栏目一起關掉。
通配符位置不当
例如只拦带排序參數的 URL，寫成 /*sort= 會把 /help/sorting-guide 這類正常路径一並拦掉。通配符越靠前，誤伤范围越大，建议尽量贴着具体的參數名寫。
结尾符 $ 的邊界
/*.pdf 會拦掉路径中含 .pdf 的地址，而 /*.pdf$ 只拦嚴格以 .pdf 结尾的地址。對于带參數的 PDF 連結（形如 /a.pdf?v=2），加了 $ 反而拦不住。
規則堆积導致無法推断
当 robots.txt 累积到几十條上百條，人眼已经很难推出某條 URL 的最终结果。建议定期合並同類規則、刪除已经失效的條目。
核對清單
- 確認全站只有一份生效的 robots.txt，HTTP 與 HTTPS、带 www 與不带 www 的入口返回同一份内容，不存在内容不一致或兜底 404。
- 检查 robots.txt 本身的响應狀態：返回 404 通常表示全站放行，返回 5xx 則可能让部分爬虫暂时放慢甚至暫停抓取。
- 把現有規則按路径長度排序，逐條自問：這條是想放行還是想屏蔽，實际结果是否一致。
- 重点排查 Disallow 目錄下是否存在更長的 Allow，以及 Allow 目錄下是否存在更長的 Disallow。
- 检查通配符與结尾符的组合，尤其是带參數 URL、静態资源目錄和多語言路径。
- 確認没有誤把 Sitemap 地址、CSS/JS 目錄、分頁路径寫進 Disallow，這些會连带影响渲染结果與入口發現。
- 確認没有用 robots.txt 去解决本该靠登入墙或頁面級指令處理的問题。
驗證與观察
改完之後不要只靠肉眼讀一遍。在搜尋蜘蛛的抓取日誌里，观察此前被拦目錄的請求量是否回升；如果仍然只有零星請求，說明屏蔽規則還在生效，或者该目錄本身就缺少内鏈入口，需要回到内鏈结构上找原因。
同时把 robots.txt 與 Sitemap 一起看：Sitemap 提交的 URL 若被 robots.txt 屏蔽，两者會互相打架，表面上提交量很大，實际抓取量却上不去。
robots.txt 只影响抓取，不决定收錄。被 Disallow 的 URL 依然可能因為外部連結出現在结果頁里，需要屏蔽展示时應改用頁面級指令。
小结
把 robots.txt 当成一份需要评审的配置而不是随手寫的文本：規則尽量少、尽量具体，改動後结合抓取日誌做一次回看。抓取入口這件事，能少一层歧义就少一层。