不少站点的页面在浏览器里看着完整，但把 JavaScript 关掉，或者直接看服务端返回的 HTML 源码，正文区域却是空的。对访客来说，只要脚本能跑起来，问题不明显；对搜索蜘蛛来说，拿到的可能就是一个几乎没内容的空壳。这类问题通常在改版、换前端框架或上线新模板之后出现，而且很难在日常浏览中顺手发现。
先判断：蜘蛛到底拿到了什么
自查的第一步不是改代码，而是确认现状。几个成本很低的方法：
- 在浏览器里打开目标页，按 Ctrl+U 查看网页源代码，搜索正文里的关键词，看是否出现在源码中。
- 临时禁用 JavaScript 再刷新页面，观察主体内容、主要导航链接、分页入口是否还在。
- 用抓取工具或 curl 请求页面，对比返回的 HTML 与渲染后的页面结构差异。
- 对同一模板下的多个栏目各抽一两个页面，避免只测首页就得出“没问题”的结论。
如果源码里只有前端框架的挂载容器，正文、标题、列表项都要等脚本执行后才出现，那就要继续往下排查。
常见的几类陷阱
懒加载把正文也一起懒了
图片懒加载本身没问题，但有些实现把正文段落、表格、评论也纳入懒加载，需要滚动到可视区域才插入页面。蜘蛛通常不会滚动，于是只能看到首屏之外的空内容。
无限滚动没有可抓取的入口
列表页用无限滚动加载，用户往下滑很顺畅，但传统分页链接被去掉之后，后面的内容就没有稳定的 URL 可供发现，越靠后的条目越难被访问到。
链接由脚本拼接生成
导航或文章列表里的 href 是脚本执行后写入的，源码里只有按钮或空标签。顺着源码找链接时，就会走进死路。
标题与描述由前端动态写入
title、description、canonical 如果靠脚本运行时改写，不同的抓取方式可能拿到不一样的结果。这类信息尽量让服务端直接输出。
处理思路
- 优先服务端渲染或静态化：让首屏的正文、标题、主要链接出现在初始 HTML 里，脚本只做交互增强。
- 预渲染作为过渡：改造周期较长时，可对重点栏目做预渲染，但要留意缓存的更新频率与内容新鲜度。
- 渐进增强：把内容放在 HTML 里，用脚本加交互，而不是把内容藏在脚本里。
- 保留可抓取的分页或归档入口：无限滚动之外，补一套带独立 URL 的分页页或按标签归档的列表页。
- 懒加载加兜底：图片懒加载要保留替代内容或首屏直出，正文区域不要懒加载。
- 元信息服务端输出：title、description、canonical 以及结构化数据，尽量在服务端确定下来。
把它变成固定巡检项
前端框架升级、模板改版、CDN 更换、构建配置调整，都可能重新引入这个问题。建议在模板或主题上线前，固定检查几个代表性的页面类型：首页、栏目页、详情页、搜索结果页。检查结果记到改动记录里，下次改版时能直接对照，不用从零摸索。
判断标准其实很简单：如果一个页面的核心内容必须等脚本跑完才出现，就要评估它在各种抓取环境下的可见性，而不是只看自己浏览器里的效果。
还要提醒一点，服务端渲染也不是万能的。渲染超时、接口报错、缓存穿透时，返回给蜘蛛的仍可能是残缺页面。把这几种异常情况也纳入监控，比单纯依赖某一种渲染方案更稳妥。