What should I check when traffic suddenly drops?

A consent banner change, a tag manager edit, or an analytics script that stopped loading will show as a traffic collapse while nothing about the site changed.

Compare against a source that does not depend on your analytics: server logs, Search Console impressions and clicks, or revenue.

A drop in one source and not the others is a measurement problem. A drop in all of them is real.

Check the date the drop started against your own deployment history. The two matching is the strongest signal you will get all day.

Also check whether the drop is an aggregate artefact: a single high-traffic page removed from a report filter looks identical to a site-wide decline.

Request the site from outside your own network. A firewall rule or a DNS change can leave it working perfectly for you and unreachable for everyone else.

Check the certificate has not expired. An expired certificate produces a full-page browser warning, and almost nobody clicks past it.

Check all four host and scheme combinations, since a broken redirect on one of them removes a share of traffic without affecting the rest.

Check response times. A site that went from fast to very slow loses visitors before they arrive, and it also causes search engines to reduce their crawl rate.

This is where a deployment accident shows up. A `noindex` promoted from staging removes pages over days, which produces exactly the shape of a sudden drop.

Check both the robots meta tag and the `X-Robots-Tag` header, on several page types rather than the home page alone.

Check robots.txt for a `Disallow: /` that was not there last week.

Check Search Console's Page indexing report for a spike in any excluded category, and compare indexed page counts against the previous month.

Check canonical tags: a template change that points every page at the home page consolidates the whole site into one URL.

Search Console's performance report separates impressions from clicks. Impressions falling means visibility changed; clicks falling with stable impressions means the result itself changed.

Compare by query and by page. A drop concentrated on a few pages is a page problem; a drop spread evenly is more likely to be site-wide or external.

Check the dates against known algorithm updates, which Google publishes. This is a plausible explanation, not a proven one, and it is frequently reached for too early.

Check for manual actions in Search Console. They are rare and they are unambiguous when present.

Seasonality is the explanation people skip. Compare against the same period last year before concluding anything.

Check whether the pages that lost traffic are still the ones being shown. A result that changed from a rich result to a plain link loses clicks without losing impressions.

A deployment that shipped a staging directive, a redirect rule, or a canonical change nobody reviewed.

A certificate that expired because automated renewal broke weeks earlier and nobody was watching.

A migration where part of the redirect map was wrong, so a section of the site 404s.

A robots.txt or firewall change that blocks crawlers while leaving visitors unaffected — the hardest version, because the site looks fine.

A CDN or DNS change that works from your office and not from elsewhere.

VeriFixScan reports `seo.noindex` and `seo.robots_txt` across the crawled pages, which covers the indexing-accident case in one pass.

`availability.status_classification` and `availability.broken_links` cover reachability and whether sections of the site have started returning errors.

`seo.canonical` reports pages whose canonical points elsewhere, which is the template accident that consolidates a site into one URL.

`transport.certificate_details` reports the certificate and its validity window.

None of this explains a ranking change. It rules out the mechanical causes, which is what has to happen before a ranking theory is worth entertaining.