先把结论说清楚
大多數搜尋引擎的解析器對 HTML 都有字节上限，常见说法在几百 KB 到几 MB 之間，不同引擎不一样，也没有公開承诺。超過之後，後面的内容基本不會被解析，連結自然也就不會被發現。所以入口頁体积太大真正的風險不是收錄變差，而是排在後面的連結压根没被讀到。
連結在文档里的位置也确實會影响被讀到的概率。這不是玄学，是解析顺序的問题：解析自上而下流式進行，越靠後的内容越容易撞上上限或被提前中断。
哪些東西會把連結挤到後面
- 内联的 CSS 和 JS：一個几萬行的内联脚本，占的空間可能比所有連結加起来還大。
- base64 内联的图片、字体、图标。
- 大段模板注释、調试日誌、被注释掉的舊代碼。
- 重复的導航和頁脚块，每個頁面都完整塞一遍。
- 表格或列表里堆了几千行資料。
這里有個常被誤解的点：gzip / br 压缩只影响传輸体积，不影响解析时的字节數。传得再小，解析上限该撞還是會撞。
几個容易混淆的概念
抓取预算和解析上限不是一回事
抓取预算决定蜘蛛来多少次、抓多少頁；解析上限决定單頁能被讀多深。两個問题的成因不同，结果却常常一样：連結没被發現。
DOM 节点數量也有影响
部分渲染路径對 DOM 节点數同样有上限，节点太多时後半部分渲染出来的内容也可能丢。静態 HTML 里直接寫連結，比依赖 JS 渲染更稳。
實际怎么處理
- 把入口頁做成薄頁面：只保留标题、少量說明和連結列表，样式和脚本放外部文件。
- 連結列表尽量往前放，別排在几千行内容之後。導航块甚至可以放到連結列表下面。
- 條目多就分頁。一頁放几十到一两百條，比一頁塞几千條更容易被完整讀到。
- 内联资源換成外鏈，图片用真實 URL 而不是 base64。
- 上线前看一下 HTML 的原始字节大小（不是压缩後的大小），超過几百 KB 就考虑拆。
- 入口頁不要承载全站資料，那是資料库该做的事，不是 HTML 该做的事。
判断方法很简單：把頁面另存為 HTML 看文件多大，再用纯文本方式打開，看開头 100 KB 能不能覆盖大部分連結。如果連結都落在後半段，就该調整结构了。
几個常见疑問
把連結放前面就一定被抓吗
不一定。位置只解决能不能被讀到的問题，能不能被抓還取决于服務器响應、robots 規則、URL 本身是否可訪問等。但位置是你最容易控制的一环。
頁面很大但蜘蛛還是来了，是不是就没事
来得勤不代表讀得完整。日誌里能看到抓取记錄，但看不到它解析到了哪一行。別把抓取成功等同于連結被發現。
分頁會不會削弱效果
不會。分頁只是把連結拆到多個 URL 上，每個 URL 各自處在解析上限内。前提是分頁本身也能被蜘蛛發現，並且做好上一頁、下一頁的連結。
一句话：入口頁是给蜘蛛讀的，不是给人看的。控制体积、把連結提前，是成本最低的一件事。