现在用前端框架搭站的团队不少，页面首屏靠 JavaScript 拉数据再渲染。用户用浏览器打开，脚本跑完，看到的是一张完整页面；抓取端虽然大多也能执行一部分脚本，但执行时间、渲染资源、接口响应都可能受限。于是就出现了那种不好定位的情况：你自己点开一切正常，抓取端拿到的却接近空壳。这类问题通常不报错，只能靠主动比对发现。
先确认抓取端看到的是哪一版
不建议一上来就全站扫描，先挑一批有代表性的地址做人工比对，效率更高也更接近真实情况。选样时可以覆盖：首页、主要栏目页、内容详情页、列表或聚合页，以及你近期最希望被发现的几个新页面。
具体做法很朴素：在浏览器里查看网页源代码，看看里面有没有正文文字、标题、主要内链；再打开开发者工具看渲染后的 DOM，把两者对照。如果源码里几乎是空的容器加一串脚本，而渲染后才出现内容，那么这类页面就有必要进一步确认抓取端的表现。
容易出问题的地方
- 正文完全依赖接口返回后再插入，脚本一旦失败页面上就没有文字。
- 标题、H1、面包屑、正文内链由脚本拼接，源码里看不到。
- 列表页只有“加载更多”，没有可单独访问的分页地址。
- 懒加载图片缺少占位尺寸与替代文字，渲染时机又滞后。
- 关键数据接口被规则文件或防火墙拦住，抓取端请求不到 JSON。
- 渲染依赖第三方 CDN，脚本加载超时或域名被拦截。
- 不同用户代理返回不同内容，服务端做了 UA 判断但没有给默认版本。
一次可执行的自查流程
- 列抽样清单：从每个主要模板里挑两到三个 URL，固定下来，后面复用。
- 看源码：在关闭脚本或直接查看源码的状态下，确认页面里有没有正文与内链。
- 对比渲染结果：记录差异，判断是“缺失”还是“延迟出现”。
- 检查接口可达性：确认数据接口没有被规则文件屏蔽，也不依赖登录态或特殊请求头。
- 确认兜底：核心页面是否可以通过服务端渲染、预渲染或静态输出，让内容直接出现在 HTML 里。
- 回归验证：调整后重新跑一遍同一份清单，比较前后差异，并留下记录。
兜底方案不必一步到位
如果整站改造周期长，可以先从收益最高的部分入手：把详情页与栏目页的正文、标题、主要内链输出到服务端；把分页做成真实可访问的地址，而不是只保留一个按钮；给不支持脚本的场景留一个可读的默认版本。这些改动通常不需要推翻现有架构，却能让更多内容直接出现在初始 HTML 中。
同时也要留意，不要为了讨好抓取端而给不同来源返回两套差别很大的内容。服务端与前端渲染的应当是同一份信息，只是呈现路径不同，避免人为制造不一致。
把渲染检查放进日常巡检
渲染相关问题往往出现在变更之后：换了模板、改了接口协议、调整了缓存策略、替换了 CDN。与其等发现问题再回头排查，不如把抽样清单挂在固定位置，在下列节点各跑一遍：新模板上线前、接口版本变更后、缓存或 CDN 配置调整后、以及每季度一次的常规复查。
渲染问题很少直接报错，它的表现通常是抓取端比用户少看到一部分内容。靠定期比对同一批地址，比凭感觉判断更可靠。
对以内容为主的站点来说，页面能被完整读取，是后续一切工作的前提。先把这件事做扎实，再去谈栏目规划与更新节奏，会顺畅得多。