很多人把入口页当成一张清单，恨不得一次性把几千个链接全塞进去。但搜索蜘蛛抓取一个页面时，并不是“看到多少就处理多少”——它只解析响应体的一部分，超过这个量的内容往往不会被继续读取。于是就出现一个实际问题：当 HTML 体积过大时，排在后面的链接有可能根本不会被发现。
搜索蜘蛛读取页面时确实有“读取上限”
主流搜索引擎对单个 HTML 文档的大小都有类似限制，但各家数值不同，也没有公开统一的标准，具体以各引擎官方文档为准。历史上 Google 提到的量级在 2MB 左右，其他引擎的量级并不一致。关键有两点：
- 上限针对的是 HTML 源码本身，不是你眼里的“页面有多长”；
- 超限的部分通常不再解析链接，页面整体也未必被判为无效，但链接就被漏掉了。
体积是怎么被撑大的
- 把图片以内联 base64 的形式写进 HTML，一条就几百 KB；
- 内联大段 CSS、JS，或者模板里重复渲染统计代码；
- 每条链接外面包了多层 div、table 或大量 style 属性；
- 锚文本、title、说明文字写得很长，逐条累加；
- 一次放几千条链接，光 li 标签就能堆出很大体积。
怎么判断自己的入口页有没有超
- 浏览器“查看源代码”，另存为文件，直接看未压缩的体积；
- 做一个只保留链接的极简版本做对比，看体积主要来自哪里；
- 在抓取日志里观察搜索蜘蛛对该页的抓取频次、返回码和响应大小；
- 用抓取模拟工具确认拿到的 HTML 是否完整、链接是否都在。
如果发现体积的大头来自内联资源或冗余标签，而不是链接本身，那说明还有很大的压缩空间。
更稳妥的几种组织方式
- 把链接往前放：别让关键链接被模板、页脚、统计脚本压在最后；
- 减少内联资源：CSS/JS 尽量外链并压缩，图片用外链地址；
- 分批投放或分页承载：新链接分几次添加，每页控制在较轻的量级；
- 让入口页只做“发现”这一件事：不要顺手塞无关正文、广告、推荐模块；
- 用 sitemap 作为补充通道：不要把发现 URL 的希望全部压在入口页上。
体积上限只影响“链接能不能被解析到”，并不决定收录。链接被发现，也只是进入待抓取队列，后续是否抓取、抓多少，仍由搜索引擎自己决定。
几个容易踩的误区
- 以为开启 gzip 传输就能绕过限制：上限通常按解压后的内容计算；
- 以为链接数量比体积更重要：几千条链接挤在超大页面里，可能一条都没被读到；
- 以为链接藏在折叠区域就没事：折叠多由 CSS/JS 控制，HTML 里还在就照样算体积；
- 以为页面能正常打开就说明没问题：人能滚到底，蜘蛛未必读到那么远。
入口页的核心任务很简单：把 URL 交出去。保持 HTML 轻、结构简单、链接位置靠前，比追求单页链接总数更实际。我们能控制的是别让体积成为发现环节的障碍，剩下的交给各引擎自己的抓取策略。