很多人在排查目标URL不被抓取时，會忽略一個很靠前的位置：入口頁所在域名的 robots.txt。它是一份放在域名根目錄的纯文本文件，只對同一個域名生效。入口頁在 a 站、目标URL在 b 站，a 站的 robots.txt 寫错，不會直接让 b 站的頁面不被抓取，但可能让搜尋蜘蛛看不到入口頁上的連結，等于少了一條發現路径。
常见的配置错誤
全站封禁没删干净
從模板複製 robots.txt 时，最容易留下一個 Disallow: /。如果它出現在 * 段或某個具体爬虫段下面，入口頁整站都不會被請求，入口頁上放的連結自然也不會被讀到。
User-agent 寫法不規范
- 名稱後面带多余空格，或大小寫與官方寫法不一致；
- 用了不存在的爬虫名稱，規則實际落到 * 段上；
- 多個 User-agent 段混在一起，Allow 與 Disallow 的匹配顺序與预期不同。
把 Disallow 当成“禁止收錄”
Disallow 只是阻止抓取。如果某個入口頁被 Disallow 挡住，爬虫讀不到頁面上的 noindex 标簽，结果可能是頁面仍在结果里出現，而連結又没被跟進。要控制收錄，先允许抓取、再用 noindex，顺序不能反。
和 CDN、安全插件冲突
部分 CDN 或安全類插件會另外下發一份机器人規則，與根目錄的 robots.txt 内容不一致。排查时要確認爬虫實际拿到的是哪一份。
入口頁被挡之後會發生什么
入口頁被抓取，是搜尋蜘蛛讀到其中連結的前提。入口頁被自己的規則挡住时，蜘蛛通常只會請求 robots.txt，然後跳過頁面，連結也就没有被讀取的机會。此时目标URL的發現只能依靠其他入口頁、站内連結、sitemap、主動推送等渠道。如果所有入口頁共用同一個域名的同一份 robots.txt，這條路径會一起失效，影响面就比較集中。
怎么驗證是不是 robots.txt 的問题
- 用浏览器直接訪問入口域名的 /robots.txt，確認返回正常文本，不是 404，也不是 HTML 错誤頁。
- 用搜尋平台提供的 robots.txt 測試工具，分別輸入入口頁地址和目标URL地址，看结果是允许還是被阻止。
- 翻服務器訪問日誌：如果蜘蛛有規律地請求 robots.txt 且狀態碼正常，說明文件可讀；如果長期没有任何請求，問题可能在 DNS、CDN 或 WAF 层。
- 在日誌里找搜尋蜘蛛對入口頁 URL 的請求记錄。只有 robots.txt 的請求、没有入口頁的請求，基本可以判断入口頁被規則挡住了。
- 核對最近一次改動時間，與日誌中入口頁請求量下降的時間点是否吻合。
修复时的几点建议
- 改動前先备份現有内容，方便回滚對比。
- 只放行需要抓取入口頁的爬虫段，尽量使用准确的爬虫名稱，而不是依赖 * 一刀切。
- 確認並移除誤加的 Disallow: /，保留必要的目錄限制即可。
- 修改後观察一到两周日誌，先看入口頁請求數是否恢复，再看目标URL是否出現新的抓取動作。
- 不要短期内反复改内容，避免爬虫按缓存的舊規則判断，導致資料看不出趋势。
robots.txt 是抓取開關，不是收錄開關，也不能保證已经抓取的頁面從结果里消失。它的作用范围只在目前域名之内。
入口頁的 robots.txt 只是發現鏈條上的一环。入口頁能被抓、連結能被讀到、目标URL能正常响應，這三件事同时成立，搜尋蜘蛛的跟進才會顺畅。排查时按這個顺序逐個確認，比只盯着一個文件更省時間。