排查 URL 發現慢的时候，大多數人的第一反應是内鏈不够、Sitemap 没提交。但還有一個更隐蔽的原因：頁面本身太大，抓取器還没讀到你的連結，就已经停了。這不是什么玄学，而是抓取端為了控制成本设定的讀取上限。
抓取器一次能讀多少
主流搜尋蜘蛛在解析 HTML 时都有單頁字节上限的设定，超過部分會被丢弃。換句话说，頁面後半段寫在源碼里的連結，在它眼里可能等于不存在。各家具体數值不同，也不會公開承诺，因此把單頁 HTML 控制在几百 KB 以内是比較稳妥的做法。
這里说的体积指原始 HTML，不是渲染後的頁面。浏览器會耐心讀完整個文档，所以你在本地打開一切正常，不代表抓取端也讀到了同一份内容。
頁面是怎么被撑大的
多數站点的頁面膨胀不是一次造成的，而是模板一层层叠上去的结果。常见的几類：
- 把整段框架代碼、統計脚本内联寫在 head 里，几千行起步；
- 图片轉成 base64 内联，一張图就是几十上百 KB；
- 隐藏的彈窗、下拉菜單、备用模板同时寫進了 DOM；
- 大段注释、調试代碼、废弃样式没有清理；
- 把整個 JSON 資料直接塞進頁面。
這些内容單獨看都不算离谱，叠加起来就很容易把一個本该几十 KB 的頁面推到几百 KB 以上。
連結被截断之後會怎样
後果分两種情况。如果這些連結還能從導航、首頁或 Sitemap 到達，URL 發現只是慢一点，問题不大；如果它們只出現在頁面底部，那基本等于没被發現，相關頁面會長期停留在很低的抓取频率里。
更麻烦的是判断困难。日誌里看到蜘蛛来過，狀態碼是 200，一切正常，但它到底讀到了第几個連結，日誌並不直接告诉你。要確認，得看抓取端拿到的原始 HTML 里，目标連結是否還在。
减重的同时保住連結
目标不是把頁面做得多小，而是让该被發現的連結落在有效讀取范围内。可以按下面的顺序調整：
- 把主要導航、分類入口放在 body 開头，不要靠绝對定位把内容推到文档後面；
- 内联脚本改為外鏈引用，或至少整体挪到 body 末尾；
- 图片恢复成外鏈 src，去掉 base64 内联；
- 隐藏内容按需插入，而不是一次性寫進 HTML；
- 列表頁做分頁或分段輸出，一頁別硬塞几百條連結。
這几步做完，頁面体积通常會明顯下降，同时連結位置也更靠前，對 URL 發現是双重收益。
怎么驗證效果
服務器日誌里能看到蜘蛛每次抓取返回的字节數，如果某個頁面反复返回几百 KB 以上，就值得检查。也可以用抓取模拟工具查看原始 HTML，數一下關键連結是否都在前半部分。
Sitemap 在這里是兜底手段：即使某條連結因為截断没被讀到，Sitemap 里仍然申报過，URL 發現不至于完全断掉，但它只能补救，不能替代内鏈。
頁面体积不是玄学指标，它直接决定抓取器能不能讀到你的連結。把资源外鏈化、導航前置、列表分頁，是比較省事的一套组合。