robots.txt 是少數「改一行就可能让整站抓取停摆」的文件。它本身不产生内容，也不保證收錄，但一旦寫错，蜘蛛會直接放弃抓取，後面所有關于收錄的動作都没有意义。真正麻烦的是，出错时往往不會有明顯报错，只有抓取量悄悄下滑、收錄慢慢减少。
下面這條顺序适用于大多數情况：先確認問题、再止损、然後重新递出入口、最後才是等收錄恢复。
一、先確認影响范围，別急着大改
發現收錄下滑後，第一步不是改文件，而是確認 robots.txt 到底屏蔽了什么。
- 用搜尋引擎官方的 robots 測試工具讀取线上文件，而不是看本地草稿。
- 检查是否出現了 Disallow: / 這類整站屏蔽，尤其是临时調试後忘记刪除。
- 检查是否屏蔽了 CSS、JS、图片等渲染资源。頁面本身可抓，但渲染资源被挡，蜘蛛拿到的可能是一個空壳。
- 检查 Sitemap 行指向的地址是否也被 Disallow 覆盖，屏蔽 sitemap 會让入口提交失效。
- 確認线上返回的是 200 且内容正确，而不是 404、403 或跳轉到驗證頁。
如果只是屏蔽了某個目錄，影响是局部的；如果是整站或渲染资源，問题會被放大。
二、止损：让文件回到可抓取狀態
確認之後尽快恢复，動作要一次到位，避免反复修改。
- 修正 robots.txt 並發布，確認线上已经生效。
- 检查 CDN、反向代理、對象存储的缓存，舊版本被缓存會让修改變成「看起来改了」。
- 確認 robots.txt 没有被 WAF、防盗鏈或人机驗證拦截，這類拦截對蜘蛛来说等同于無法讀取。
- 用不同 UA 各請求一次，確認返回内容一致。
三、重新递出入口，恢复抓取信号
文件恢复只是让门重新打開，蜘蛛不會立刻回来。接下来要主動把重要 URL 再递一次。
- 重新提交 sitemap，並確認里面只有可索引、返回 200 的規范 URL。
- 對更新频繁的頁面使用 IndexNow 或對應的提交接口，但不要高频重复提交同一批地址。
- 检查站内導航、面包屑、列表頁和正文内鏈是否仍指向這些 URL，内部連結是長期有效的發現路径。
- 观察服務器日誌中蜘蛛的請求量、狀態碼和抓取路径，確認它重新開始走正常入口。
這里不需要額外堆一堆提交渠道，重点是让入口清晰、可達、稳定。
四、等收錄恢复：分清抓取恢复和索引恢复
抓取频次通常在几天内就會有反應，索引變化慢得多，可能是几周級別。這段時間可以观察：
- 日誌里蜘蛛請求數是否回到改错之前的水平。
- 索引报告中「已抓取未索引」「已發現未抓取」的數量變化。
- 頁面是否仍被判定為重复或内容單薄，這類問题不會因為 robots 修好就自動消失。
robots.txt 修好只解决了「能不能抓」，能不能收錄仍然取决于頁面本身的质量、重复度與站点整体信任度。
五、長期预防：把風險挡在改動之前
- 測試环境用訪問密碼或獨立域名隔离，不要靠 robots.txt 屏蔽。
- 任何 robots.txt 改動都走一次评审，並记錄修改時間、内容和负责人。
- 發布後立刻用线上地址驗證一次，不要只看本地文件。
- 需要临时屏蔽时，尽量只屏蔽目錄，不屏蔽整站，並設定明确的恢复時間。
把 robots.txt 当成配置资产而不是随手改的文本文件，收錄波動會少很多。真出問题时，按「確認范围—止损—递入口—观察恢复」的顺序走，比反复修改、到處提交要有效得多。