很多人排查收錄問题，习惯從連結和 sitemap 入手，却容易忽略更基础的一件事：搜尋引擎得先把頁面完整拿下来、讀懂它。頁面体积過大、DOM 层級過深、内联资源過多，都會让這一步變慢，抓取频次和後續的索引處理也會跟着受影响。
抓取一個頁面，引擎要付出什么成本
每次抓取都是一次资源投入：發起請求、接收响應、解析 HTML、执行渲染、提取正文和連結。在總预算相對固定的情况下，能抓多少頁面，取决于每個頁面有多“重”。同样一批 URL，如果單頁响應体普遍是數百 KB，抓取調度占用的時間和带宽就會明顯更多。
收錄問题有时不是“要不要收錄”，而是“能不能顺畅讀到”。
HTML 体积：先看有没有異常，而不是追一個數字
没有适用于所有搜尋引擎的公開硬阈值，所以不建议拿某個數字当红线。更實用的判断方式是對比：同一站点内，同類模板的頁面 HTML 大小是否接近；某個頁面是否比同類頁面大出數倍甚至十几倍。
- 整段样式表或脚本被内联進每個頁面，重复体积随頁面數量放大。
- 图片、字体以 base64 形式寫進 HTML，体积膨胀且無法單獨缓存。
- 列表頁一次性輸出几百上千條資料，或者把大量隐藏内容塞進头部区块。
- 模板注释、調试信息、未使用的组件代碼被一起打包輸出。
如果命中了其中几條，先把模板精简一遍，通常比反复提交 URL 更有意义。
DOM 层級與节点數量
HTML 大，往往 DOM 也深。過深的嵌套會增加解析和渲染耗时，正文與連結的提取也更容易被噪声干扰。自查时可以看两点：從根节点到正文段落大约经過多少层；一個頁面里可交互元素和容器是不是遠超實际需要。
常见来源是组件层层包裹、表格布局嵌套，以及為了样式而生成的空标簽。减少無意义的包装层，一般不會影响视觉，但能让结构更清晰。
正文是否出現在原始 HTML 里
如果正文完全依赖脚本在浏览器端填充，而原始 HTML 只是一個空壳加大量资源引用，那么引擎需要走渲染流程才能拿到内容，這一步的成本遠高于直接讀取 HTML。即使最终能讀到，處理優先級也可能低于结构清晰的頁面。
可行的做法是：把标题、正文主体、關键連結放在服務端輸出的 HTML 中，把交互和增强效果交给脚本處理。這样即使渲染环节出問题，頁面主体信息也不會一起丢失。
一個可执行的自查顺序
- 用抓取工具或浏览器查看源代碼，確認原始 HTML 的大小和主要内容。
- 確認标题、正文首段和主要連結是否在原始 HTML 中直接可见。
- 統計内联脚本與样式的占比，判断是否存在明顯重复。
- 检查 DOM 深度與节点總數，找出無意义的嵌套容器。
- 對照服務器日誌，看這些頁面的响應体大小和抓取耗时是否異常。
- 精简模板後持續观察抓取频次、抓取成功率和索引狀態的變化，不要只看一两天。
什么情况下不用折腾
站点頁面數量不多、模板统一、日誌里抓取正常、索引狀態也没有大面积異常时，為几百 KB 的体积差异做大改版並不划算。体积和结构属于基础條件，把它理顺能让抓取更顺，但替代不了内容本身的價值。
把頁面做轻一点、结构做清楚一点，是成本不高也不容易出错的方向；至于最终是否收錄、收錄多少，仍取决于内容质量、整体站点狀態和引擎自己的判断。