Technical SEO Triage After a Sudden Traffic Drop

Traffic was healthy on Monday. By Friday it is down 40%. This article is not about long-term technical SEO hygiene — it is about the specific triage sequence to run when something has clearly broken and you need to find the cause in hours, not weeks. The order matters because each step rules out a category of cause, and getting the order wrong wastes time chasing the wrong hypothesis.

Step one: confirm the drop is real

Before anything technical, rule out measurement noise. Check Search Console against Google Analytics — do both show the same drop on the same day? If only one shows it, the problem is in tracking, not in the site. Check whether the drop is concentrated in one country, one device type, one browser, one referring source. A 40% drop that is actually a 100% drop in Safari mobile traffic is a very different incident from a uniform sitewide drop.

Step two: check for indexing changes

Open the Coverage report. Has the count of valid indexed pages changed? Has it changed sharply? If you used to have 10,000 indexed pages and you now have 6,000, the cause is almost certainly a recent deploy that introduced noindex tags, blocked crawling in robots.txt, or broke canonicals. Look at the deploy log for the past week and find the change that correlates with the dropped pages.

Step three: check for ranking changes vs impression changes

In Search Console, compare the last 28 days to the previous 28. Is the issue that your existing rankings dropped, or that your impressions dropped while rankings stayed the same? Dropped rankings point to algorithmic causes (core updates, helpful-content updates, manual actions) or content quality. Dropped impressions with stable rankings point to seasonal or external causes (a competitor launched a feature, a seasonal pattern, a paid-search shift).

Step four: check the technical fundamentals

If steps two and three rule out indexing and ranking-position changes, the issue is something subtler. Check page speed — a deploy that added 2 seconds of JavaScript can quietly tank rankings. Check Core Web Vitals — they trail by 28 days so a regression last month might be showing up now. Check internal linking — a sitemap change can shuffle which pages get crawl priority.

Step five: rule out manual actions

Open the Manual Actions and Security Issues sections in Search Console. Both are checked in seconds and either rules out or confirms a very specific category of cause. If you have a manual action, the triage stops and you move into the manual-action recovery process, which is its own playbook.

Step six: scope the recovery

Once you have a probable cause, the question becomes how much of the drop is recoverable and how fast. Indexing issues fixed today usually recover within two weeks. Content quality issues that triggered an algorithmic adjustment recover at the next refresh of that algorithm — sometimes months. Manual actions recover after you submit a reconsideration request and Google reviews it. Set expectations with stakeholders accordingly.

What not to do

Do not start "fixing things" before you have a hypothesis. Random fixes during an incident often make things worse — you noindex pages you should have left alone, you redirect URLs you needed standalone, you change schemas that were working. Triage first, fix second. The temptation to be seen doing something is the biggest cause of incident overreach.

Tools that help during triage

A continuous site auditor gives you a timeline view of when issues appeared, which is the single most useful piece of information during triage. If you can see that indexable-page count dropped by 4,000 on the same day as a particular deploy, you have your culprit in minutes rather than days. UtilitySEO and equivalent tools all support this kind of historical view.

The goal during a traffic incident is not perfection — it is a defensible explanation of what happened and a defensible plan for recovery. Triage gets you both.