用浏览器打开页面，正文、图片、评论都正常显示，但在“查看网页源代码”或抓取工具返回的响应里，正文区域却是空的。这种页面往往不是内容质量问题，而是渲染方式的问题：搜索引擎第一次拿到的是服务端返回的 HTML，里面没有内容，后面能不能补上，取决于它是否愿意再花资源执行页面脚本。
先分清你看到的是哪一份页面
日常在浏览器里看到的，是脚本执行完之后的 DOM；而爬虫首先拿到的是服务器返回的原始 HTML。两者经常不是一回事。核对时可以用几种简单方式对比：
- 在浏览器里右键“查看网页源代码”，搜索正文中的关键词，看是否出现；
- 用抓取工具或命令行请求该 URL，看响应内容里有没有正文和链接；
- 在浏览器设置中关闭 JavaScript 再刷新页面，观察还剩下什么。
如果关闭脚本后页面几乎只剩框架和占位符，说明核心内容依赖渲染。这时再讨论收录，就不是内容差异度的问题，而是内容有没有被拿到的问题。
渲染能力有差别，不要默认所有引擎都会执行脚本
主流搜索引擎具备一定的渲染能力，但渲染通常要排队，消耗的资源也比直接读取 HTML 高。对抓取预算有限的站点来说，依赖渲染的页面在处理顺序上往往更靠后，延迟也更明显。不同引擎对脚本的支持程度并不一致，把关键内容完全交给前端，等于把不确定性留在了收录链路的第一环。
常见的“内容藏在渲染之后”的情况
- 正文由接口异步返回，初始 HTML 只有骨架；
- 内容默认折叠，需要点击“展开更多”才显示；
- 列表采用无限滚动，首屏之后的数据靠后续请求加载；
- 选项卡切换的内容，未选中的部分不在初始 HTML 中；
- 图片使用 data-src 懒加载，初始 HTML 里没有真实图片地址。
这些做法对用户体验未必是坏事，但要判断其中哪些内容是你希望被搜到的，哪些只是辅助展示。希望被搜到的部分，最好在初始响应里就能看到。
链接发现同样受影响
内容之外，入口也常被忽略。如果站内跳转用的是 onclick 事件、button 元素或前端路由，而不是可点击的 a 标签，爬虫在初始 HTML 里就找不到目标地址。列表页、分页、相关推荐如果全部由前端渲染，深层页面缺少可跟随的链接，发现速度会明显变慢。检查时可以在关闭脚本的情况下走一遍站内导航，看还能不能顺着链接到达重点页面。
可以按这个顺序核对和调整
- 先确认初始 HTML 里有什么：正文、标题、内链、canonical 是否齐全；
- 把最需要被收录的正文改为服务端输出，或做预渲染；
- 站内跳转恢复成标准的 a 标签链接，避免只靠脚本跳转；
- 列表和分页提供可抓取的链接入口，不依赖首次请求之外的加载；
- 首屏之外的内容如果重要，考虑改为服务端分页或独立 URL；
- 改完后对照服务器日志，看爬虫拿到的响应是否包含正文，再观察收录变化。
不必全站推倒重来
全站改成服务端渲染成本不低，也没有必要。可以先按页面价值排序：承担搜索流量的详情页、栏目页优先处理，交互性强、本就不指望被搜到的功能页保持现状即可。判断标准很简单——这个页面希望被搜到吗？如果希望，就在初始 HTML 里给它一份完整内容。
收录问题的排查顺序，通常是先看爬虫拿到了什么，再看它是否选择收录。渲染方式影响的是前者，而这往往是后面所有环节的前提。
最后提醒一点：渲染方式的调整不会立刻带来收录变化，索引更新有自身节奏。把响应 HTML 里的内容补齐、把链接入口理顺，剩下的交给时间和持续的日志观察。