They count different events. Google Search Console counts clicks on a result in Google Search; your analytics counts sessions that began on your site. A click is not a session, so the totals never match and were never meant to.
Should the two numbers ever line up?
No. A gap of roughly five to twenty percent is ordinary on most sites. The question worth asking is not whether the numbers agree but whether the gap is stable, because a stable gap means your measurement is consistent and a moving gap means something changed.
Chasing agreement wastes weeks. The two tools sit at different points in the same journey: one at the search result, one after the page loads and a script runs. Everything that happens between those two points is counted by one and invisible to the other.
What does each tool actually count?
Search Console counts a click on a result for a verified property. Analytics counts a session, which starts when a visitor arrives and engages, and ends after a period of inactivity.
| Dimension | Search Console | Analytics |
|---|---|---|
| Unit | Click on a search result | Session on your site |
| Measured where | Google's result page | Your page, by a script |
| Scope | Everything on the verified property | Everything your tag is installed on |
| Day boundary | Pacific Time | Your property's reporting time zone |
| Source coverage | Google Search only | Every search engine bucketed as organic |
| Completeness | Aggregated, filtered for privacy | Dependent on consent and script execution |
Read that table once and most of the discrepancies explain themselves. The last two rows do most of the work.
Track the ratio between the two numbers, not the numbers. A consistent ratio means both tools are working, and the day it moves is the day something actually broke: a tag that stopped firing, a consent banner that changed, or a redirect that started stripping the referrer.
Which gaps push Search Console higher?
Clicks that never become a measured session. The most common cause is a visitor who leaves before the analytics script executes, which Search Console already counted the moment the result was clicked.
Script blocking and consent are the next largest. A visitor who declines tracking, or who runs a blocker, is a click in one tool and nothing in the other. Slow pages make this worse in a way that compounds: the longer the page takes to become interactive, the more clicks abandon before the tag fires, so a performance problem shows up as a widening reporting gap before anyone frames it as a performance problem.
Scope accounts for the rest. A domain property reports clicks to every URL on the domain, including PDFs, feeds, and any subdomain or template where your analytics was never installed. Those clicks are real traffic that your analytics has no way to see.
Which gaps push analytics higher?
Sessions that were never a Google click. Bing, DuckDuckGo, and every other engine land in the same organic bucket in your analytics, while Search Console reports only Google Search.
Session mechanics add more. One click can produce several sessions when a visitor leaves a tab open, returns after the inactivity timeout, and is counted again. Internal navigation that loses and re-acquires the referrer does the same thing, and so does a campaign parameter that gets stripped mid-journey and leaves the next pageview looking like a fresh organic arrival.
Then there is what Search Console leaves out by design. Discover, News, and image or video results are reported separately or not at all in the default view, so a page that earns real organic search visits from those surfaces will look under-reported next to your analytics total.
Comparing a filtered Search Console view against an unfiltered analytics report. The default performance view is web results for one property and one search type; if your analytics report covers the whole domain and every engine, you are comparing two different populations and the difference tells you nothing.
How do you tell a measurement gap from a real drop?
Look at whether both tools moved. If clicks and sessions fall together, the traffic is gone. If only sessions fall while clicks hold, the page is still being chosen in the results and the loss is in your measurement or in what happens after the click.
That second case has a short list of causes: a tag removed in a release, a consent change, a new redirect hop that drops the referrer, or a page that got slow enough to lose visitors before the script ran. Check the deploy log for the day the ratio moved before you check anything else.
The opposite pattern, clicks falling while sessions hold, points at the results page rather than your site. Impressions alongside position will tell you whether you lost ranking or lost the click at a position you still hold, which is a different problem with different fixes.
What should you compare instead?
Pick one tool per question. Use Search Console for anything that happens in the results: impressions, position, which queries bring the clicks, which pages Google chose to show. Use analytics for anything that happens after the click: what people read next, what they did, and your conversion rate.
Keep one caution about impressions. They are a count of times your result was shown, not demand, and they are not search volume. Reading them as a market size estimate produces forecasts that fall apart the first time a layout change moves your result above or below the fold.
For a single number that holds across both, compare trends on the same metric from the same tool over time, never a level from one tool against a level from the other. There is more that Search Console structurally cannot tell you, covered in what Search Console cannot tell you.
Which number do you report to the client this month?
Decide now, write it into the report template, and stop switching. Search Console clicks for anything you are judged on in the results, analytics sessions for anything you are judged on after the click, and the ratio between them as your own internal check that the measurement still works. The worst option is the one most reports use, which is whichever number looks better that month.