Algorithm Update Response Runbook

An algorithm update response is an incident investigation, not an editing sprint. Its first rule is simple: confirm the drop is real and is yours before reacting. “Real” means the decline persists in complete, comparable data. “Yours” means it reflects your site’s search visibility rather than broken measurement, reduced demand, a changed result layout, or an update that has not affected your pages.

Checklist: Algorithm Update Response. Timebox: 60–90 minutes for triage on day one; 2–4 hours for segmentation during the first week; a formal act-or-wait decision after seven complete days, unless a verified technical fault requires immediate repair. Owner: the SEO lead owns the incident and decision log; an analyst validates the data; engineering owns technical faults; content owners approve page changes.

Use this runbook when a material search decline overlaps a confirmed or suspected Google algorithm update , meaning a change to Google’s ranking systems. It is also suitable when no update has been confirmed but many URLs move together and the cause is unclear.

Why this phase, and why here

This checklist consumes the dated baseline measurement , release annotations, page ownership map, template inventory, intent classification, analytics, Search Console data, and conversion definitions established earlier in the process. Without those inputs, a team can see that a line moved but cannot establish what changed, where it changed, or whether it matters to the business.

The order matters because measurement faults and site faults can imitate algorithm losses. A consent change can remove analytics sessions. A deployment can add noindex, choose the wrong canonical, or hide internal links. Seasonality can reduce searches while rankings remain stable. Diagnose those cases before attributing the decline to an external system.

Running remediation before segmentation causes a second problem: attribution disappears. If the team rewrites titles, restructures templates, removes pages, and changes internal links in the same week, any later recovery or decline has several plausible causes. The response must therefore move from verification, to pattern isolation, to a recorded act-or-wait decision, and only then to a controlled intervention.

Inputs and outputs

The decision record is the contract with the next step. “Google changed something” is not a deliverable; a bounded pattern, an explicit decision, and evidence that another reviewer can inspect are.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

The checklist

1. Confirm that the drop is real and is yours

What: verify the loss across independent measurements before assigning a cause. Why: incomplete reporting, tracking failures, weekends, seasonality, news cycles, and changing demand can create a convincing false alarm. Organic traffic means unpaid visits from search results; it can fall even when rankings do not. How: use complete days, compare equal weekday-aligned periods, check Search Console clicks and impressions against analytics sessions and conversions, inspect year-over-year context where seasonality exists, and note the latest date each source has finalized. Tool: search performance data, analytics, conversion reporting, uptime logs, and the release calendar. Done when: at least two independent signals agree on direction, the last three complete days remain below the selected baseline, data freshness is recorded, and the brief states whether the loss is visibility, demand, tracking, conversion, or a mixture.

2. Exclude causes you control

What: test for site, tracking, security, and indexing faults. Why: a verified defect deserves immediate repair, while waiting for an update to finish would extend preventable loss. Indexability is a page’s ability to be included in a search engine’s index. How: inspect affected and unaffected URLs for response status, robots directives, canonical, rendering, internal links, sitemap presence, manual-action notices, and analytics events; align any change with its release time. Tool: URL inspection, server and deployment logs, crawler output, analytics debugger, uptime monitor, and change record. Done when: every candidate fault is passed, disproved, or assigned with an owner; any fault matching the onset is labeled repair now and separated from algorithm hypotheses.

3. Segment by directory, template, and intent

What: build an impact matrix instead of judging the site-wide average. Why: a broad total can hide the actual pattern: product pages may fall while guides grow, one template may lose mobile clicks, or informational queries may move while branded demand remains stable. Search intent is the task a person wants to complete with a query. How: calculate before-versus-after changes for clicks, impressions, position, conversions, and affected URLs; group first by directory, then template, primary intent, device, country, query class, and business role. Include stable or gaining groups as controls. Use weighted absolute totals as well as percentages so ten lost clicks on a small segment do not outrank ten thousand lost clicks on a large one. Tool: directory, page, query, URL-mover, and keyword-mover reports plus a spreadsheet or analysis notebook. Done when: the matrix covers at least 95% of search clicks, shows affected and control segments, records low-volume groups as inconclusive, and names the narrowest repeatable pattern supported by the data.

