聊抓取的时候，大部分讨论都围绕連結：内鏈够不够、Sitemap 全不全、路径深不深。但蜘蛛真正把頁面抓回去的前提，是服務器能把响應给出来。連結决定蜘蛛想去哪，服務器狀態决定它能不能到。很多站点 URL 發現慢、抓取量上不去，問题不在連結结构，而在响應质量。
一次抓取要過哪几道服務器關卡
從蜘蛛發出請求到拿到 HTML，中間要经過 DNS 解析、TCP 连接、TLS 握手、服務器處理、首字节返回（TTFB）和内容传輸。任何一环慢了或者断了，這次抓取就算失敗，或者被判為低质量。
- DNS 與连接：解析慢、连接被拒，蜘蛛连门都進不去。
- TTFB：服務器處理時間過長，蜘蛛的等待成本變高。
- 传輸：HTML 体积過大、中途中断，頁面拿不全。
- 並發：服務器拒绝過多连接，蜘蛛只能降低請求频率。
不同响應對抓取路径的實际影响
5xx：最需要警惕的一類
500、502、503、504 表示服務器端没能正常完成請求。蜘蛛遇到 5xx 通常會重试，但如果某個目錄下大量 URL 连續返回 5xx，蜘蛛會降低對整站的抓取频率，已经排在队列里的 URL 也可能被推後。更麻烦的是 URL 發現：新地址即使被内鏈指向或在 Sitemap 里提交，只要反复返回 5xx，它就會一直停留在待抓取狀態。
429 與 503 加 Retry-After：別把它当成通用限流開關
有些站長為了控制抓取压力，對蜘蛛统一返回 429。短期看請求量确實下来了，但長期如此，蜘蛛會認為站点持續不可用，抓取节奏被压得很低。限流更合适的做法是控制單 IP 並發、给動態内容做缓存、把慢查询優化掉，而不是對所有請求一刀切。
超时與连接重置
服務器處理時間長于蜘蛛的等待上限，請求會被判超时。表現上和 5xx 類似：這次抓取没有结果，蜘蛛也不知道這個 URL 到底存不存在，于是不敢把它标记為已發現，容易反复回来试探。连接被中途重置則更糟，蜘蛛可能拿到残缺 HTML，如果初始 HTML 里缺了連結，那部分 URL 就發現不了。
200 但内容不完整
還有一種隐性情况：狀態碼正常，但内容是空壳，關键連結靠 JS 渲染，或者服務器按 UA、按地域返回了不同版本。對蜘蛛来说這次抓取是成功的，但抓到的連結集和你预期不一致，URL 發現自然會出現遗漏。
抓取路径被打断後的连鎖反應
單次失敗看起来不起眼，但影响會沿着路径扩散：
- 入口頁响應慢，蜘蛛在入口就消耗掉大部分耐心，深层頁排不上队。
- 中間层頁面返回 5xx，蜘蛛走不到它下面的連結，更深层 URL 的發現被推迟甚至中断。
- 服務器整体不稳定时，蜘蛛整体降速，Sitemap 里提交的 URL 也不會被優先處理。
- 反复失敗會让一些 URL 長期停留在已發現未抓取狀態，站内看起来提交了，實际没被處理。
怎么定位：抓取日誌和服務端指标對着看
單獨看抓取日誌很难判断是連結問题還是服務器問题，需要和服務端指标交叉比對。
- 日誌里的响應碼分布：如果 5xx 占比高，先修服務端，再谈内鏈。
- 响應時間分位：平均 TTFB 看着還行，但 P95、P99 很高，說明偶發慢請求正在拖累抓取。
- 蜘蛛 UA 的請求是否被限流、被 WAF 拦截、被 CDN 回源失敗。
- 同一 URL 在日誌中反复出現且都是失敗狀態，說明蜘蛛在重试，但一直没成功。
- 观察抓取高峰时段的 CPU、資料库连接數和慢查询數量。
可以落地的調整
- 優先保證入口頁、栏目頁的响應時間稳定，這些頁面决定蜘蛛能不能繼續往下走。
- 给耗时接口做缓存，减少動態渲染带来的 TTFB 波動。
- 對静態资源做長缓存和 CDN 分發，减少回源压力。
- 如果必须限流，用低频率的均匀限速，避免整段集中返回 429。
- 頁面体积控制在合理范围，避免蜘蛛下载到一半中断。
- 保持服務器時間准确，日誌時間對不上會让人誤判抓取节奏。
抓取路径由連結和服務器一起构成。連結再漂亮，服務器响應不给力，蜘蛛也走不到终点。排查抓取問题时，先確認服務端稳定，再看連結结构，顺序反了會浪費很多時間。
對 URL 發現来说，最實际的结论是：新地址被提交之後能不能被真正抓取，取决于服務器在那個时刻有没有把頁面正常交出去。稳定性不是優化項，它是抓取的前提。