Check the shape of the graph before you change anything on the site. A cliff, a slope, and a seasonal dip have completely different causes, and the shape tells you which one you are dealing with in about thirty seconds. Most panicked rewrites happen because somebody skipped this step.
We get this call a few times a month. Traffic is down, somebody has already started rewriting pages, and nobody has looked at whether the drop lines up with a known Google update or a broken redirect from last Tuesday. The rewriting is almost always premature.
Google publishes its own guide to debugging search traffic drops, and it is the right starting point. What follows is that framework plus the order we actually work through it on client sites.
Google documentation groups them into algorithmic updates, technical issues, security issues, manual actions, and seasonality or changing interests. Almost every drop we investigate turns out to be one of those five. There is a sixth possibility worth keeping in mind, which is that the reporting itself glitched.
Google actually lists that last one explicitly in its own guidance, complete with a shrug emoticon. It is a useful reminder that not every dip in a dashboard reflects something that happened to real users.
The value of a fixed list is that it stops the guessing. Instead of asking the open question of why traffic fell, you work through five closed questions and eliminate them one at a time. That takes an afternoon rather than a fortnight.
Work them in order of how cheap they are to rule out. Technical issues and manual actions are quick binary checks. Algorithmic causes take the longest to confirm, so leave them until you have eliminated the others.
Google guidance maps chart shapes to causes directly. A large sudden drop suggests an algorithmic update or a site wide security or spam problem. A more gradual decline points to a technical issue across the site or to changing interests. A repeating annual pattern is seasonality.
So pull the Search Console Performance report and set the date range to 16 months rather than the default three. Google uses exactly that range in its documentation to make yearly patterns visible, and a lot of apparent disasters resolve themselves once you can see the same week last year.
A cliff edge that starts on one specific day is the easiest to diagnose, because you can go and find out what happened that day. A slope that started somewhere in the last two months is the hardest, and usually the most boring in its cause.
If you have not spent much time in this report, our Google Search Console guide covers how to read it properly before you start drawing conclusions from it.
Compare your drop date against the Google Search Status Dashboard, which lists every confirmed ranking update with its start and end dates. If your decline began inside a rollout window, an algorithmic cause is likely. If it began on a date with no update running, look elsewhere.
The 2026 dates are on that dashboard and worth knowing. Google ran a March 2026 spam update starting 24 March, a March 2026 core update starting 27 March that took just over 12 days to roll out, a May 2026 core update starting 21 May that took nearly 12 days, and a June 2026 spam update starting 24 June.
Those durations matter more than the start dates. A core update taking almost two weeks to finish means your traffic can move several times during the rollout, in both directions. Judging your position from day three of a twelve day update is how people talk themselves into changes they later reverse.
If the timing does line up with a core update, the Google advice is not to make hasty changes. Its guidance on drops points you toward reviewing how your top pages were ranking and whether they slipped a few positions rather than disappeared, which is a very different problem from being deindexed.
Check whether Google can still crawl, index, and serve your pages. Google defines technical issues in exactly those terms, and they are the most common cause we find on sites that recently launched, migrated, or shipped a redesign. They are also the easiest thing to fix once you find them.
Start with the page indexing report in Search Console and look for pages that moved into an excluded state around the drop date. A block of URLs suddenly reporting as not indexed is the clearest signal there is.
Then check the obvious mechanical things. A stray noindex tag pushed to production, a robots.txt rule that blocks more than intended, a server that started timing out, or a redirect chain introduced during a migration. Broken redirects deserve particular attention after any URL change, and we walk through how to get them right in our guide to website redirects.
The tell for a technical cause is that the drop is uneven. Algorithmic changes tend to move a whole site or a whole content type. A technical fault usually kills a specific set of URLs completely while leaving everything else untouched.
Both are possible and both take under a minute to check. Search Console has a Manual Actions report and a Security Issues report, and the Google guidance on traffic drops tells you to look at both. If either shows something, that is your answer and nothing else needs investigating.
Manual actions are rare on normal business sites, because they involve human review at Google after its automated systems flag something. If you have never bought links or published spun content, you will almost certainly see a clean report here.
Security issues are less rare than people think. A compromised site serving injected pages or redirects can lose traffic sharply, and the site owner often has no idea because the injected content is only shown to search engines or to visitors arriving from search.
Check these two reports first every single time, precisely because they are so quick. Spending a day on content analysis when a hack notice was sitting in Search Console the whole time is a bad afternoon.
Very possibly. The Google documentation on this includes a section on seasonality and changing interests, and uses food queries as its example. People search for diets in January, turkey in November, and champagne in December. If your business sits in a seasonal category, your traffic is supposed to move.
The test is the year over year comparison, not the month over month one. Set Search Console to compare the same period last year and see whether this shape has happened before. A drop that repeats annually is a pattern, not a problem.
Google also distinguishes seasonality from changing interests, which is the slower and more serious version. Seasonality comes back. Declining interest in your category does not, and no amount of on page work fixes a query that people have simply stopped typing.
Check the trend for your main queries as well as your own traffic. If demand for the term fell and your share of it held steady, you have a market problem rather than an SEO problem, and the response is different.
Then your rankings are probably fine and something changed about the results page. This is the pattern we see most often now, and it is the one that confuses people the most, because every traditional diagnostic comes back clean while the traffic keeps sliding.
Search Console reports impressions and clicks separately for a reason. Steady impressions with falling clicks means you are still appearing and people are not clicking through. AI Overviews, expanded featured snippets, and richer result layouts all push organic links further down and answer more questions before anyone leaves the results page.
The response here is not to rewrite for rankings you already have. It is to make the result itself more clickable, and to accept that some share of these queries now get answered without a visit. We took a fuller position on this in our piece on building a zero click search strategy.
Segment the report before you conclude anything. Often a handful of informational queries lose their clicks entirely while commercial queries hold steady, and that mix tells you exactly which pages to stop worrying about.
Wait until the update has finished rolling out and then give it a few weeks. The Google guidance is explicit that you will likely want to wait a few weeks before analysing your site in Search Console again, because the data needs time to settle before it means anything.
This is the hardest advice to follow and the most valuable. The pressure to act during a drop is enormous, and acting during a rollout means you cannot tell whether any later recovery came from your changes or from the update finishing.
Use the waiting time for diagnosis rather than for edits. Document which pages and which queries moved, check the five causes properly, and build the list of what you would change. Then execute once, on evidence, instead of three times on instinct.
The exception is anything clearly broken. If you find a noindex tag, a hacked page, or a redirect loop, fix it immediately. Waiting applies to strategy, not to faults.
Open Search Console and do four things in order. Check the Manual Actions and Security Issues reports, set the Performance report to 16 months and look at the shape, compare your drop date against the Google Search Status Dashboard, and split impressions from clicks. That sequence identifies the cause in most cases.
Write down what you find before you touch the site. A drop with a named cause is a manageable problem. A drop that gets responded to with a dozen simultaneous changes becomes permanently undiagnosable, because you can never work out which change did what.
If you have been through all of this and the numbers still do not add up, we are happy to take a look with fresh eyes. Get in touch at phoenix.studio and we can work through your data together.
Tell us where you want to go. We'll tell you how we'd get you there.