Weekly Search-Change Triage: Wait, Watch or Act (Agent Routine)

A line moves in Search Console, a page drops out of an AI Overview, or ChatGPT Search stops citing you for a prompt it used to. The expensive mistake is not missing the change. It is reacting to it before you know what it is: rewriting pages during a rollout, or "fixing" a reporting delay. A weekly triage turns each of those moments into a short, dated decision. This guide describes the routine, in order, and how to run it in Claude Code, Cursor or Codex with search-change-triage, one of the two free skills among our Claude SEO skills.

Short answer: once a week, and whenever traffic, rankings, AI Overviews or AI citations move, have your agent check the official sources first, put the change into one class, collect two weeks of evidence against a control, and then choose exactly one of wait, watch or act. Write the decision down with the next check date. Only "act" leads to changes on the site, and then only to the named cause.

Why triage search changes every week?

Because search moves constantly, and most movement is not about your site. Updates roll out over days or weeks, reports lag, and AI answers shift which sources they cite. Without a routine, every wobble ends with someone proposing a rewrite.

A fixed weekly pass does three things. It makes "nothing material changed" a valid, recorded outcome. It builds a dated history, so next week starts from this week's note instead of from memory. And it keeps changes to the site tied to evidence, which makes their effect readable later. Monday works well: the weekend's reports have settled and the week's work has not started.

What should the agent check first?

Official sources, then trade press, then vendor blogs, in that order. Trade coverage is useful for context but often runs ahead of what the search engines have confirmed, and vendor posts tend to frame every change as a reason to buy a tool.

A good first pass covers:

1. The Google Search Status Dashboard for ranking incidents and update rollouts, with their start and end dates.
2. The Google Search Central blog and the Search documentation changelog for guidance and feature changes.
3. Bing's blog and Bing Webmaster Guidelines for Bing and Copilot.
4. The AI search products you care about, for example OpenAI's ChatGPT search help page and the Perplexity changelog.
5. Trade press, last week only, after the official sources.

Two practical notes. The Search Console Performance report shows daily dates in Pacific Time, but its 24-hour view uses your local time, so check which view you are reading and convert before you line a drop up against a rollout window. And keep your own dated list of these URLs: when one moves or dies, update the list the same day so the next run does not silently skip it.

How do you classify a search change?

Pick one class before you look at fixes. The class decides what evidence matters. The free skill uses a short list of durable classes; in plain terms:

• Core update: a broad ranking change announced on the status dashboard.
• Spam update or spam policy change: targets specific patterns; check whether you match one.
• Product or interface change: a new SERP feature, a changed AI Overview layout, a new answer unit.
• Measurement change: a report, metric or data delay changed, not the rankings.
• Docs or rich-result change: guidance rewritten, or a rich result retired.
• AI citation swing: an AI answer engine cites different sources for the same prompts.
• On-site change: your own deploy, migration, template or robots change.

Check the on-site class early. A release log or the repository history often explains a drop faster than any external source, and it is the one class where you already control the fix.

What evidence should you collect before deciding?

Look at the last 14 days, and compare the affected pages with a control: pages the change should not touch. A drop that hits both is probably measurement or sitewide; a drop only in the affected group is a real signal.

Before reading a sudden cliff at the right edge of a chart, check when the report was last updated. A partial day looks exactly like a drop. Check Search Console's Manual actions report on every run; it is the fastest way to confirm or rule out a manual action. A clean report does not rule out an algorithmic change, such as a core or spam update, so keep classifying.

For AI answers, use a fixed set of prompts and run them on the same engines each week. Record which sources each answer cites, and always report how many prompts you ran next to any rate. "Cited in some answers" with a sample size is honest; a percentage without one is not. geo-citation-playbook covers this measurement in depth, and aeo-answer-surface-playbook covers single answer surfaces such as featured snippets.

If the question is really "how is this site doing overall?", that is a period review, not a triage. Use gsc-growth-review for that instead.

When should you wait, watch or act?

The decision is one of three, and the triage note names exactly one.

Wait when the change is real but not yet readable. An update still rolling out, or one that finished only days ago, needs time before the data means anything. Residual wobble after a completed update, with no new incident, is also a wait. So is a shift in one AI engine's citations when the others are stable.

Watch when something is happening that could reach you but has not yet. A spam update in flight with no manual action on your property is a watch. So is a product or measurement change announced but not visible in your data. Name what you are watching and when you will look again. Once a rollout completes, a watch item usually becomes a wait.

Act when there is a specific, fixable cause on your side:

• a manual action in Search Console (fix the named pattern, then request review);
• a robots.txt rule, noindex or snippet control blocking pages you want shown;
• an indexing collapse after a deploy;
• an accidental opt-out of search features you rely on;
• a content pattern that a current spam policy names.

"Act" means fixing that cause. It does not mean rewriting the site. A broad rewrite during a rollout destroys the evidence you would need to tell whether anything you did helped.

What does the weekly triage note look like?

One page, with the same headings every week, so anyone can scan it in a minute:

Search triage, week of <date>

Class: <one class>
Decision: <wait | watch | act>

What changed: <official link> (<date>)
What did not change: <the things people will ask about>
What we measured: <reports, date range, control group, sample size>
What we will not do: <the tempting overreaction, named>
Next check: <date, usually next Monday>

The "what we will not do" line matters more than it looks. It records the panic rewrite, the "GEO schema" or the llms.txt file expected to move Google rankings, before anyone starts on it. If nothing material changed, the note can be two lines.

Run the weekly search-change triage for example.com.
Search Console export for the last 14 days is in data/gsc/.
Report only: one class, the evidence, and wait, watch or act.