4. Inspect representative winners and losers

What: review pages and queries that best represent each affected and control segment. Why: aggregates locate the damage but do not explain it. A search engine results page can replace classic listings with shopping units, local results, video, or AI answers; that change may reduce clicks without showing a correctable page defect. How: select at least five high-impact losers and five stable or gaining controls when the segment contains enough URLs. Compare intent satisfaction, originality, evidence, authorship, commercial load, update history, internal routing, snippet changes, and competing result formats. Record observations as hypotheses, not as ranking-factor claims. Tool: live result review, page render, source record, competitor pages, search data, and content inventory. Done when: every hypothesis cites examples from losers and controls, contradictory evidence is retained, and no recommendation rests on one page or one query alone.

5. Freeze panic edits during week one

What: prohibit broad, speculative changes while continuing diagnosis. Why: mass title rewrites, publication-date changes, page deletion, site-wide word-count targets, template redesigns, and link churn alter multiple variables at once. They can damage pages that were not affected and make any later movement impossible to attribute. How: create a seven-complete-day change window from the observed onset. Allow only verified repairs, legal or factual corrections, security work, and already-approved launches whose deferral carries greater risk; annotate each exception. Preserve copies of current pages and exports. Tool: release calendar, CMS permissions, incident log, and annotation system. Done when: the freeze scope, start, end, approver, and exceptions are visible to publishers and engineers; zero unlogged SEO experiments ship inside the window.

6. Choose act, wait, or repair now

What: make a decision at a named checkpoint. Why: endless observation leaves genuine defects untreated, while reflexive action converts uncertainty into uncontrolled change. How: choose repair now for a reproduced technical or measurement fault; choose act when a material loss persists, concentrates in a coherent segment, and a page or system weakness explains both losers and controls; choose wait when rollout, data lag, seasonality, low volume, or contradictory segments prevent a defensible cause. Record the rejected alternatives and the evidence that would change the decision. Tool: incident brief, impact matrix, representative review, business-risk assessment, and approver. Done when: the record has one decision, confidence level, owner, review date, evidence links, and a trigger for reopening it.

7. Run one controlled intervention

What: translate an act decision into a bounded repair or experiment. Why: one hypothesis and one coherent change set preserve the chance to learn; simultaneous site-wide changes do not. How: define the affected cohort, untouched comparison group where practical, precise weakness, intended reader improvement, expected metric, observation window, acceptance threshold, and rollback route. For decayed pages, use the content refresh checklist rather than changing dates or expanding copy blindly. Tool: action brief, page inventory, CMS, QA record, release owner, and annotations. Done when: every changed URL maps to the diagnosed pattern, the intervention has passed QA, controls remain unchanged or deviations are logged, and the release annotation states what should move and by when.

8. Measure, document, and close or iterate

What: evaluate the intervention separately from the update narrative. Why: recovery after a release is association, not proof that the release caused it; the update may still be rolling out, competitors may change, and demand may return. How: compare the declared post window with the frozen baseline, retain the same segmentation, inspect controls and conversions, and record confounders. Classify the outcome as positive, neutral, negative, or inconclusive. Tool: annotation outcomes, mover reports, analytics, conversion reporting, and the incident record. Done when: actual versus expected results are attached, confidence and limitations are stated, the owner selects close, extend observation, revert, or run a new bounded hypothesis, and the next review date is set.

Tools in AmICited

AmICited makes the diagnosis reproducible by preserving periods, segments, and interventions. It does not prove what an algorithm rewards; use the reports to locate patterns and test decisions.

1. Open Organic Rank with the Organic Rank Report to compare demand, average position, and clicks across connected search channels. Use it to decide whether the incident is broad or channel-specific.
2. Open URL Position Movers with URL Position Movers to identify the pages creating the loss, compare periods, and split movement by device and section.
3. Open Keyword Position Movers with Keyword Position Movers to separate changed query rankings from lost demand and to find intent-level patterns.
4. Open Google Search Directories with Google Search Directories to drill from the whole site into the directories where clicks or impressions changed.
5. Use Google Search Pages with Google Search Pages and Google Search Queries with Google Search Queries to validate representative URLs and the exact searches they served.
6. Open Annotation Outcomes with Annotation Outcomes to record the intervention, expectation, checkpoint, and result. Treat a graded outcome as evidence of association, not proof of causation.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Decision rules

