排查 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 发现不至于完全断掉，但它只能补救，不能替代内链。
页面体积不是玄学指标，它直接决定抓取器能不能读到你的链接。把资源外链化、导航前置、列表分页，是比较省事的一套组合。