LotsBlogYou opened Search Console on a Tuesday, clicked last month's view, and the chart looked broken. Impressions halved. Average position flat. Clicks about the same. The operator instinct is panic, then blame — a core update, a site issue, a content problem. But this time it might not be your fault at all.
Google confirmed on April 3, 2026 that a logging error had been inflating Search Console impression counts since May 13, 2025 — nearly 50 weeks of overreported data (Search Engine Land, April 3, 2026). The fix started rolling out in late April 2026. If your numbers dropped between April 20 and April 21, that was the correction, not a traffic collapse.
This piece walks through exactly what changed, why your YoY reports are now misleading, and how to rebuild a clean baseline in under 30 minutes — so you can stop staring at the broken chart and get back to running the blog.
What actually changed
Here is the timeline so you can match it against your own data.
- May 13, 2025 — The logging error begins. Google starts overcounting impressions due to a bug in how the logging system recorded search appearances. Nobody notices yet because the overcount is consistent enough to blend into normal noise.
- March 30, 2026 — Brodie Clark, independent SEO consultant, flags unusual impression spikes across merchant listings and organics (Search Engine Journal, April 10, 2026).
- April 3, 2026 — Google confirms the bug publicly. A Google spokesperson tells Search Engine Land: "We identified a logging error that has prevented us from accurately reporting on impressions. The fix has been deployed and will roll out over the coming weeks."
- April 12, 2026 — Brodie Clark documents that impressions are now declining sharply as the fix begins propagating, particularly when using the Images search appearance filter (LinkedIn, April 12, 2026).
- April 20–21, 2026 — The most visible drop. A Google support thread fills with operators reporting the same pattern: impressions halved overnight, clicks stable (Google Support Thread).
- Late April 2026 — The fix completes for forward-looking data. But the historical data from May 13, 2025 to April 27, 2026 remains inflated, with no retroactive correction.
The core problem: the data between May 2025 and April 2026 cannot be trusted for impression counts. Clicks, position, and CTR were not affected by the logging error.
Why your YoY reports look wrong
Year-over-year comparisons are the most commonly broken report right now.
Here is why. If you compare June 2026 impressions to June 2025 impressions, you are comparing corrected data against inflated data. The 2025 side of the equation was overstated — sometimes by a significant margin depending on the query type and search appearance filter. The drop you see in the YoY chart is mostly the correction catching up, not your site losing ground.
The same applies to any report that compares a post-March-2026 window to a pre-April-2026 window. The delta is an artifact of the bug, not a real performance decline.
One operator on the Google support thread noted their impressions went from roughly 2 million to 900,000 after the fix. Clicks stayed flat. The shape of that report — impressions down, clicks steady — is the signature of the bug correction, not a traffic problem.
How to re-baseline your numbers in 30 minutes
You need a clean before-and-after that excludes the affected window. Here is the workflow.
1. Define the clean windows.
Pull two date ranges:
- Pre-bug baseline: January 1, 2025 to May 12, 2025 (the period before the logging error started)
- Post-fix baseline: May 1, 2026 to today (the period after the correction completed)
If your archive did not exist in early 2025, use the post-fix window alone and treat it as your new baseline going forward.
2. Normalize like-for-like.
Compare the same number of days. A 30-day window in the pre-bug period against a 30-day window in the post-fix period. Do not compare a single month against a single month unless you control for the same days of the week.
3. Stop reading single-month deltas.
Until you have 3+ months of clean post-fix data, any single month comparison is noise. Use 90-day rolling averages instead.
4. Report clicks and position, not impressions.
For client reporting, internal dashboards, and personal benchmarks: click data was not affected by the bug. Position data was not affected either. These are the trustworthy signals until the impression data has 90 days of clean history.
What to look at instead
While the impression data settles, shift your attention to the metrics the bug did not touch.
- Average position. If your posts are holding position or improving, your content is fine. Position was accurately logged through the entire affected window.
- Click-through rate over 90 days. A stable or improving CTR means the title and meta description are working. A dropping CTR means the answer-first paragraph or title needs a refresh — same as always, no bug required.
- Indexed pages. The number of indexed URLs in GSC was not affected. If that number is steady, Google is still crawling and surfacing your archive.
- Organic traffic in Analytics. Google Analytics (or any server-side analytics) was not affected by the Search Console logging bug. Compare your GA sessions to Search Console clicks to validate whether the impression drop is real or a reporting artifact.
Run these metrics through a 30-minute blog audit and you will have a clearer picture of your archive health than any impression chart right now.
What this means for the refresh loop
If you run a content refresh workflow, the bug changes which posts you should prioritize.
- Ignore posts whose only decay signal is an impression drop between April 20 and May 1. That drop is the correction, not a real decay signal.
- Prioritize posts with position drift or CTR decay over the same period. Those signals are real. If a post was ranking #8 in February and is ranking #12 in June, that is a real decline.
- Re-baseline your refresh triggers. Update your Search Console dashboard to use the post-fix window as the new reference point. A post that seemed to lose 50% of impressions in April probably did not — it was inflated before.
The 4-step operator refresh workflow is still the right system for bringing posts back. The only change is which posts you feed into Step 1.
Where the agent fits
A blog operating system that tracks Search Console signals needs to know which signals are trustworthy and which are noise right now. The agent should flag posts using position and CTR as the primary signals — not raw impressions — until the impression data settles.
In LotsBlog, the system already reads your archive state and surfaces the next post to refresh. During the post-bug window, the right move is to let the operator review which candidates entered the queue based on impression signals before April 2026 and re-score them against the new baseline. The operator's playbook for writing an article that compounds covers how the agent fits into that loop end to end.
FAQ
Is my traffic really down?
Probably not. If clicks are stable in Search Console and sessions are stable in Google Analytics, your traffic is fine. The impression drop is a data correction, not a real loss. Check clicks and position instead of impressions for the next 90 days.
How long until the numbers settle?
The forward-looking fix was complete by late April 2026. But Google has not retroactively corrected the historical data from May 2025 to April 2026. You will need 90 days of clean post-fix data — roughly through late July 2026 — before month-over-month impression comparisons become reliable again.
What should I report to stakeholders right now?
Report clicks and position. Do not report YoY impression comparisons unless you clearly annotate that the 2025 window contains inflated data. If you must report impressions, use the post-fix window only and label it clearly: "Data from May 2026 onward (post-Google bug correction)."
Numbers you cannot trust break the loop. A system that surfaces the trustworthy signals — position, CTR, clicks — and queues the next post based on real decay keeps you shipping while the charts settle. Run the 30-minute re-baseline above, then pick the next post from the clean signal.