Google Analytics vs Server Logs: Why the Numbers Never Match

Most website owners are familiar with one source of traffic data: Google Analytics, or something like it. It’s where you go to understand how your site is performing. But it’s not the only place that data lives, and it doesn’t see everything. Understanding what the other sources are – and what each one is actually measuring – is what lets you ask the right question when something looks off.

What each source is for

Client-side analytics

What it is: a JavaScript tag that fires in the visitor’s browser each time a page loads, and sends that data back to your analytics platform. Google Analytics is the most common example, but the same principle applies to any tool in this category.

What it is for: understanding how real humans are using your site. Sessions, behaviour, conversions, campaign performance. This is your primary tool for anything marketing or experience related.

What it is not for: measuring total request volume. Client-side analytics only sees what the browser executes. Bots, crawlers, blocked scripts, and failed requests are invisible to it. That increasingly includes AI agents visiting your site on your customers’ behalf, not just search crawlers.

What to use instead for total request volume: server logs.

Server logs

What they are: a record of every request that reached your web server. Every page, every asset, every bot, every error, every timestamp. Bear in mind this only covers what the CDN didn’t handle first.

What they are for: diagnosing incidents. Something broke, you need to know exactly what happened and when. Server logs have the unfiltered record of everything that hit the server directly.

What they are not for: measuring total traffic. They won’t capture requests served from the CDN, and the raw numbers that are there include bots, crawlers, and asset requests that have nothing to do with human visits.

What to use instead for total traffic: CDN logs. For human behaviour: client-side analytics.

CDN logs

What they are: the CDN’s own record of every request handled at the edge, before it ever reaches your server.

What they are for: understanding total request volume at the network level, geographic distribution of visitors, and diagnosing caching issues. If you want to know why users in a particular region are seeing stale content, this is where you look. If you’re not across: this post covers how CDN caching works.

What they are not for: behavioural analytics. CDN logs tell you a request was made and served. They don’t tell you what the visitor did next.

What to use instead for behaviour: client-side analytics.

Application logs

What they are: a record of what your software did internally in response to requests. Database queries, background jobs, errors thrown, API calls made.

What they are for: debugging. We’re deep into the lower decks of the ship now. If your developer is in the application logs, they’re not counting visitors. They’re tracing what the code did and why something went wrong.

What they are not for: anything traffic or analytics related.

The number that matters depends on the question

None of these sources is the whole truth. They’re each a partial view, built for a specific purpose.

• Client-side analytics is your day-to-day lens on how real people are using your site.
• Server logs are your incident record, the unfiltered timestamped history of everything that hit your server.
• CDN logs capture the layer of traffic that never reaches your server at all.
• Application logs tell you what the software did internally, which is a different question to how many people visited.

When someone quotes you a traffic number, it’s worth asking where it came from. Not to be difficult, but because “traffic is down” means something different depending on which source you’re looking at, and the right response depends on knowing which one.

If your client-side analytics looks odd, check whether a recent deployment might have affected caching. If server logs look low, remember the CDN is absorbing a share. If your developer is in the application logs, they’re not answering a traffic question – they’re tracing what the code did.

The sources don’t compete. They stack.