抓取不只是“访问一次 URL”。蜘蛛拿到 HTML 之后还要解析：抽链接、切正文、读结构化数据。解析同样消耗资源，所以搜索引擎通常会给单个页面设一些隐性上限。页面越大、链接越多、结构越乱，越容易在后半段被提前截断。这类问题不会报错，只会安静地少发现几个 URL。
解析过程中的三个常见停止点
各家没有统一标准，但工程上常见的限制集中在三处：
- 响应体大小：HTML 太大，超出处理上限的部分不再解析。超长页面里的链接和正文，都可能落在截断线之后。
- 链接数量：一页里铺了成百上千条链接时，引擎可能只处理其中一部分，或对整页的链接权重做稀释。
- 结构复杂度：极度嵌套的 DOM、成片的内联脚本和样式，会增加解析负担，也更容易让正文识别跑偏。
三者的共同点是：你看到的页面是完整的，蜘蛛拿到的可能只是前半截。
链接太多时的真实代价
目录页、标签页、聚合列表把几百条链接铺在一个页面里很常见。多数时候不会立刻出问题，但有两个副作用值得留意：
- 重要链接被淹没在重复链接里，比如每页都出现的导航、页脚、推荐位。
- 新链接的发现被拉长，蜘蛛要分几次回来，才能把这一页的链接走完。
把列表拆成合理的分页，或在列表页只保留必要的入口，比一页塞满更容易被稳定处理。
正文被挤到后面
有些页面把正文压在一层层容器里，前面几十行都是脚本、弹窗占位和广告位。这带来两个问题：正文提取可能不准；首屏之外的重要链接，可能落在解析范围的边缘。
一个简单的判断方式：把页面 HTML 从头到尾看一遍，找出正文和核心链接大概出现在第几屏的位置。
抓取成功不等于解析完整
服务器日志里出现 200，只能说明这一次下载成功。链接有没有被提取、正文有没有被正确切分，日志本身看不出来。要判断解析是否完整，得从结果反推：页面里写了多少条内链，实际有多少条被访问过；正文里的关键内容，有没有出现在搜索结果的摘要里。两者差距过大时，再回头去看页面体积和结构，这个顺序比盲目压缩 HTML 更省事。
可以落地的检查动作
- 查看响应体大小，和同类页面做对比。明显偏大的，优先排查图片是否被内联为 base64、是否把整站数据打进了 HTML。
- 数一数页面里的 a 标签数量，去掉导航、页脚、侧栏里的重复项后还剩多少。
- 抽查日志：某一区块的链接是否长期没有被访问过。如果链接在源码里存在却从不被抓，解析截断是可能的解释之一。
- 用 Sitemap 兜底，把截断风险高的深层 URL 单独列出来。
调整方向
- 列表类页面拆页，单页链接控制在自己能维护的范围内。
- 把正文相关结构提到前面，减少无意义的容器嵌套。
- 懒加载的内容尽量在服务端输出，或保留可被抓取的静态链接。
- 定期看页面体积的增长趋势，模板改动和组件堆叠，往往会让体积悄悄变大。
这些调整不会让蜘蛛一定来，也不保证收录。它们做的是减少“链接明明在，蜘蛛却走不到”的情况。抓取路径的顺畅程度，很多时候就是被这类细节一点点削掉的。