快速答案：先保留页面级证据
Core Web Vitals 页面体验诊断不能只看一次分数。先按页面组核对 LCP、INP、CLS、设备、模板、资源请求和渲染结果，再判断是内容、图片、脚本、缓存还是服务器响应导致体验下降。
基础事实：先看这些字段
| 主要指标 | LCP 关注主要内容加载，INP 关注交互响应，CLS 关注布局稳定。 |
|---|---|
| 第一证据 | 保存页面组、设备、时间范围、请求样本、渲染截图和核心资源。 |
| 常见原因 | 图片过大、字体阻塞、第三方脚本、首屏模块复杂、缓存策略不稳定。 |
| 修复边界 | 先做可回退的小改动，再比较普通 URL 与 cache-bust 结果。 |
| 结果边界 | 体验指标改善不等于排名承诺，只能证明被测页面条件改善。 |
先按页面组判断影响范围
把同一模板、同一栏目或同一业务路径的 URL 放在一起看，避免用单页分数代表全站问题。
如果只有图片型文章异常，优先看图片尺寸和懒加载；如果多个模板页都异常，再检查公共脚本、字体和缓存策略。
分开看 LCP、INP 和 CLS
LCP 异常通常与首屏图片、服务器响应、阻塞资源和渲染路径有关。INP 异常更常见于脚本执行、事件处理和第三方组件。
CLS 异常要查看图片宽高、广告位、字体替换和动态插入模块。三个指标原因不同，不能用一个优化动作解决所有问题。
保留上线前后的复验证据
修复前后都要记录普通 URL、cache-bust URL、桌面端、移动端和核心页面组。没有对照证据时，不要把一次分数变化当作稳定结论。
如果缓存版本与新鲜版本不同，先处理缓存层；如果两者一致但指标仍差，再回到模板、资源和服务器响应排查。
参考要点：发布前后怎么验收
修复或发布后，先验收公开页面本身：HTTP 状态、canonical、robots、标题、正文、图片、FAQ JSON-LD、内部链接和移动端阅读效果。
如果普通 URL 与 cache-bust URL 看到的内容不同，优先定位缓存层；如果两者一致但内容结构仍差，再回到正文、模板或脚本层处理。
这类技术文章的结论应保持证据边界，不承诺收录、排名、流量或询盘结果。
延伸阅读
常见问题
这类技术诊断能直接保证排名恢复吗？
不能。诊断和修复只能证明页面条件、抓取条件或渲染条件被改善，最终收录、排名和流量仍由搜索引擎综合判断。
为什么要同时看普通 URL 和 cache-bust URL？
普通 URL 可能命中缓存，cache-bust 更容易看到新鲜结果。两者一致时，才更适合判断前台修复是否已经公开生效。
发现一个页面异常就要改全站模板吗？
不一定。先判断异常是否来自单篇正文、缓存、插件、模板还是服务器层。只有样本证明是共同组件问题时，才考虑模板级修复。
修复后应该保留哪些记录？
至少保留修复前页面、修复动作、负责人、上线时间、普通 URL 复验、cache-bust 复验、canonical/index 状态和下一次观察窗口。
