做收录排查时，很多人只盯着状态码和站点地图，却忽略了一个更靠前的问题：搜索引擎抓到页面之后，能不能分清哪一块是正文。如果它判定页面主体内容不足，或者干脆把模板当成了主体，收录和后续展现都会受到影响。
搜索引擎怎么判断哪部分是正文
抓取工具拿到的是一份 HTML，渲染后得到一棵 DOM 树。系统需要从这棵树里剥离导航、页脚、侧栏、推荐位、弹窗，找出真正的正文区域。常见的判断依据有几类：
- 语义结构：main、article、h1 以及连续的段落标签，通常会被优先考虑。
- 文本密度：某个区域内有效文字与标签数量的比例越高，越像正文。
- 位置与稳定性：出现在页面中段、且在多数页面中不重复的区块，更容易被当作正文。
- 跨页对比：在站点大量页面上都出现的文本块，会被归为模板。
这些只是启发式规则，并不是公开标准。但它们能解释一个常见现象：同样的文字，放在不同结构里，被当成正文的概率并不一样。
模板占比过高会带来什么
如果页面源码里导航、菜单、友情链接、推荐列表、免责声明加起来比正文还长，可能出现几种结果：
- 正文被稀释，系统提取到的有效内容很少，页面被视为内容不足。
- 不同页面提取出来的“主体”高度相似，因为它们共享了大量模板文本，于是被归入重复内容。
- 正文区域被识别错误，索引里保留的可能是一段推荐语或一段导航文字。
这不必然意味着页面会被剔除，但会让它在收录与展现上处于劣势。先修结构，再谈提交和推送，顺序更合理。
正文提取常见的几个坑
正文依赖交互才出现
如果正文要靠点击“展开全文”或滚动加载才渲染，而未渲染前的 HTML 里几乎为空，抓取端可能看不到任何内容。渲染能力是有限的，能直接拿到的文字，尽量直接放在 HTML 里。
正文由 JS 在客户端拼接
纯前端渲染又没有服务端输出时，首屏 HTML 往往只有骨架。需要评估渲染成本与收益，至少保证关键内容在 HTML 源码中可见。
正文被拆散在多个区块
段落之间插入大量广告位、卡片、推荐模块，会让正文被切碎。提取时每一小段都被当作独立区块，整体长度明显不足。
正文塞进不合适的容器
把正文放在嵌套极深的 div 里，或用表格布局拼接，会让文本密度判断失真。语义化标签不仅对无障碍友好，对内容识别也有帮助。
一个可操作的自检流程
- 用“查看网页源代码”（不是查看元素）打开页面，确认正文文字是否直接出现在 HTML 里。
- 关闭 JS 再看一次，确认正文有没有整体消失。
- 粗略估一下正文文字与全页文字的占比，模板明显超过正文时值得优化。
- 抽取几个页面，比对它们重复出现的文本块，那些基本就是模板。
- 检查标题、h1 与正文主题是否一致，不一致时系统更难判断主体。
调整思路
方向上无非两件事：让正文更突出，让模板更收敛。
- 用 main 或 article 包裹正文，正文内部保持清晰的 h2、h3 与段落层级。
- 把导航、推荐、页脚等重复块与正文在结构上分开。
- 正文优先服务端输出，交互只做增强。
- 减少正文中间插入的干扰模块，或把它们移到正文之后。
- 多个页面共享的说明文字、免责声明，尽量收敛长度。
这些改动不保证收录速度立刻变化，它们影响的是页面被理解和被评估的基础条件。基础理顺之后，再去处理提交、内链与索引状态，排查链路会短很多。