抓取不只是“訪問一次 URL”。蜘蛛拿到 HTML 之後還要解析：抽連結、切正文、讀结构化資料。解析同样消耗资源，所以搜尋引擎通常會给單個頁面设一些隐性上限。頁面越大、連結越多、结构越乱，越容易在後半段被提前截断。這類問题不會报错，只會安静地少發現几個 URL。
解析過程中的三個常见停止点
各家没有统一标准，但工程上常见的限制集中在三處：
- 响應体大小：HTML 太大，超出處理上限的部分不再解析。超長頁面里的連結和正文，都可能落在截断线之後。
- 連結數量：一頁里铺了成百上千條連結时，引擎可能只處理其中一部分，或對整頁的連結權重做稀释。
- 结构复杂度：极度嵌套的 DOM、成片的内联脚本和样式，會增加解析负担，也更容易让正文识別跑偏。
三者的共同点是：你看到的頁面是完整的，蜘蛛拿到的可能只是前半截。
連結太多时的真實代價
目錄頁、标簽頁、聚合列表把几百條連結铺在一個頁面里很常见。多數时候不會立刻出問题，但有两個副作用值得留意：
- 重要連結被淹没在重复連結里，比如每頁都出現的導航、頁脚、推荐位。
- 新連結的發現被拉長，蜘蛛要分几次回来，才能把這一頁的連結走完。
把列表拆成合理的分頁，或在列表頁只保留必要的入口，比一頁塞满更容易被稳定處理。
正文被挤到後面
有些頁面把正文压在一层层容器里，前面几十行都是脚本、彈窗占位和广告位。這带来两個問题：正文提取可能不准；首屏之外的重要連結，可能落在解析范围的邊缘。
一個简單的判断方式：把頁面 HTML 從头到尾看一遍，找出正文和核心連結大概出現在第几屏的位置。
抓取成功不等于解析完整
服務器日誌里出現 200，只能說明這一次下载成功。連結有没有被提取、正文有没有被正确切分，日誌本身看不出来。要判断解析是否完整，得從结果反推：頁面里寫了多少條内鏈，實际有多少條被訪問過；正文里的關键内容，有没有出現在搜尋结果的摘要里。两者差距過大时，再回头去看頁面体积和结构，這個顺序比盲目压缩 HTML 更省事。
可以落地的检查動作
- 查看响應体大小，和同類頁面做對比。明顯偏大的，優先排查图片是否被内联為 base64、是否把整站資料打進了 HTML。
- 數一數頁面里的 a 标簽數量，去掉導航、頁脚、侧栏里的重复項後還剩多少。
- 抽查日誌：某一区块的連結是否長期没有被訪問過。如果連結在源碼里存在却從不被抓，解析截断是可能的解释之一。
- 用 Sitemap 兜底，把截断風險高的深层 URL 單獨列出来。
調整方向
- 列表類頁面拆頁，單頁連結控制在自己能维護的范围内。
- 把正文相關结构提到前面，减少無意义的容器嵌套。
- 懒加载的内容尽量在服務端輸出，或保留可被抓取的静態連結。
- 定期看頁面体积的增長趋势，模板改動和组件堆叠，往往會让体积悄悄變大。
這些調整不會让蜘蛛一定来，也不保證收錄。它們做的是减少“連結明明在，蜘蛛却走不到”的情况。抓取路径的顺畅程度，很多时候就是被這類细节一点点削掉的。