GSC Core Web Vitals 报告使用：按 URL 分组定位问题

引言：报告里一堆红，先修哪页

GSC 的”体验 → 核心网页指标”会告诉你全站有多少 URL 达标、多少不达标，但不点进去就不知道该修哪页。正确用法是按分组下钻到具体 URL。

原理分析：报告的数据结构

报告按”来源/分组（如 AMP、非 AMP）”和”设备（移动/桌面）”两个维度聚合。每个不良 URL 都标注了主犯指标（LCP/INP/CLS）和具体数值。数据同样来自 CrUX，有 28 天延迟，且只显示有足够样本量的 URL。

保姆级实操

第一步，进 GSC → 体验 → 核心网页指标，顶部切换”移动”和”桌面”，看达标率差多少（移动通常更低）。
第二步，点”需要改进的网址”或”不良网址”，进入按指标分组的列表。

# 用 Search Console API 导出全部不良 URL 做批量排查
curl -X POST "https://searchconsole.googleapis.com/v1/urlTestingTools/mobileFriendly:run?key=YOUR_KEY" \
  -H "Content-Type: application/json" -d '{"url":"https://mimangfei.com/sample-post/"}'
# 更实用的是在 GSC 界面直接导出 CSV

第三步，把列表导出 CSV，按”主要问题指标”排序，优先修 LCP 超标的模板级页面（如文章页、列表页共用同一个烂首图逻辑）。
第四步，修完对应 URL 后，报告会在下次抓取时更新状态。

常见踩坑

1. 只看总数不看设备，移动端问题被桌面达标掩盖。
2. 一个一个手测 URL，应该用分组批量定位同类模板问题。
3. 案例：某站 GSC 显示 1200 个不良 URL 全是 LCP 问题。导出后发现 90% 是文章页，共用同一个未优化的头图组件。修了该组件一次，整批 URL 在两周内转绿。
4. 等报告”实时”更新，它有 28 天延迟，别天天刷。
5. 忽略”无数据”的 URL，它们样本不足，用 PSI 单独补测。

总结

判断标准：先看设备维度达标率，再按”主要问题指标”批量定位同类模板 URL。行动清单：切换移动/桌面 → 进不良网址 → 导出 CSV 按指标排序 → 修共性模板 → 等抓取更新。配合LCP 优化的实操清单修具体指标。