很多站点在服務器根目錄放了 robots.txt，但真正定期检查的人並不多。它看起来只是一段文本，實际却會影响搜尋引擎蜘蛛能否發現和抓取 URL。寫错規則时，問题往往不會立刻暴露：頁面還能正常訪問，用戶也能打開，只是蜘蛛不再来了。
這篇文章不讲复杂语法，只整理一份 robots.txt 自查思路，适合在改版、上线新栏目、調整目錄後逐項過一遍。
先確認它是不是真的在生效
第一步不是看規則，而是確認文件位置和狀態。robots.txt 必须放在站点根目錄，例如 https://www.example.com/robots.txt，不能放在子目錄里。用浏览器或 curl 訪問，返回狀態碼應当是 200，内容類型通常是 text/plain。如果返回 404，蜘蛛會認為没有限制；如果返回 403 或 5xx，不同爬虫的處理方式可能不一样，容易造成抓取異常。
還要注意域名。如果有 www 和非 www、HTTP 和 HTTPS 多個版本，確認每個可訪問的主机名都返回同一份規則，或者至少確認蜘蛛實际訪問的那個版本没有問题。
這些常见寫法容易誤伤
- 全站屏蔽後忘记刪除。測試环境常用的 Disallow: / 如果同步到了正式环境，會直接挡住整站抓取。上线前检查一次，比事後补救省事。
- 屏蔽 CSS、JS 等静態资源。有些規則為了省流量，把 /assets/、/static/ 整個目錄 disallow。蜘蛛拿不到样式和脚本，可能影响對頁面内容的理解。除非你明确知道後果，否則不要屏蔽渲染所需资源。
- 用 robots.txt 處理不该被收錄的頁面。robots.txt 只是“不要抓取”，不是“不要索引”。如果頁面已经被外部連結指向，搜尋引擎仍可能僅凭連結把它展示出来。真正不想被索引的頁面，應使用 noindex，並且确保蜘蛛能訪問到该頁面。
- 規則顺序和匹配范围寫错。User-agent、Allow、Disallow 的匹配存在優先級差异，通配符和结尾符号也容易寫多寫少。比如想屏蔽 /search/，却寫成了 /search，可能把 /search-engine/ 之類的路径也挡住。改寫後最好用官方測試工具驗證。
- Sitemap 地址寫错或漏寫。Sitemap 声明不是必须，但寫了就要保證地址可訪問、内容有效。如果站点有多個子 Sitemap，也可以在這里匯總声明。
自查时重点看什么
- 確認重要栏目、詳情頁、列表頁没有被誤屏蔽。可以按目錄层級逐個核對，尤其是新上线的频道。
- 確認不想被抓取的路径确實寫進了規則，例如後台、搜尋结果頁、带參數的篩選頁。但不要依赖它做安全防護。
- 確認没有把整站资源目錄一棍子打死。图片、CSS、JS 是否允许抓取，要结合頁面渲染方式判断。
- 確認規則没有相互矛盾。同一 User-agent 下，Allow 和 Disallow 同时出現时，理解清楚哪條生效。
- 確認文件编碼和換行正常。虽然不复杂，但複製粘贴时带入特殊字符，也可能让規則解析異常。
改完之後怎么驗證
不要只看文件内容。可以用搜尋引擎提供的 robots.txt 測試工具，輸入具体 URL，看它是否被允许抓取。也可以结合服務器日誌，观察蜘蛛對重要目錄的請求是否恢复。如果站点有搜尋资源平台帳號，抓取統計和覆盖率报告也能提供參考，但它們反映的是趋势，不是實时结果。
如果最近刚調整過目錄或換了域名，建议把舊規則、新規則各留一份记錄，寫清楚修改時間和原因。過一段時間再回看，能快速判断某次抓取下降是否和規則變更有關。
把 robots.txt 当成一份给蜘蛛看的“站点說明书”，而不是權限系統或萬能開關。它越简單、越明确，越不容易出错。
日常维護的小习惯
- 每次改版、上线新栏目、調整 URL 结构後，把 robots.txt 加入检查清單。
- 不要把測試环境的屏蔽規則直接合並到正式环境，發布前人工確認。
- 如果使用了 CDN 或 WAF，確認它們没有額外拦截蜘蛛，也没有缓存一份過期的 robots.txt。
- 定期查看服務器日誌中蜘蛛的訪問狀態，發現大量 403、404 或超时，再回头检查規則和服務器配置。
robots.txt 本身不复杂，复杂的是站点结构變化後，規則没有跟着更新。把它当作站点运营中的一個小型配置項，定期核對，通常就能避開大部分“蜘蛛突然不来了”的誤會。