頁面内容寫得再完整，如果服務器在蜘蛛来的时候答不上话，收錄流程也走不到下一步。抓取是收錄的前置條件，而狀態碼、响應時間、连接是否稳定，决定了蜘蛛這一次訪問是“拿到内容”還是“记一筆帳下次再来”。
先分清两類“抓不到”
4xx 和 5xx 在蜘蛛眼里完全不是一回事。
- 404 / 410：地址确實没有内容，這是明确表態，蜘蛛會逐步把舊 URL 從索引中清理出去，410 比 404 更干脆。
- 5xx（500、502、503、504）：服務器自己出了問题，属于暂时性故障。蜘蛛通常不會因此判定頁面消失，而是记為抓取異常，過一阵子再试。
把 5xx 当 404 處理，或者反過来，都會让索引狀態變得混乱。比如一個临时维護的頁面连續几天返回 500，蜘蛛不會立刻删掉索引里的舊版本，但如果拖得太久，抓取频次會被下調，頁面更新也跟着延迟。
蜘蛛遇到 5xx 之後會做什么
多數搜尋引擎對 5xx 采用“重试加退避”的策略：第一次失敗後不會马上放弃，而是隔一段時間再试；连續失敗則會拉長間隔、降低该目錄的抓取配額。這個過程對站長不可见，你能看到的是日誌里同一批 URL 反复出現 5xx，而索引里的版本停在几天前。
如果整站在某個时段集中返回 5xx，影响范围會從單個頁面扩大到抓取预算——蜘蛛把時間花在等待超时上，真正该抓的新 URL 反而排到了後面。
超时和慢响應，比错誤碼更隐蔽
狀態碼至少會留痕，响應慢則容易被忽略。常见情况有：
- 首字节時間很長，蜘蛛等到超时就断開，日誌里可能连完整狀態碼都没记下来；
- 資料库查询或第三方接口拖慢頁面，動態頁面尤其明顯；
- 同一時間涌入大量請求，服務器排队，部分請求被直接丢弃。
這類問题不會让頁面被判為“不存在”，但會明顯降低蜘蛛愿意抓取的频次。對更新频繁的站点来说，抓取频次下降往往就表現為“新頁面發布後很久才被處理”。
需要限速时，用服務器能听懂的方式说
如果确實不想让蜘蛛抓得太猛，不要靠随机返回 500 来“劝退”，那只會被当成故障。更稳妥的表達方式有两種：
- 503 加 Retry-After：明确告诉蜘蛛“我暂时不可用，請在指定時間後再来”。這属于标准语义，通常不會被理解為頁面消失。
- 429：表示請求過多，适合接口或高负载时段使用。
robots.txt 里的 Crawl-delay 只有部分蜘蛛支持，不能当作唯一手段；真正的限速還是要落在服務器层的並發控制和缓存上。
排查顺序：從日誌里的狀態碼分布開始
遇到收錄變慢、頁面更新不上，先別急着改内容，先看服務器日誌：
- 把蜘蛛請求按狀態碼分组，看 5xx 與超时所占的比例；
- 看失敗是集中在某些目錄、某些參數，還是覆盖全站；
- 對比失敗时段與服務器负载、發布操作、缓存刷新是否重合；
- 確認 404 是否被当成兜底响應返回，從而掩盖了真實故障。
抓取失敗本身不是内容問题，但结果常常以“收錄問题”的形式表現出来。先確認蜘蛛到底拿到了什么，再谈頁面本身。
把服務器稳定性当成收錄的基础设施来看待：狀態碼语义正确、响應時間可控、限速方式規范，蜘蛛才愿意把有限的抓取額度持續投到你的站点上。至于多久恢复抓取频次、多久重新處理頁面，取决于故障持續時間、站点規模和歷史表現，没有统一的數字。