Before you blame Google, make sure your numbers are real. A surprising number of "algorithm hits" turn out to be a broken analytics tag, a new cookie banner, a reporting delay or a server that went down over a weekend. These problems can wipe out a chunk of recorded traffic overnight, and because Google ships updates so often, there is usually an update nearby to blame.
This checklist helps you rule out tracking and technical problems first. It covers GA4 tagging, consent changes, Search Console reporting delays and anomalies, and site outages, with a clear order of checks so you can reach an answer quickly.
Key Takeaways
- Compare GA4 with Search Console first: if Search Console clicks are steady but GA4 organic sessions fell, the problem is probably tracking, not rankings.
- Consent banner changes can reduce what GA4 records, especially with basic consent mode, where no data is sent when users decline.
- Search Console's newest data is preliminary, and Google publishes a list of known data anomalies; check both before reacting.
- Outages, robots.txt mistakes and accidental noindex tags cause real drops that look like updates but have very different fixes.
- Write down every site, tag and consent change with dates so you can line them up against traffic charts.
Start with the two-source test
Search Console and GA4 measure different things. Search Console counts clicks from Google Search results; GA4 counts sessions that its tag recorded on your site. That difference is your first diagnostic tool.
| Search Console clicks | GA4 organic sessions | Most likely explanation |
|---|---|---|
| Stable | Down sharply | Tracking problem: tag, consent, filters or channel grouping |
| Down | Down by a similar amount | Real visibility or demand change; continue to update diagnosis |
| Down | Stable | Unusual; check Search Console anomalies and property settings |
| Gap in data, then normal | Normal | Search Console reporting delay or logging issue |
| Down | Down, plus server errors in logs | Outage or technical issue affecting crawling and users |
The full checklist, in order
- Confirm the tag still fires. Use GA4 DebugView or Tag Assistant on key templates (home, blog post, product, checkout). Check that a recent theme update, plugin change or tag manager publish did not remove or duplicate the tag. Our Google Tag Manager guide and GA4 on WordPress setup cover common breakages.
- Check consent changes. Did you install or reconfigure a cookie banner, or switch consent mode settings? See the consent section below and our explainer on Google Consent Mode v2.
- Check GA4 configuration changes. Look for new data filters, internal traffic rules, changed channel groups or a different reporting identity. Our guide to excluding internal traffic shows where filters live.
- Check Search Console freshness and anomalies. Recent days may be preliminary, and Google lists known logging issues on its data anomalies page.
- Check uptime and server errors. Review uptime monitoring, hosting status and server logs for 5xx errors or timeouts around the drop date. See website downtime and SEO.
- Check crawl and indexing. Look at the Crawl Stats report for spikes in errors or response time, and the Page indexing report for sudden exclusions. Our Crawl Stats guide explains what to look for.
- Check robots.txt and meta robots. Make sure a staging setting, plugin or deployment did not block crawling or add
noindexto live pages. - Only then compare against update dates. If everything above is clean, move on to update analysis using the Search Status Dashboard.
Consent changes and GA4
Consent settings directly affect what Google tags can record. Google's consent mode documentation distinguishes between basic and advanced implementations.
“However, when the user doesn't consent, no data is transferred to Google at all.”
— Google Tag Platform documentation (on basic consent mode), Consent mode overview
In advanced consent mode, tags send cookieless pings while consent is denied, and modelling can fill some gaps. Either way, a new banner, a stricter default or a change in how the banner is displayed can reduce recorded sessions without any change in real visitors. If the drop in GA4 started the day a consent change went live and Search Console clicks did not move, you have found your cause.
Search Console reporting delays and anomalies
Search Console data is not instant. Google's help page for the Performance report notes that the newest data can be preliminary and may change; it is shown with a dotted line on the chart. Do not compare a partial day with complete days.
“On rare occasions, there might be an event in Search Console that could affect your report data.”
— Search Console Help, Data anomalies in Search Console
Google's "Data anomalies in Search Console" page lists those events by date and report. If your dip matches a listed anomaly, the drop may exist only in the report. Our wider guide to Search Console data during updates explains other quirks to watch for, and search bugs mistaken for updates covers cases where Google Search itself had a temporary problem.
Outages and technical changes
A site that returns server errors or times out cannot be crawled or visited properly. Short outages often recover on their own; long or repeated ones can affect crawling and visibility. Google's guidance on debugging traffic drops lists technical issues, security issues and site moves as separate causes from algorithmic updates. If your drop coincides with a migration, read site migration or algorithm update? before anything else.
| Change to log | Where to find the date | Why it matters |
|---|---|---|
| Tag manager publishes | GTM version history | Tags can be removed or duplicated |
| Consent banner changes | Consent platform logs or release notes | Can reduce recorded sessions |
| Theme or plugin updates | CMS update log | Can strip tags or change robots settings |
| Deployments and migrations | Release notes, version control | Can break redirects, canonicals or noindex |
| Hosting incidents | Host status page, uptime monitor | Real outages affect users and crawling |
Common mistakes
- Looking only at GA4 and never opening Search Console.
- Comparing today's preliminary Search Console data with full days.
- Forgetting that a cookie banner change can cut recorded sessions overnight.
- Assuming a site-wide drop on one day is an update; updates usually play out over a rollout period, while tracking failures are often instant.
- Fixing content in response to a drop that was really a broken tag.
Once tracking is ruled out, use our ranking drop diagnosis guide and the algorithm updates hub to continue.
Related Guides
- How to Recover From a Google Spam Update
- Recovering From a Link Spam Update: What You Can and Can't Get Back
- How to Recover From a Google Reviews Update
Frequently Asked Questions
How do I know if a traffic drop is a tracking problem?
Compare Search Console clicks with GA4 organic sessions for the same period. If Search Console is stable and GA4 fell, the cause is most likely tracking.
Can a cookie banner reduce my GA4 traffic?
Yes. With basic consent mode no data is sent when users decline, and any change in consent settings can change how many sessions GA4 records.
Is recent Search Console data reliable?
The newest data can be preliminary and may change in the next few hours, so avoid comparing partial days with complete ones.
Where can I see known Search Console reporting problems?
Google maintains a "Data anomalies in Search Console" help page that lists known logging issues by date and report.
What should I check after ruling out tracking issues?
Check crawling, indexing, robots settings and uptime, then compare the drop with confirmed update dates on the Search Status Dashboard.
Fix the measurement, then the marketing
Clean data is the foundation of every good SEO decision. If you want a technical and analytics health check after a sudden drop, our SEO specialists can audit tags, consent and indexing together. Get a free quote to begin.
