Google update postmortem for SEO winners and losers.

Update postmortem compares Search Console winners and losers around an official Google update window. It looks for repeated patterns while keeping migrations, releases, tracking changes, demand, and seasonality in the investigation. Timing alone does not prove that the update caused a change.

Run this report from the CLI, an MCP client, or application code. Every surface uses the same report definition and returns the same evidence. JSON is the source of truth; Markdown makes it readable without hiding dates, limits, warnings, or skipped work.

What this report helps you decide

What changed across this property during the update window, and what can the evidence support?

Property movement overlaps a confirmed update and needs a careful segment review.
Known launches, migrations, or tracking changes can be recorded as confounders.

Command facts

Report id: update-postmortem
Execution: Local process
Outputs: JSON and Markdown
Example parameters: site, days, recentDays, limit, includeBrand, knownConfounders, includeChangeLog
Agent discovery: seo reports describe update-postmortem --json
Interactive prompts: Human CLI commands only

When this report is not the right tool

These cases need a different report, more evidence, or a human decision. Do not force this report to answer a question its data cannot support.

You only need to check whether unusual traffic dates overlap a confirmed Google ranking update. Recommended report: Check traffic changes against Google updates. Run update correlation. It compares the anomaly window with official rollout dates and returns a timing classification without running the deeper winner, loser, page, and confounder analysis.
You need proof that the update caused a specific loss or that one proposed change will recover it. No automated report can prove either conclusion. Review unaffected comparison groups, intent and result-page changes, site releases, tracking, demand, seasonality, and representative pages. The postmortem can organise the evidence and identify patterns, but timing remains context rather than causation.

Data sources and inputs

Official Google ranking update dates. Defines the confirmed rollout window used for the analysis.
Search Console winner and loser evidence. Provides matched movement by page, query, device, country, and repeated template patterns.
Known site changes and optional page checks. Keeps launches, migrations, change-log entries, and representative live-page evidence visible as confounders.

What this report checks

Anchors matched comparisons to the confirmed update window and identifies supported winner and loser patterns.
Preserves supplied and observed confounders, page verification, source limits, and incomplete segments before suggesting action.

How it works

Anchors analysis to the confirmed window, compares supported segments, keeps coincident site changes visible, and returns limited investigation actions.

The JSON result keeps dates, thresholds, limits, skipped work, and source completeness beside the finding. Missing, partial, capped, filtered, and complete data remain different states.

Run the report from the CLI

Review winners and losers around a confirmed Google update. Agents and CI should inspect the live schema before their first run.

Run it from the CLI

seo update-postmortem --project example

Check the agent input schema

seo reports describe update-postmortem --json

Run it from an agent or script

seo reports run update-postmortem --params '{"site":"sc-domain:example.com","days":90,"recentDays":7,"limit":10,"includeBrand":false,"knownConfounders":["Site migration on 2026-05-12"],"includeChangeLog":true}' --json

Project profiles can fill supported property and analytics inputs for the human-facing commands. The catalog form shown here is explicit by design, so agents and CI jobs do not prompt or guess.

How an MCP agent should use it

Call seo_describe_report first so the agent sees when this report is useful and gets the current input schema. Then callseo_run_report with the validated parameters. Read the status, warnings, source limits, and skipped sections before acting on a finding.

Describe the report with MCP

{
  "id": "update-postmortem"
}

Run the report with MCP

{
  "id": "update-postmortem",
  "params": {
    "site": "sc-domain:example.com",
    "days": 90,
    "recentDays": 7,
    "limit": 10,
    "includeBrand": false,
    "knownConfounders": [
      "Site migration on 2026-05-12"
    ],
    "includeChangeLog": true
  }
}

Use a follow-up report returned by the result instead of guessing the next tool. The local MCP server and CLI use the same report definition and evidence. Their outer transport envelopes differ.

Use the report in a TypeScript app

Install seo as a project dependency, then call the same report catalog used by the CLI and MCP. executeReportrejects an unknown report id or invalid parameters. Provider and runtime failures come back as structured results withisError set.

Install the library

npm install seo

Run this report from TypeScript

import { executeReport } from 'seo/mcp'

const result = await executeReport(
  'update-postmortem',
  {
  "site": "sc-domain:example.com",
  "days": 90,
  "recentDays": 7,
  "limit": 10,
  "includeBrand": false,
  "knownConfounders": [
    "Site migration on 2026-05-12"
  ],
  "includeChangeLog": true
},
)

console.log(result)

The TypeScript library guide also covers direct core functions, schema discovery, and the difference betweenexecuteReport and runReport.

What comes back and how to read it

A postmortem with confirmed dates, property movement, segment winners and losers, template patterns, and representative pages.
Known confounders, source caveats, and limited investigations with no claim that the update caused a specific movement.
Look for repeated page or intent patterns across winners and losers, then verify representative pages. Timing overlap is context, not causation.

Start with dataStatus, source details, warnings, and caveats. Then inspect the observed evidence before derived findings or suggested actions.

What this report cannot tell you

Update rollouts, seasonality, demand, competitors, and site releases overlap. Search Console evidence cannot isolate them perfectly.

What to do next

Audit representative winner and loser pages.
Record any deliberate response and measure it over a complete later window.

Check traffic changes against Google updates. Place unusual Search Console movement beside confirmed Google ranking update windows without claiming the update caused it.
Find which search segments moved. Compare Search Console movement by page, query, country, or device.
Measure an SEO change. Compare equal, finalised search windows around a recorded change and see what moved without claiming the change caused it.

Sources behind the guidance

These primary sources define the provider data or search controls used in the interpretation above.

Browse all reports in Multi-report workflows.