Model Updates Are the New Algorithm Updates

Anyone who did SEO in the 2010s remembers the rhythm: Google ships an algorithm update, rankings lurch, forums light up, and everyone scrambles to work out what changed and who won. The updates had names — Panda, Penguin, Hummingbird — and they reshaped the discipline.

The AI era has its own version, and it’s the model update. When a provider ships a new model, the engine’s behaviour can change, including how it describes, ranks and recommends brands. The brand confidently recommended last month might be hedged about this month, with nothing on your end having changed.

The analogy is useful. It’s also incomplete in a way that matters, and the second half of this post is about where it breaks.

Why a new model shifts your visibility

A model update isn’t a cosmetic version bump. A newer model may:

• Weigh sources differently, elevating some kinds of authority and discounting others.
• Carry a later knowledge cutoff, suddenly “knowing” about your rebrand, launch or recent coverage — or a competitor’s.
• Reason differently about comparisons, changing who makes the shortlist.
• Apply different guardrails, becoming more or less cautious about making recommendations in your category.

Because so much of AI visibility flows from the model’s learned view of the world, changing the model changes the view. See navigating AI model updates and how LLMs learn about brands.

Unlike a search algorithm update, this is documented. Providers publish model identifiers, ship dates and deprecation timelines — Anthropic maintains a model overview listing versions and their lifecycle, and comparable references exist for the other major providers. That’s a meaningful improvement on the Google-update era, where the community was reduced to inferring from ranking volatility whether anything had shipped at all. You can know when. You still can’t know what changed about your brand without measuring.

The two clocks

Here’s the nuance the old SEO mental model misses. AI engines run on two clocks, and confusing them produces most of the bad advice in this space.

1. The training clock — the model’s baked-in knowledge, which only changes when a new model ships. This is where model updates hit hardest, and where you have no short-term lever at all.
2. The retrieval clock — live web content fetched at query time, which updates continuously.

This is why the same brand can look outdated in a plain chat answer and current in a search-grounded one: one is reading training memory, the other is reading today’s web. Providers document the second clock directly. Google’s Gemini API documents grounding with Google Search, which connects a model to live results and returns supporting links; other providers ship equivalent search tools.

Knowing which clock a given answer ran on tells you whether to wait for the next model or fix something retrievable this afternoon. It’s the single most useful diagnostic question in AEO, and almost nobody asks it before drawing conclusions from an engine comparison.

Where the algorithm-update analogy breaks

Three ways, and each one changes what you should do.

Google updates were universal; model updates are staggered. A core update landed on everyone’s rankings at roughly the same time, which is why the community could pool observations and converge on a story within days. Providers ship independently, on their own schedules, and many products let developers pin a specific model version — so “the update” may reach different surfaces weeks apart, and some users not at all for a while. There’s no shared moment to compare notes around.

Rankings were observable; model behaviour is sampled. You could check a ranking and get the same answer twice. Generated answers vary run to run, so a change you notice after a release may be a genuine behavioural shift or may be a different draw from the same distribution. This is the biggest practical difference, and it means the post-release scramble that worked in SEO — check, panic, react — actively misleads here. Establish variance before a release, or you cannot interpret anything after one.

Google published intent; providers publish capabilities. Search updates came with guidance about what the change was trying to reward, which gave practitioners something to act on even if the specifics stayed opaque. Model release notes describe benchmarks, context windows and features. They do not describe how brand descriptions shifted, because nobody was optimising for that — it’s an emergent property nobody at the provider measured.

That last point is worth sitting with. Nobody publishes a changelog for how a model talks about your company. If you want to know, you have to measure before and after yourself. There is no equivalent of the SEO community’s shared post-mortem, and there probably never will be.

A worked example

Suppose you notice, a week after a major release, that your brand has vanished from “best tools for [your category]” on one engine. The instinct is to treat this as a ranking loss and start rewriting content.

Work through it in order instead. Was the query grounded or ungrounded? If grounded, the model change is largely irrelevant — the answer came from live pages, and you should be looking at which sources were retrieved, not at the release. If ungrounded, how many times did you run it, and how many times did you run it before the release? One-versus-one tells you nothing. And did competitors move too? A shortlist that reshuffled for everyone is a behavioural change in the model; a shortlist where only you dropped is more likely to be about you.

Most investigations that start with “the update hurt us” end somewhere else entirely — usually at sampling variance, occasionally at a retrieval change that predates the release by weeks. The value of the sequence is that it costs an hour and stops you rewriting a page that was never the problem.

How to operate in a model-update world

You can’t control when models ship, but you can build a practice that absorbs the shocks.

Establish variance before you need it. Measure your tracked prompts repeatedly during a quiet period so you know what normal fluctuation looks like. Without that, every post-release movement looks like a finding, and you’ll spend a week explaining noise.

Re-baseline after major releases. Treat a significant release like an algorithm update: re-run the same tracked queries, the same number of times, and compare. This is what continuous multi-engine monitoring is for — the value is having the before, which you cannot construct retroactively.

Watch the whole panel, not one engine. Providers update on different schedules, so tracking multiple engines separates a model-specific shift from an industry-wide one. If your visibility drops on one engine and holds on five, that’s a release. If it drops everywhere at once, something changed about you or your category.

Fix what’s on the retrieval clock now. If an outdated representation is hurting you, you don’t have to wait for the next model. Improving live, crawlable content can influence search-grounded answers quickly, and it’s the only lever with a short feedback loop.

Don’t over-fit to one model’s quirks. Optimising for the idiosyncrasies of a specific model version is the AI-era equivalent of chasing a single ranking factor. It ages badly, and it ages badly on a schedule you don’t control.

The reassuring part

Here’s the difference from the old algorithm-update anxiety: the brands that weathered Google’s updates best weren’t the ones who chased each change. They were the ones whose quality and authority the updates kept rewarding. The same logic applies now, for a mechanical reason rather than a moral one — a brand that many independent sources describe consistently and specifically is a brand that survives a change in how sources are weighted, because it looks the same from most angles.

So treat model updates as the new algorithm updates: worth monitoring, worth re-baselining around, and worth measuring rather than inferring. Then build the foundation that doesn’t need the updates to go your way, and let them come.