Sign in Start free

Separating Algorithm Updates From Your Own Changes

The instinct is to check an update tracker, see a rollout in the same week, and blame Google. That is wrong roughly half the time, because deploys, CMS changes and template edits cluster around the same dates and nobody logged them. You need a test that distinguishes a site-wide ranking shift from a technical or content-specific one.

CATEGORY
Analytics & reporting
FORMAT
update-vs-self-inflicted.md
STEPS
6
PRICE
Free - no account
WHEN TO REACH FOR THIS

Use when organic traffic drops and someone asks whether it was Google or something you shipped.

The skill file

update-vs-self-inflicted.md 
---
name: update-vs-self-inflicted
description: Use when organic traffic drops and someone asks whether it was Google or something you shipped.
---

# Separating Algorithm Updates From Your Own Changes

The instinct is to check an update tracker, see a rollout in the same week, and blame Google. That is wrong roughly half the time, because deploys, CMS changes and template edits cluster around the same dates and nobody logged them. You need a test that distinguishes a site-wide ranking shift from a technical or content-specific one.

## What you need first

- daily clicks and impressions by page group from Search Console
- a deploy or CMS change log covering the drop window
- a confirmed update timeline for reference

## Method

1. Split clicks from impressions immediately. Impressions flat but clicks down is a SERP layout or CTR change, not a ranking loss - do not start rewriting content.
2. Check whether the drop is gradual over 5-14 days or a cliff inside 48 hours. Core updates roll out slowly. Cliffs are almost always yours: a robots change, a noindex, a broken template, a CDN rule.
3. Segment by page type and by query intent. A genuine core update hits unevenly across topics. A technical fault hits one template uniformly regardless of topic.
4. Cross-reference the exact drop date against your deploy log before you look at any update tracker, so the tracker does not anchor you.
5. Check whether competitors moved. If your position held and clicks fell, Google added an AI overview or a feature block above you and no ranking work will recover it.
6. Write the conclusion as a falsifiable statement with the evidence that would overturn it, and annotate the date.

## What this produces

A dated written diagnosis naming the cause, the evidence for it, and what would disprove it.

## Where this goes wrong

- Comparing to the previous period when the previous period contained a seasonal peak, which manufactures a drop that never happened
- Treating an unconfirmed tracker spike as evidence - those trackers measure volatility, not causation, and they spike during your own migrations too
- Declaring recovery because one week rose, when the week you compared to contained a bank holiday

---

From the QuQi skill library - https://www.quqi.io/skills/update-vs-self-inflicted
Free to download · no account, no email

What you need first

  • daily clicks and impressions by page group from Search Console
  • a deploy or CMS change log covering the drop window
  • a confirmed update timeline for reference

Method

  1. 01 Split clicks from impressions immediately. Impressions flat but clicks down is a SERP layout or CTR change, not a ranking loss - do not start rewriting content.
  2. 02 Check whether the drop is gradual over 5-14 days or a cliff inside 48 hours. Core updates roll out slowly. Cliffs are almost always yours: a robots change, a noindex, a broken template, a CDN rule.
  3. 03 Segment by page type and by query intent. A genuine core update hits unevenly across topics. A technical fault hits one template uniformly regardless of topic.
  4. 04 Cross-reference the exact drop date against your deploy log before you look at any update tracker, so the tracker does not anchor you.
  5. 05 Check whether competitors moved. If your position held and clicks fell, Google added an AI overview or a feature block above you and no ranking work will recover it.
  6. 06 Write the conclusion as a falsifiable statement with the evidence that would overturn it, and annotate the date.

What this produces

A dated written diagnosis naming the cause, the evidence for it, and what would disprove it.

Where this goes wrong

  • Comparing to the previous period when the previous period contained a seasonal peak, which manufactures a drop that never happened
  • Treating an unconfirmed tracker spike as evidence - those trackers measure volatility, not causation, and they spike during your own migrations too
  • Declaring recovery because one week rose, when the week you compared to contained a bank holiday

Use this skill in your own AI

The download is a plain markdown file with the name and trigger in its frontmatter. Where an assistant supports skills it can load itself, that frontmatter is what it reads to decide this one applies.

Claude Code Save it as ~/.claude/skills/update-vs-self-inflicted/SKILL.md and Claude loads it on its own when what you are doing matches the trigger line. Put it in .claude/skills inside a project instead if the whole team should have it.
Claude Upload the file in the skills section of your settings. Once it is there it applies itself in any conversation where the trigger fits, so you do not have to remember it exists.
ChatGPT There is no skills format to install into, so paste the file contents into a Project instruction or a Custom GPT instead. It then applies to every chat in that project rather than only the one you paste it into.
Anything else Paste the markdown into the chat before your question. It works in any assistant, it just has to be pasted again each time.

Questions about this skill

When should I run this diagnosis rather than check an update tracker and compare dates?

When traffic falls and matching the date to a rollout is the first instinct. Rollouts, deploys, CMS edits and template changes cluster in the same weeks, so a tracker will nearly always hand you a plausible candidate. This method separates a site-wide ranking shift from a technical or content-specific fault by shape and segment, before any tracker is allowed to anchor you.

What do I need in hand before starting, and what happens if I start without it?

Daily clicks and impressions split by page group, and a deploy or CMS change log covering the drop window. Without the log you cannot rule your own release out, so the diagnosis defaults to blaming Google. Without impressions beside clicks you cannot tell a ranking loss from a click-through loss, and you will start rewriting content in response to a SERP layout change.

What do I end up with, and which part of it actually gets used?

A dated diagnosis naming a cause, the evidence behind it, and what would overturn it. The falsifiable clause is the part that gets used later: it is what lets somebody check six months on whether the call was right, rather than storing an opinion. The date also feeds the change log that the next investigation will read first.

What is the mistake that most often ruins this, and what does it cost?

Comparing against a previous period that contained a seasonal peak, which manufactures a drop that never happened and sends a team chasing it for a fortnight. The same error runs in reverse when one good week gets called a recovery against a comparison week holding a bank holiday. Settle the comparison window and the gradual-versus-cliff shape before interpreting anything.

More in Analytics & reporting

Striking Distance Query Analysis

Use when you have Search Console data and need to decide which queries are worth working on this...

Annotation Discipline

Use when setting up or repairing the record of what changed on a site and when.

Organic Attribution Reality

Use when someone asks what organic search actually contributed to revenue and last-click says le...

A Report That Survives An Executive

Use when preparing an SEO report for people who will not read past the first page and will remem...