Nick QuirkEvery SEO agency has lived this month. You are three weeks into a content phase, the sprint board is clean, and then Google confirms a core update. Slack lights up. Two account managers ask if the client should be told. Someone pulls a Search Console export at 9pm. By Friday, four people have spent time on the same investigation, none of it is logged against a project, and the deliverables that were due slipped a week.
Algorithm update tracking is not a research hobby. It is an operational process that sits inside your project plan, consumes retainer hours, and produces artifacts your clients read. If it lives outside your project management system, it will quietly eat 5-10% of your delivery capacity every quarter and you will never see it on a report.
This article covers how to run update tracking as a first-class workflow next to deliverables: what to log, when to react, how to protect the roadmap, and how to bill for it.
Why updates wreck agency project plans
Google confirms roughly nine to thirteen ranking updates in a typical year — core updates, spam updates, reviews and product-review refreshes — plus a steady drizzle of unconfirmed volatility. The rollouts are not instant. The March 2024 core update ran for about 45 days. Some spam updates have finished in under a week. That range is the actual problem: you cannot plan a fixed response window when the event itself might last six weeks.
Three failure modes show up again and again:
- Panic reallocation. An account manager pulls two writers off a scheduled cluster to "investigate," and a 12-article deliverable slips a month for a client whose traffic moved 4% — inside normal variance.
- Invisible labor. Update triage gets done but never logged, so the retainer looks like it delivered 28 hours of value when it actually delivered 36. Margin disappears with no paper trail.
- Amnesia. Six months later, nobody remembers whether the client dropped during the August update or during their own site migration two weeks earlier. Without annotated data, every QBR becomes a debate about vibes.
Separate the log from the response
The single most useful structural decision is to split algorithm update tracking into two distinct objects.
1. The update log (one record, all clients)
This is a shared reference table your whole team reads. One row per confirmed update, with:
- Update name and type (core, spam, helpful content, product reviews, unconfirmed volatility)
- Announcement date, rollout start, rollout end
- Source links — the official Google post and two or three tracker screenshots
- Affected accounts flagged as watching, impacted, or clear
- A one-paragraph plain-English summary written by whoever owns SEO research
Critically, this log is not a task list. Nobody is assigned to it. It exists so that when a client emails "did something happen last Tuesday?", any AM can answer in 30 seconds without pinging the SEO lead.
2. The triage task (one per impacted client)
Only clients that cross a defined threshold get a task. Define the threshold in writing so it is not a judgment call at 9pm. A workable default: a 15%+ change in clicks over a seven-day rolling window versus the prior four-week baseline, or a shift of more than three positions on tracked head terms representing 20%+ of non-brand traffic. Anything below that goes in the log as "watching" and gets revisited when the rollout ends.
This threshold discipline is what saves your roadmap. In a 20-client agency, a typical core update produces two or three genuine triage tasks — not twenty.
The 72-hour triage protocol
When a client does cross the threshold, run a fixed sequence so the work is bounded and estimable. Budget three to four hours, not "as long as it takes."
- Confirm the timing (30 min). Overlay the traffic change against the rollout start date. If the decline began five days before the announcement, this is probably not the update — check deploys, robots.txt, CDN changes, and any recent site releases first.
- Segment the damage (60 min). Break the loss down by directory, template, intent type and device. A drop concentrated in one blog subfolder is a very different story from a site-wide 20% haircut.
- Check the SERP, not just the site (45 min). Pull the top 10 for five representative lost queries. Very often the "drop" is an AI Overview, a new forum block, or a shopping module compressing organic real estate — which changes the recommendation entirely.
- Write the internal note (30 min). Three bullets: what moved, what it correlates with, what we are doing (including "nothing yet, waiting for rollout end").
- Decide the client comms (30 min). Proactive email, mention at the next call, or nothing.
The output of triage is a decision, not a plan. Remediation is scoped separately, after the rollout completes plus about a week of stable data.
Fold volatility into your phase structure
Most agency projects are structured in phases — audit, technical remediation, content production, authority building. Updates do not fit neatly into any of them, which is why they get bolted on badly.
Two patterns work well. The first is a permanent low-intensity workstream that runs parallel to every delivery phase: "Monitoring & Volatility," with a small recurring allocation each month. The second is a conditional phase that only activates when triage escalates — "Post-Update Remediation," pre-scoped as a template with typical tasks (content refresh audit, E-E-A-T review, internal link redistribution, template-level fixes) so you can spin it up in an hour instead of writing a proposal from scratch.
The second pattern pairs naturally with the way most agencies already build roadmaps from data. If you already connect search data to project milestones, an update is just another data trigger that promotes a candidate task into an active phase — the same mechanism, different input.
The same goes for keyword monitoring. Rather than a human refreshing rank trackers during every rollout, automated keyword tracking alerts can push threshold breaches straight into the relevant client project as a draft triage task, with the baseline numbers already attached.
Retainers: who pays for the response?
This is where agencies bleed. Be explicit in the contract and explicit in your capacity plan.
A practical split for a 40-hour monthly retainer:
- 4-6 hours (10-15%) reserved as a volatility buffer. Covers log maintenance, monitoring, triage and client comms. In a quiet month, it rolls into opportunistic work — not into extra deliverables you did not sell.
- Remediation is separate. A site-wide content refresh across 60 URLs is a project with an estimate, not something you absorb because "the update caused it."
Track update work against real time entries with a distinct label. After two quarters you will have a number — most agencies find volatility work runs 6-11% of delivered hours — and you can price it properly instead of guessing. This is exactly the kind of cost that stays invisible in generic tools; it is the same dynamic behind the context switching cost that quietly drains agency hours.
Reporting: annotate, do not narrate
Clients do not want an essay about the helpful content system. They want their own chart with a vertical line on it and a sentence.
Make every client report carry the same annotation layer, drawn from your central update log. Three lines of copy is enough: "March core update, rollout Mar 5 – Apr 19. Non-brand clicks down 8% during the window,
