Log file analytics
Log file analytics analyzes server access logs — every request the server received — instead of relying on a browser script. It captures all requests, including bots and non-JavaScript clients, which makes it strong for crawl and bot analysis. Its blind spots are browser-only signals and client-side interactions. Tools like AWStats and GoAccess process these logs.
What this means
Every request a web server handles is recorded in an access log with details like path, status code, user agent, and timestamp. Log file analytics parses these logs to report traffic, status codes, referrers, and crawler activity.
Because logs capture all requests, they see things a browser script cannot — bots, non-JS clients, and failed requests.
Strengths and blind spots
Logs excel at completeness and at crawl/bot analysis, since every hit including non-rendering clients is present. The blind spots are browser-only signals (viewport, client-side events) and the fact that one human can generate many requests, so deriving 'visitors' needs care.
- Captures all requests, including bots and non-JS clients
- Strong for crawl and status-code analysis
- Misses browser-only signals and client-side events
Where it fits
Use log analytics for technical and crawl visibility, often alongside a script-based tool that adds engagement context. Tools such as AWStats and GoAccess process logs into reports; treat the raw logs as sensitive data with retention and anonymization policies.
How it appears in analytics and logs
Log-based counts include every request the server logged, so they capture bots and non-JS clients that a browser script misses — differences from script-based tools are expected.
Diagnostic use case
Consider log file analytics for complete request-level visibility, crawl and bot analysis, or when a browser script cannot be relied upon.
What WebmasterID can help detect
WebmasterID's bot intelligence relies on server-side request context similar to logs; this page explains log-based measurement even-handedly.
Common mistakes
- Reading raw request counts as visitor counts.
- Forgetting logs contain sensitive data needing retention rules.
- Expecting browser-only engagement signals from logs.
Privacy and accuracy notes
Server logs can contain IP addresses and user agents; treat them as sensitive, apply retention and anonymization, and keep geo coarse. This is educational, not legal advice.
Related pages
- Server-side vs client-side analytics collection
Analytics can be collected client-side (a browser script fires events) or server-side (the server or a server endpoint records them). The two see different things: client-side captures rich browser context but misses no-JavaScript clients and is affected by blockers, while server-side sees every request but lacks some browser-only signals. Many setups combine them.
- Bot traffic in analytics: filtering it out
Bots — crawlers, scrapers, monitors, scanners — generate requests that, unfiltered, inflate pageviews and distort every metric. Client-side analytics often misses bots (many do not run JavaScript) or miscounts the ones that do. Server-side classification at ingest is the reliable way to keep bot traffic out of human reports.
- Matomo: open-source, self-hostable analytics
Matomo (formerly Piwik) is an open-source web analytics platform that can be self-hosted on your own server or used as a hosted cloud service. Self-hosting means the visitor data lives in your own database rather than a vendor's. It offers a session/visit-based model with familiar reports plus optional add-ons, and configurable options such as cookieless tracking and IP anonymization.
- Bot intelligence
Classify bot and crawler traffic.
Sources and verification notes
- MDN — HTTP request methods and server logs contextBackground on requests that servers log.
- GoAccess — log analyzer documentation
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.