SEO

Algorithm update triage

Use when traffic drops and you need to work out whether an update caused it before reacting.

algorithm-update-triage.md

Download .md

You are triaging an organic traffic drop. Your job is to rule things out before blaming an algorithm update.

Site: {{SITE_URL}}
Drop details (dates, percentage, which metric): {{DROP_DETAILS}}
Segment data (by page type, country, device, query group): {{SEGMENT_DATA}}
Known site changes in the 30 days before the drop: {{SITE_CHANGES}}

Work through these in order and report on each:
1. Measurement - could this be tracking, sampling, filtering or a reporting change?
2. Technical - deployment, robots, noindex, canonical, server errors, migration.
3. SERP shift - feature changes, new competitors, intent shift.
4. Seasonality and demand - is impressions down as well as clicks?
5. Only then: algorithmic.

Output format: for each of the five, a verdict of Ruled out / Possible / Likely, the evidence, and the single check that would confirm it.

Finish with: "Most probable cause" (one line), "Do not do this yet" (three things people wrongly rush into), and "Next 7 days" (three concrete checks).

Constraints:
- Do not name a specific named update as the cause unless {{DROP_DETAILS}} dates align with one you can identify from the supplied information. Otherwise say "timing consistent with a broad update, unconfirmed".
- If impressions held steady while clicks fell, say plainly that this points at SERP presentation, not ranking loss.

Fill in before running

Replace each placeholder with your own detail. The more specific you are, the less the model invents.

{{SITE_URL}}
{{DROP_DETAILS}}
{{SEGMENT_DATA}}
{{SITE_CHANGES}}

Getting a better result

Segment before you paste - a site-wide percentage hides the fact that one template took the hit.
Include impressions as well as clicks, since the two moving differently changes the diagnosis entirely.
Resist acting on the algorithmic branch until the first four are genuinely ruled out.

Questions about this prompt

When should I use this instead of reacting to the drop?

Before you change anything. Most traffic drops attributed to an algorithm update turn out to be a tracking break, a seasonal pattern, a deployment or a manual action. Rebuilding content in response to an update that did not affect you is expensive and slow to undo.

What data do I need?

Segmented data, not a site-wide percentage, plus impressions alongside clicks. A single site-wide number hides the fact that one template took the whole hit. Impressions and clicks moving differently changes the diagnosis completely: impressions holding with clicks falling is a presentation problem, not a ranking one.

How does it decide it was an update?

By ruling out the alternatives first, in order. The algorithmic branch is the last one it reaches, which is deliberate, because it is the branch people jump to first and the one with the most expensive response.

What if it really was an update?

Then the useful output is which segment was hit and what those pages have in common, not a generic recovery checklist. Core updates reassess quality at the pattern level, so the pattern is what you have to change.