复盘
核心更新后流量下降：撰写复盘报告
每天早上 8 点大家都会问同一个问题：是 Google 的问题，还是我们自己的问题，或者是追踪出了问题？复盘按此顺序逐一排查，拒绝盲目猜测。
从时间线开始，而非理论
流量下降有一个起始日期。在查阅任何关于核心更新后流量下降的论坛帖子之前，先找到它。
Google 确认在 2024 年 3 月、2024 年 8 月、2024 年 12 月、2025 年 3 月和 2025 年 6 月进行了核心更新，每次更新持续约两周。因此，在更新 rollout 的第三天出现的流量下降可能尚未反映最终情况。将您的变更日志叠加在这些日期上：发布、迁移、模板编辑、robots.txt 更改。
如果您的网站没有任何变动，且 Search Console 图表在更新窗口期内出现波动，这是一个嫌疑对象。如果您的部署恰好发生在前一天，那么嫌疑更大。无论哪种情况，核心更新周的流量下降都值得用书面时间线记录下来。写下来。
按排除速度排序的原因
| 嫌疑对象 | 检查方法 | 排除所需时间 |
|---|---|---|
| 追踪出错 | 对比 GA4 和 Search Console 中相同页面的点击量；一夜之间出现的差距是主要迹象 | 10 分钟 |
| 索引或站点地图 | Search Console 页面索引报告，以及对下降 URL 的 site: 抽查 | 20 分钟 |
| 技术发布 | 将 robots.txt、canonical 标签、状态码和重定向与上周的抓取结果进行对比 | 1 小时 |
| 链接丢失或新增 | 对比两个 refdomains 快照；查看 丢失的链接 | 30 分钟 |
| 关键词内耗 | 在性能报告中，您的两个 URL 针对同一查询的排名发生互换 | 1 小时 |
| SERP 变动 | 查看实时结果：AI 摘要、论坛帖子、您曾占据位置的大型品牌列表文章 | 30 分钟 |
| 质量重新评估 | 排除其他所有明确因素后剩下的内容 | 数天至数周 |
链接证据：一项对比
提取两个日期下该掉链网站的引荐域名，并打印出保留和新增的部分。索引刷新大约每月一次，因此请选择更新前后的快照进行对比。
import json
old = {r['domain'] for r in json.load(open('2026-09-01.json'))['rows']}
new = {r['domain'] for r in json.load(open('2026-10-01.json'))['rows']}
print('lost :', len(old - new))
print('gained:', len(new - old))
print('sample lost:', sorted(old - new)[:20])
# Field names ('rows', 'domain') vary by action: print one response first.
示例报告（假设数据）
这是一个虚构示例，并非真实客户。它展示了我们力求达到的语调。
影响。 一家拥有 140 个页面的虚构食谱网站在九天内有机点击量下降 38%。检测。 每周的 Search Console 导出数据触发了 25% 的周环比预警。原因。 引荐域名从 410 个减少到 402 个，这排除了链接作为主要驱动因素。两个页面针对同一查询发生排名互换，属于关键词内耗。
行动项。 使用 301 重定向合并这两个页面，更新内部链接，四周后重新检查。无需提交 Disavow 文件，也无需重写整个网站。
看似更新但实为测量和索引故障的问题
部分流量下降并非排名问题。追踪工具是常见嫌疑对象。标签损坏、属性变更或站点地图缩减，在图表中看起来与核心更新完全一致。核心更新时间点后出现的流量下降可能掩盖了上述任何情况，因此请优先检查这些方面。
最快的测试方法是将您的分析数据与 Search Console 中相同页面和日期的数据进行对比。如果差距在 overnight 出现，请将其视为测量故障，除非有证据证明否则。
索引故障遵循相同的逻辑。从索引中消失的页面与保留在索引中但排名下滑的页面属于不同的问题。
如果点击量在一夜之间降至零怎么办？
首先检查 Search Console 属性。协议变更、新属性或验证丢失可能导致数据分裂，因此旧属性显示无数据，而新属性包含流量。只有在排除这种情况后，再查看页面本身。
为什么页面会在更新后停止被索引？
提取相关 URL 的索引报告。页面在保持索引的情况下排名下滑是一回事。从索引中消失的页面原因不同，通常是由于 robots 指令、canonical 变更或发布时包含的 noindex 标签。
损坏的站点地图会导致流量下降吗？
有可能。如果站点地图突然只列出了您极少部分的 URL，便会出现这种情况。修复简短的站点地图成本很低，但 Google 仍会通过内部链接发现页面，因此应将其视为多个嫌疑因素之一，而非最终定论。请将 URL 数量与您实际的页面数量进行对比。
我们的立场
第一周不要重写站点
核心更新会在数周内重新评估质量。修正那些你能证明已出问题的地方，然后在更新发布完成之前不要改动内容。
- 立即修复测量和技术故障。
- 在拥有确凿证据后，再合并产生竞争的内容页面。
- 在更新发布结束之前，不要调整内容策略。
文档中应写什么
六个标题就足够了：影响、时间线、检测、原因、排除项、行动项。排除项列表是未来的你会感谢你的部分。
将证据与声明并列。像“排除链接，402 与 410 个引荐域名”这样的行，比“链接看起来没问题”更能经受住怀疑型管理者的审视。
更新发布开始后的第一周
- 1
冻结内容编辑
在更新发布运行期间不要重写页面。在此期间进行的编辑会模糊你稍后需要的“前后对比”画面。
- 2
记录每次发布
记下每次部署、模板更改、重定向和 robots.txt 编辑及其日期，以便时间线包含真实条目，而非记忆。
- 3
运行测量检查
将分析数据与 Search Console 进行对比，然后检查索引报告中丢失的 URL。这两项检查可在半小时内完成。
- 4
以时间线开启案例
即使原因仍未确定，也要从你拥有的日期开始进行事后分析。部分完成的文档比空文档更容易完成。
- 5
设定审查日期
选择一个在更新发布结束后的日期进行审查，而不是在图表出现波动的那一天。
向管理层证明问题是技术性的
管理层通常将流量下降视为内容问题的判决。这是一种合理的反应，但当故障是模板损坏或标签缺失时，这也是最浪费数周的reaction。
带上时间线和原因表，而不是理论。一张可以逐一排除嫌疑因素的时间表，能让管理者看到团队正在按清单工作，而非盲目猜测。
诚实地说明表格无法证明的内容。如果质量重新评估仍在进行中，请说明这一点，并说明什么会改变你的看法。
我如何证明这是开发问题而不是内容问题？
指出一个与下降开始时间吻合的有日期标记的更改，例如模板发布或 robots 更改。一个你可以复现的故障，附带 URL 和发生变化的标头，比任何平均值的图表都更有说服力。
如果根本不是技术问题，我该怎么说？
说明链接、索引和跟踪检查均无异常，剩下的嫌疑因素是质量重新评估。这个答案来得较慢且不那么令人满意，但它是准确的，并告诉团队内容工作应集中在何处。
记录恢复过程，而不仅仅是下降
当流量恢复时，事后分析并未完成。写作的第二部分记录了什么发生了变化、何时发生变化，以及你彻底排除了哪些嫌疑因素。
在下一次核心更新完成后重新审视文档。跨多次发布重复出现的模式比单次下降更能揭示你站点的状况。
将排除项列表与原因分开。未来的读者会首先询问排除了什么，如果缺少列表，他们会回到起点。
什么算作恢复？
在查看之前定义它。恢复到旧的点击水平是一种定义，恢复最重要的页面是另一种定义。选择一种，写下来并据此报告，而不是在图表移动时改变标准。
审查应该等待多久？
等待更新发布关闭并显示两个正常周的数据。恢复通常来得很慢，因此早期审查主要发现的是噪音，而较晚的审查才有机会找到答案。
每次更新后我们听到的问题
我能从核心更新下降中恢复吗？
通常是部分恢复，很少是 overnight。恢复通常需要后续更新来重新评估站点，因此请预期需要数月而非数天。没有人能承诺这一点。你能做的是消除真实故障并保持发布值得引用的页面。
为什么排名保持而流量下降？
结果页面围绕你发生了变化。AI 概览、论坛帖子和购物区块可以将相同的位置在屏幕上推得更低。比较相同查询在前后阶段的点击率，而不仅仅是平均排名。
丢失的外链会导致更新后的排名下降吗？
有时是，但 Rankift 无法告诉你哪个更新导致了什么。足以产生影响的链接丢失会在两个快照之间显示为引荐域名的明显下降。少量百分之几的波动很少能解释 30% 的流量下降。
我应该等待多久再采取行动？
直到 Google 在其状态仪表板上标记更新发布完成，除非你发现明确的技术故障。立即修复故障，但保持内容不变。在更新发布期间编辑会模糊你稍后需要的证据。
