Traffic drop: how to investigate before blaming it all on Google or AI

When traffic drops, the two explanations that come up first — a Google update, answers generated by artificial intelligence — are also the least verifiable and the least useful, because they don't tell you what to do on Monday morning. Before getting there, four checks explain most drops, and three of them have nothing to do with ranking at all.

The order matters. Whoever starts from the hypotheses ends up looking for evidence that confirms them; whoever starts from the checks arrives at a hypothesis with something in hand.

Does the drop actually exist? Check the tool first

A significant share of sudden drops is a measurement problem. Ruling it out costs half an hour and saves weeks.

• Is the tracking code still on every page? A change to the site or an update may have removed it from part of the site.
• Has anything changed in consent collection? A new banner or a different configuration changes how many visits get counted, without fewer actually arriving.
• Does the drop show up in every data source or just one? If the analytics tool drops but the search data doesn't, the problem is in the tool.
• Have the period, filters, or properties being compared changed? A new filter, a moved domain, or a segment saved by someone else can produce perfect-looking drops that don't exist.
• Have inquiries and phone calls dropped as much as visits? If your workload hasn't dropped, the drop is in the numbers before it's in the market.

Comparing comparable periods

The second check is the calendar, and it closes just as many cases.

• Compare the same period from the previous year, not last month. Many industries have dead months that need no explanation.
• Count the working days: holidays, long weekends, and closed weeks shift the totals without anything having actually changed.
• Look at the shape of the curve. A vertical drop in a single day has different causes than a slow three-month decline: the first is almost always technical or a measurement issue, the second relates to demand, content, or competition.
• Check that the earlier period was normal. Sometimes there's no drop: there was a spike before.

Segmenting: not how much dropped, but where

A total can't be diagnosed. The same loss has opposite meanings depending on how it's distributed. A reading table, to use as a guide.

The distinction between impressions and clicks is the most useful and the most overlooked: it separates "they can't find us anymore" from "they find us and go elsewhere," which are solved in different ways.

What did you change?

It's the question nobody asks first, and it resolves more cases than any analysis. A change log is worth more than one extra tool.

• Changes to the site: structure, page addresses, rewritten text, pages removed or merged, a redesign that went live.
• Technical changes: hosting switch, certificates, redirects, search engine access rules, changes introduced by an automatic update.
• Commercial changes: prices, price lists, a reduced catalog, out-of-stock products, a service no longer offered.
• Communication changes: paused campaigns, stopped mailings, ended partnerships, a link from an important site that disappeared.

The log needs to be kept beforehand, not reconstructed afterward: one row per change, with date and owner. It's also useful the other way around: knowing that nothing changed in the previous six weeks narrows the field.

Availability and indexing

The third block concerns reachability, and it's the one with the most trivial causes and the biggest damage.

• Was the site unreachable or very slow during some period? Whoever hosts it keeps a log of outages.
• Are the pages still indexed? A rule set by mistake or a directive left over from a testing environment is enough to make them disappear.
• Do the redirects work? After a change of addresses, a chain of redirects or an error on part of the site reads in the data like a ranking drop.
• Have errors increased? Page-not-found and server errors need to be looked at over the period, not just on the day you check.

From hypothesis to proportionate action

At the end of the checks, you arrive with two or three hypotheses. Each one should be written down along with the evidence that supports it and the evidence that would disprove it.

1. Hypothesis: what you think happened, in one sentence.
2. Evidence for: what you saw in the data or in the change log.
3. Evidence against: what should be true if the hypothesis were correct, and isn't. If you can't find any, you probably haven't looked for it.
4. Proposed action, proportionate to the strength of the evidence: a fix on three pages is one thing, rebuilding the structure is another.
5. How to verify it: which number should move, by how much, and within what timeframe.

The hypothesis "it was an algorithm update" stays at the bottom of the list not because it's impossible, but because it can only be accepted after everything else has been ruled out. And because, even when it's true, the action that follows from it is almost always the same: fix the pages that deserve to be found.

What this guide doesn't cover

This guide covers investigating a change: understanding what happened before deciding. You won't find recipes to apply to the site without evidence, because that's the fastest way to add a problem to the one you already have. The distinction between being indexed and being ranked, for when the site doesn't appear at all, and reading search tools from the point of view of someone who has to decide, are covered separately.