These are incident-control defaults, not claims about how Google scores pages. Their purpose is to prevent both overreaction to noise and inaction during a material failure. Replace them only with a documented threshold based on the site’s established volatility and business risk.

Percentages alone are insufficient. A 50% decline from two clicks to one is not operationally equivalent to a 15% decline involving thousands of visits. Always retain absolute volume, conversion exposure, and confidence beside the relative change.

Deliverable: the algorithm update incident packet

Hand over one dated folder or incident record, not a slide saying “core update impact.” It contains:

1. A one-page incident brief with onset, severity, suspected update, data freshness, business exposure, owner, and current decision.
2. Frozen exports or report links for baseline and incident periods, including filters and timezone.
3. An impact matrix by directory, template, intent, device, country, page, and query, with affected and control cohorts.
4. A cause-exclusion log covering measurement, demand, releases, crawling, indexing, rendering, security, and result-layout changes.
5. Representative loser and control reviews, with supporting and contradictory evidence for each hypothesis.
6. The act/wait/repair decision, rejected alternatives, approver, next review date, and evidence that would reopen the incident.
7. For an intervention, the exact URL cohort, change specification, QA record, rollback route, release annotation, checkpoint, and final outcome.

Use a machine-readable table for the impact matrix and a human-readable summary for the decision. The packet is complete when another analyst can reproduce the affected pattern without asking which filters were used, and a publisher can see exactly what is approved without interpreting a chart.

What goes wrong

The update becomes the explanation for everything

An announcement and a traffic decline occur near each other, so the team stops testing alternatives. The fix is to maintain an exclusion log and require corroboration. Timing establishes a hypothesis, not ownership of the loss.

Site averages hide opposing movements

Guides gain while category pages lose, but a flat total makes the event look harmless. Or one large directory falls and makes every template look weak. Segment the same data by directory, template, intent, device, and country, and retain stable groups as controls.

Week-one edits destroy attribution

Teams rewrite pages because action feels safer than waiting. A recovery then cannot be separated from rollout completion, demand, competitor changes, or the edits themselves. Freeze speculative work for seven complete days and annotate every exception.

Percentage changes exaggerate tiny samples

A low-volume group drops from four clicks to two and becomes the top “loser” at 50%. Always pair relative change with absolute clicks, impressions, affected URL count, and business value. Mark thin segments as directional.

Controls are chosen after the result

If stable pages are selected only after seeing which ones stayed stable, the comparison flatters the preferred explanation. Declare control logic before the intervention: same template but different intent, same intent but different template, or unaffected country/device within the same cohort.

Several fixes ship as one package

Titles, body copy, navigation, schema, and templates change together. Even a positive outcome teaches little. Split causes into separate interventions where operationally possible; when they cannot be separated, record the package and lower the attribution confidence.

Recovery is reported as proof

The metric improves after a release, so the action is declared causal. Report the sequence accurately: the change was followed by recovery, controls behaved in a stated way, and known confounders remain. That language is more useful than certainty the evidence cannot support.

Next phase

A verified technical fault moves to its engineering owner immediately, with the affected cohort and retest condition attached. A diagnosed page-quality problem moves into the content refresh workflow. An inconclusive incident returns to observation with a named review date rather than entering an indefinite backlog.

The ongoing continuous refresh and iteration phase needs four things from this runbook: the affected cohort, the accepted or rejected hypothesis, the action and annotation record, and the next measurement date. It uses those outputs to prioritize work without treating every ranking fluctuation as decay.

FAQ

The incident owner should publish the frontmatter FAQ answers in the page’s FAQ component and keep them aligned with the decision rules above. The governing principle remains the same across every answer: verify, segment, decide, change one bounded system, and measure.

Respond with evidence, not urgency

Open the Organic Rank report , freeze the comparison dates, and create the first incident brief before changing a page. The fastest useful response is a decision the team can later explain.