做收錄排查时，很多人只盯着狀態碼和站点地图，却忽略了一個更靠前的問题：搜尋引擎抓到頁面之後，能不能分清哪一块是正文。如果它判定頁面主体内容不足，或者干脆把模板当成了主体，收錄和後續展現都會受到影响。
搜尋引擎怎么判断哪部分是正文
抓取工具拿到的是一份 HTML，渲染後得到一棵 DOM 树。系統需要從這棵树里剥离導航、頁脚、侧栏、推荐位、彈窗，找出真正的正文区域。常见的判断依據有几類：
- 语义结构：main、article、h1 以及连續的段落标簽，通常會被優先考虑。
- 文本密度：某個区域内有效文字與标簽數量的比例越高，越像正文。
- 位置與稳定性：出現在頁面中段、且在多數頁面中不重复的区块，更容易被当作正文。
- 跨頁對比：在站点大量頁面上都出現的文本块，會被归為模板。
這些只是啟發式規則，並不是公開标准。但它們能解释一個常见現象：同样的文字，放在不同结构里，被当成正文的概率並不一样。
模板占比過高會带来什么
如果頁面源碼里導航、菜單、友情連結、推荐列表、免责声明加起来比正文還長，可能出現几種结果：
- 正文被稀释，系統提取到的有效内容很少，頁面被视為内容不足。
- 不同頁面提取出来的“主体”高度相似，因為它們共享了大量模板文本，于是被归入重复内容。
- 正文区域被识別错誤，索引里保留的可能是一段推荐语或一段導航文字。
這不必然意味着頁面會被剔除，但會让它在收錄與展現上處于劣势。先修结构，再谈提交和推送，顺序更合理。
正文提取常见的几個坑
正文依赖交互才出現
如果正文要靠点击“展開全文”或滚動加载才渲染，而未渲染前的 HTML 里几乎為空，抓取端可能看不到任何内容。渲染能力是有限的，能直接拿到的文字，尽量直接放在 HTML 里。
正文由 JS 在客戶端拼接
纯前端渲染又没有服務端輸出时，首屏 HTML 往往只有骨架。需要评估渲染成本與收益，至少保證關键内容在 HTML 源碼中可见。
正文被拆散在多個区块
段落之間插入大量广告位、卡片、推荐模块，會让正文被切碎。提取时每一小段都被当作獨立区块，整体長度明顯不足。
正文塞進不合适的容器
把正文放在嵌套极深的 div 里，或用表格布局拼接，會让文本密度判断失真。语义化标簽不僅對無障碍友好，對内容识別也有帮助。
一個可操作的自检流程
- 用“查看網頁源代碼”（不是查看元素）打開頁面，確認正文文字是否直接出現在 HTML 里。
- 關閉 JS 再看一次，確認正文有没有整体消失。
- 粗略估一下正文文字與全頁文字的占比，模板明顯超過正文时值得優化。
- 抽取几個頁面，比對它們重复出現的文本块，那些基本就是模板。
- 检查标题、h1 與正文主题是否一致，不一致时系統更难判断主体。
調整思路
方向上無非两件事：让正文更突出，让模板更收敛。
- 用 main 或 article 包裹正文，正文内部保持清晰的 h2、h3 與段落层級。
- 把導航、推荐、頁脚等重复块與正文在结构上分開。
- 正文優先服務端輸出，交互只做增强。
- 减少正文中間插入的干扰模块，或把它們移到正文之後。
- 多個頁面共享的說明文字、免责声明，尽量收敛長度。
這些改動不保證收錄速度立刻變化，它們影响的是頁面被理解和被评估的基础條件。基础理顺之後，再去處理提交、内鏈與索引狀態，排查鏈路會短很多。