先明确一点：蜘蛛抓取頁面时通常存在一個讀取上限，但這個上限各家搜尋引擎都没有公開标准，也會随頁面類型和時間調整。它不是一條可以卡着算的红线，而是一種倾向——頁面越臃肿，讀到後面内容的概率越低，解析出来的連結和正文也越容易打折扣。
為什么會有“讀不完”這回事
抓取是有成本的。搜尋引擎每天要處理海量 URL，每個頁面能分配到的下载量、解析量和存储量都有限。当 HTML 体积超出一定范围，抓取程序可能只保留前面一部分字节，後面的内容不再進入解析流程。這不等于判定頁面有問题，只是後面的内容没被“看到”。
更常见的情况是没被硬截断，但被稀释：正文埋在几萬行 DOM 里，連結藏在底部大段脚本後面，蜘蛛虽然下载完了，解析时有效内容已经被摊薄。
哪些東西最容易把頁面撑大
内联脚本與样式
把整個前端框架、埋点代碼、样式表直接寫進 HTML，是体积膨胀最快的方式。這些東西對蜘蛛發現連結和讀取正文几乎没有帮助，却占掉了最前面的字节。
冗余的 DOM 與属性
层层包裹的容器、大量只用于样式控制的 class、重复的 data 属性，會让 DOM 节点數迅速上升。节点太多时，解析成本和内存占用都會增加，連結所在的上下文也變得更难判断。
内联图片與資料块
base64 图片、内联 JSON、把整個列表塞進初始 state，這些内容動辄几十上百 KB，對蜘蛛来说基本是噪声。
頁面被“讀不完”时會有哪些表現
- 頁脚、分頁、相關推荐里的連結長期不被抓取；
- 日誌里抓取响應正常，但解析出的連結數明顯少于實际存在的數量；
- 正文靠後的段落、表格後面的部分没有被正确理解；
- 同一模板的頁面抓取表現差异很大，往往是某個頁面多了内联資料。
這些現象也可能由其他原因造成，不能只凭体积下结论，要结合抓取日誌和内鏈结构一起看。
给頁面瘦身的几個方向
- 把重要内容放前面。标题、正文主体、主要導航連結尽量出現在 HTML 前部，把統計脚本、客服组件、推荐模块往後放。
- 外鏈化脚本與样式。能拆成獨立文件的就拆走，让 HTML 只保留结构。
- 控制 DOM 层級。减少無意义的嵌套容器，清理只服務于舊样式的包装节点。
- 图片用真實地址。除极少數图标外，不要 base64 内联；初始資料用接口按需加载，而不是全部寫進 HTML。
- 長内容适当分节或分頁。超長列表、超長文档可以拆成多頁，並保證分頁連結可被抓取到。
- 開啟压缩传輸。gzip 或 brotli 能明顯降低下载体积，對抓取节奏有實际帮助。
別為了瘦身把内容砍掉
体积是參考指标，不是優化目标。為了减字节而删掉正文、隐藏連結、把内容改成图片，只會让頁面更难被理解。
真正要控制的是無效字节的比例：脚本、样式、内联資料、重复结构占了多少，有效正文和連結又占了多少。判断标准可以很朴素——如果一個用戶禁用脚本打開頁面，還能看到主体内容和主要連結，那這個頁面大致是稳的。
實际操作顺序
先挑一個典型模板頁，用浏览器查看源碼，看正文第一條有效連結出現在第几屏、整個 HTML 有多大、DOM 节点有多少。再對照抓取日誌，看這個模板下的連結抓取率和其他模板差多少。找出最胖的几個模板先改，改完观察一两周日誌變化，再决定要不要繼續調整。整個過程不用追求某個具体數字，只要让關键内容尽量靠前、让噪声尽量靠後，頁面被完整讀取的概率就會提高。