robots.txt 是放在站点根目錄下的一份纯文本文件，用来告诉爬虫哪些路径可以抓、哪些路径不必抓。它既不是收錄開關，也不是訪問密碼，只是抓取层面的一種约定。很多站点回头排查抓取異常，問题往往就出在這份被遗忘的小文件上。
一、先確認文件位置和訪問狀態
文件必须放在域名根目錄，例如 https://example.com/robots.txt，放在子目錄里的同名文件不會被识別。用浏览器直接訪問這個地址，確認返回 200，且内容是一段纯文本。如果返回 404，說明文件缺失或路径寫错；如果返回 403 或 5xx，可能是服務器權限、防火墙或重寫規則把它挡住了，需要先把訪問問题解决，再谈規則内容。
另外留意返回的 Content-Type，個別环境會把它当成下载文件或重定向到別的頁面，爬虫拿到的就不是規則本身。
二、分清 Disallow 與 Allow 的邊界
常见誤区是寫完 Disallow 就以為頁面不會再出現在搜尋结果里。實际上，禁止抓取不等于禁止索引，如果被禁止的地址有外部連結指向，仍可能以無描述的形式出現。真正想控制收錄要靠 noindex，但要注意：被 robots.txt 禁止抓取的頁面，爬虫讀不到頁面里的 noindex，效果會打折扣。這两者要配合使用，而不是互相替代。
几個高频翻车点
- 整站寫成 Disallow: /，本意是測試环境用，上线後忘了改回来。
- 目錄名寫错一個字母，比如實际是 /temp 却寫成 /tmp，規則没覆盖到目标路径。
- 使用通配符或结尾符号时，没確認目标爬虫是否支持同样的语法。
- 顺手屏蔽了 CSS、JS 目錄，導致爬虫渲染頁面时看不到完整内容。
- 把分頁、篩選參數一並屏蔽，结果列表頁後續内容長期没有入口被發現。
三、按爬虫分別寫規則
可以针對不同 UA 寫不同的 User-agent 段。如果只想给某個爬虫單獨限制，就為它單獨開一段；如果規則對所有爬虫都适用，用 User-agent: *。段落之間记得留空行，避免把下一段的 User-agent 当成上一條規則的延續。多數爬虫以匹配到的那一段為准，寫混了容易出現意想不到的结果。
四、用工具和日誌驗證，別靠肉眼
各家站長平台一般都有 robots.txt 測試工具，輸入具体 URL 就能看到是被允许還是被拦截，改完規則顺手测几個關键地址。同时可以在服務器日誌里搜尋该文件的請求记錄，看爬虫是否成功讀取、返回什么狀態碼。如果日誌里長期没有對 robots.txt 的請求，可能是服務器把它重定向了，或者返回了非文本類型，爬虫讀到的是空内容。
五、把维護纳入日常
站点改版、栏目調整、目錄迁移之後，robots.txt 很容易和現状脱节。建议把它列入改版检查清單，逐條對一遍：
- 新增目錄是否需要放行；
- 废弃目錄是否應该屏蔽；
- 被屏蔽的路径是否還有内鏈指過去；
- 規則是否與 noindex、canonical 的安排冲突。
改動前先备份原文件，改動後观察一段時間的抓取日誌，確認没有出現大范围抓取量下降。規則越简單清晰，出問题时越容易定位。
robots.txt 是抓取入口的規則說明，不是收錄開關。寫清楚、定期對一遍，比反复猜蜘蛛為什么不来的更省事。