站点用了前端框架之后，最容易出现的一种情况是：人工在浏览器里点开页面，内容完整、排版正常；但用抓取工具或直接拉取 HTML 时，返回的却是一个空壳，正文要等脚本跑完才出现。蜘蛛是否执行脚本、执行到什么程度，不同抓取方做法不一样，也随时可能调整，把内容能不能被看到完全押在这一点上并不稳妥。所以这类自查的目的不是追求某个技巧，而是确认一件事：没有脚本时，页面还剩什么。
先分清「看得到」和「抓得到」
浏览器里的「审查元素」面板显示的是脚本执行后的 DOM，而「查看网页源代码」显示的是服务器最初返回的 HTML。两者差别越大，说明内容越依赖客户端渲染。做自查时要以源码和抓取工具的视角为准，而不是以自己屏幕上的效果为准。
可以照着做的几项检查
1. 对同一批 URL 做两种方式的取回
挑首页、栏目页、几篇正文页、一个列表分页，分别用「查看源代码」和渲染后的方式各取一份，对比正文文字量、内链数量、标题是否出现。差异明显的页面，就是需要优先处理的页面。
2. 关掉 JavaScript 再打开页面
在浏览器里禁用脚本后刷新，如果页面只剩导航和一片空白，说明正文、相关阅读、评论等内容全部由脚本注入。这不一定是错误，但要有意识地确认哪些内容属于「希望被抓到」的部分。
3. 核查关键元素是否在初始 HTML 里
- 页面标题、H1、面包屑
- 正文主体段落，尤其是首屏之后的内容
- 指向其他内容页的站内链接，而不是点击后才由脚本拼出来的地址
- 图片的真实地址与 alt 文本
- canonical、hreflang 等头部信息
- 结构化数据所在的脚本块
4. 注意分页与无限滚动
无限滚动在体验上顺畅，但如果没有可抓取的静态分页地址，列表深处的条目可能一直缺少入口。比较稳妥的做法是给滚动列表补一份带页码的静态链接，或者提供一个「查看全部」的列表页。
5. 对比响应体大小和首屏内容
同一条 URL，服务器返回的 HTML 只有几百字节、渲染后却是几十 KB，说明内容基本靠脚本。返回体里正文占比越低，越值得考虑服务端渲染或预渲染处理。
几类常见问题
- 正文放在选项卡、折叠面板、懒加载模块里，用户不点击就不出现。
- 内容通过接口异步拉取，接口一旦限流或报错，页面就是空的。
- 关键链接用按钮加事件绑定实现，源码里只有无意义的占位标签。
- 不同模板渲染方式不一致，改版只改了其中一部分页面。
处理思路
- 先列出「希望被抓到」的内容清单，不要全站一起动。
- 优先级最高的页面改服务端渲染，让正文直接出现在初始 HTML 中。
- 暂时无法改动架构的，可以考虑预渲染方案，并确保渲染结果与用户看到的一致。
- 保留一套不依赖脚本的降级入口，比如静态分页、站点地图中的正文链接。
- 改完之后用同一批 URL 复测，对比修改前后的差异。
记录与复查节奏
把抽查的日期、URL、源码中的正文长度简单记下来，下次改版或换模板时就能快速判断有没有退化。建议在每次模板调整、接口改造、上线新栏目之后各抽查一次，而不是等到数据出现异常才回头找原因。
渲染方式属于技术细节，调整后的效果不会立刻反映在数据上。把「关闭脚本后页面还剩什么」当成一条固定检查项，定期抽查，通常比一次性大改更实际。
最后提醒一句：结论尽量以多种方式对照为准，单一工具的渲染结果只能作为参考。自查的价值在于把不确定的地方变成可确认的事实，而不是找到一套一劳永逸的写法。