很多人排查收录问题，习惯从链接和 sitemap 入手，却容易忽略更基础的一件事：搜索引擎得先把页面完整拿下来、读懂它。页面体积过大、DOM 层级过深、内联资源过多，都会让这一步变慢，抓取频次和后续的索引处理也会跟着受影响。
抓取一个页面，引擎要付出什么成本
每次抓取都是一次资源投入：发起请求、接收响应、解析 HTML、执行渲染、提取正文和链接。在总预算相对固定的情况下，能抓多少页面，取决于每个页面有多“重”。同样一批 URL，如果单页响应体普遍是数百 KB，抓取调度占用的时间和带宽就会明显更多。
收录问题有时不是“要不要收录”，而是“能不能顺畅读到”。
HTML 体积：先看有没有异常，而不是追一个数字
没有适用于所有搜索引擎的公开硬阈值，所以不建议拿某个数字当红线。更实用的判断方式是对比：同一站点内，同类模板的页面 HTML 大小是否接近；某个页面是否比同类页面大出数倍甚至十几倍。
- 整段样式表或脚本被内联进每个页面，重复体积随页面数量放大。
- 图片、字体以 base64 形式写进 HTML，体积膨胀且无法单独缓存。
- 列表页一次性输出几百上千条数据，或者把大量隐藏内容塞进头部区块。
- 模板注释、调试信息、未使用的组件代码被一起打包输出。
如果命中了其中几条，先把模板精简一遍，通常比反复提交 URL 更有意义。
DOM 层级与节点数量
HTML 大，往往 DOM 也深。过深的嵌套会增加解析和渲染耗时，正文与链接的提取也更容易被噪声干扰。自查时可以看两点：从根节点到正文段落大约经过多少层；一个页面里可交互元素和容器是不是远超实际需要。
常见来源是组件层层包裹、表格布局嵌套，以及为了样式而生成的空标签。减少无意义的包装层，一般不会影响视觉，但能让结构更清晰。
正文是否出现在原始 HTML 里
如果正文完全依赖脚本在浏览器端填充，而原始 HTML 只是一个空壳加大量资源引用，那么引擎需要走渲染流程才能拿到内容，这一步的成本远高于直接读取 HTML。即使最终能读到，处理优先级也可能低于结构清晰的页面。
可行的做法是：把标题、正文主体、关键链接放在服务端输出的 HTML 中，把交互和增强效果交给脚本处理。这样即使渲染环节出问题，页面主体信息也不会一起丢失。
一个可执行的自查顺序
- 用抓取工具或浏览器查看源代码，确认原始 HTML 的大小和主要内容。
- 确认标题、正文首段和主要链接是否在原始 HTML 中直接可见。
- 统计内联脚本与样式的占比，判断是否存在明显重复。
- 检查 DOM 深度与节点总数，找出无意义的嵌套容器。
- 对照服务器日志，看这些页面的响应体大小和抓取耗时是否异常。
- 精简模板后持续观察抓取频次、抓取成功率和索引状态的变化，不要只看一两天。
什么情况下不用折腾
站点页面数量不多、模板统一、日志里抓取正常、索引状态也没有大面积异常时，为几百 KB 的体积差异做大改版并不划算。体积和结构属于基础条件，把它理顺能让抓取更顺，但替代不了内容本身的价值。
把页面做轻一点、结构做清楚一点，是成本不高也不容易出错的方向；至于最终是否收录、收录多少，仍取决于内容质量、整体站点状态和引擎自己的判断。