快速答案：先保留页面级证据
JavaScript 渲染 SEO 技术诊断要同时读取原始 HTML 和渲染后的 DOM。只有确认重要正文、链接、canonical、schema 和交互模块在渲染后仍可见，才算完成页面级判断。
基础事实：先看这些字段
| 检查对象 | 源代码、渲染 DOM、正文、链接、canonical、schema、图片和关键交互模块。 |
|---|---|
| 第一证据 | 普通 URL、cache-bust、桌面端、移动端和抓取样本。 |
| 常见风险 | 正文只在客户端插入、链接不可抓取、schema 可见、首屏依赖慢脚本。 |
| 修复边界 | 优先保证重要内容服务端可读，再处理延迟加载和交互细节。 |
| 验收方式 | 对比源代码和渲染结果，并确认移动端无横向溢出。 |
先分清源代码和渲染结果
源代码说明服务器最初返回了什么，渲染 DOM 说明浏览器执行脚本后用户和搜索引擎可能看到什么。
如果重要正文只存在于渲染 DOM，页面仍可能被理解，但稳定性低于服务端直接输出。关键服务页和文章页应尽量让核心内容在初始 HTML 中可读。
检查链接、结构化数据和移动端
JavaScript 渲染问题不只影响正文，也可能影响内部链接、面包屑、FAQ schema、图片和按钮。
要确认链接是正常 a 标签，schema 留在 script 中，移动端没有横向溢出，也没有把 CSS 或 JSON-LD 显示成正文。
用样本页控制修复范围
先选一个服务页、一个文章页和一个工具页做样本，对比普通 URL 与 cache-bust 的内容是否一致。
如果样本问题来自同一模板，再扩展修复；如果只是单页正文写入异常，就不要改全站主题。
参考要点：发布前后怎么验收
修复或发布后，先验收公开页面本身：HTTP 状态、canonical、robots、标题、正文、图片、FAQ JSON-LD、内部链接和移动端阅读效果。
如果普通 URL 与 cache-bust URL 看到的内容不同，优先定位缓存层；如果两者一致但内容结构仍差，再回到正文、模板或脚本层处理。
这类技术文章的结论应保持证据边界，不承诺收录、排名、流量或询盘结果。
延伸阅读
常见问题
这类技术诊断能直接保证排名恢复吗？
不能。诊断和修复只能证明页面条件、抓取条件或渲染条件被改善，最终收录、排名和流量仍由搜索引擎综合判断。
为什么要同时看普通 URL 和 cache-bust URL？
普通 URL 可能命中缓存，cache-bust 更容易看到新鲜结果。两者一致时，才更适合判断前台修复是否已经公开生效。
发现一个页面异常就要改全站模板吗？
不一定。先判断异常是否来自单篇正文、缓存、插件、模板还是服务器层。只有样本证明是共同组件问题时，才考虑模板级修复。
修复后应该保留哪些记录？
至少保留修复前页面、修复动作、负责人、上线时间、普通 URL 复验、cache-bust 复验、canonical/index 状态和下一次观察窗口。
