先把结论说清楚
大多数搜索引擎的解析器对 HTML 都有字节上限，常见说法在几百 KB 到几 MB 之间，不同引擎不一样，也没有公开承诺。超过之后，后面的内容基本不会被解析，链接自然也就不会被发现。所以入口页体积太大真正的风险不是收录变差，而是排在后面的链接压根没被读到。
链接在文档里的位置也确实会影响被读到的概率。这不是玄学，是解析顺序的问题：解析自上而下流式进行，越靠后的内容越容易撞上上限或被提前中断。
哪些东西会把链接挤到后面
- 内联的 CSS 和 JS：一个几万行的内联脚本，占的空间可能比所有链接加起来还大。
- base64 内联的图片、字体、图标。
- 大段模板注释、调试日志、被注释掉的旧代码。
- 重复的导航和页脚块，每个页面都完整塞一遍。
- 表格或列表里堆了几千行数据。
这里有个常被误解的点：gzip / br 压缩只影响传输体积，不影响解析时的字节数。传得再小，解析上限该撞还是会撞。
几个容易混淆的概念
抓取预算和解析上限不是一回事
抓取预算决定蜘蛛来多少次、抓多少页；解析上限决定单页能被读多深。两个问题的成因不同，结果却常常一样：链接没被发现。
DOM 节点数量也有影响
部分渲染路径对 DOM 节点数同样有上限，节点太多时后半部分渲染出来的内容也可能丢。静态 HTML 里直接写链接，比依赖 JS 渲染更稳。
实际怎么处理
- 把入口页做成薄页面：只保留标题、少量说明和链接列表，样式和脚本放外部文件。
- 链接列表尽量往前放，别排在几千行内容之后。导航块甚至可以放到链接列表下面。
- 条目多就分页。一页放几十到一两百条，比一页塞几千条更容易被完整读到。
- 内联资源换成外链，图片用真实 URL 而不是 base64。
- 上线前看一下 HTML 的原始字节大小（不是压缩后的大小），超过几百 KB 就考虑拆。
- 入口页不要承载全站数据，那是数据库该做的事，不是 HTML 该做的事。
判断方法很简单：把页面另存为 HTML 看文件多大，再用纯文本方式打开，看开头 100 KB 能不能覆盖大部分链接。如果链接都落在后半段，就该调整结构了。
几个常见疑问
把链接放前面就一定被抓吗
不一定。位置只解决能不能被读到的问题，能不能被抓还取决于服务器响应、robots 规则、URL 本身是否可访问等。但位置是你最容易控制的一环。
页面很大但蜘蛛还是来了，是不是就没事
来得勤不代表读得完整。日志里能看到抓取记录，但看不到它解析到了哪一行。别把抓取成功等同于链接被发现。
分页会不会削弱效果
不会。分页只是把链接拆到多个 URL 上，每个 URL 各自处在解析上限内。前提是分页本身也能被蜘蛛发现，并且做好上一页、下一页的链接。
一句话：入口页是给蜘蛛读的，不是给人看的。控制体积、把链接提前，是成本最低的一件事。