Aggregate charts summarize. The log proves.
Every request that reaches your WordPress site becomes one honest row: URL, user agent, exact time, and classification. When you need to know what actually happened - not what a chart smoothed over - this is where you look.
Sampling is a summary. A log is evidence.
JavaScript analytics compresses visits into sessions, samples heavy traffic, and drops everything that never ran a script. A server-side log inverts that: nothing is inferred, nothing is sampled, and the machines that make up a huge share of modern traffic appear as plainly as the humans. The difference sounds academic until the day you need to answer a specific question about a specific visit.
Every URL
Not a sample, not a session rollup - the actual path each visitor requested, including the feed endpoints, old posts, and paginated archives that dashboards usually hide.
Every user agent
The full user-agent string as it arrived, next to the classification Viz assigned it. When something looks off, you can read the raw evidence yourself.
Exact time
Request-level timestamps, so you can reconstruct the order of events: crawl first, spike second, or the other way around.
Classification
One of 8 categories on every row - human, AI training, AI search, AI user agent, autonomous agent, search engine, traditional bot, or unknown.
Questions a dashboard can't answer. A log can.
The dashboard tells you AI traffic rose 40% this week. The log tells you which bot, which pages, in what order, and whether it came back after you said no.
Explain a traffic spike
Filter to the spike window and read what actually happened. A hundred requests a minute from one AI training crawler looks completely different from a hundred humans arriving via a link - and your response should differ too.
Confirm a block held
After blocking a bot in AI Control, filter the log to that bot. You should see requests continuing to arrive and being refused - logged first, then denied with a 403. If the requests stop entirely, robots.txt did its job.
Spot a scraper by cadence
Humans browse in bursts and follow links. Scrapers walk your archive in order, at machine-regular intervals, often from one user agent. That pattern is invisible in aggregate charts and obvious in a request log.
Noise is part of the truth.
A real server log is messier than an analytics dashboard, because the web is messier than dashboards admit.
Unknown stays unknown
Requests Viz can't identify with confidence are labeled Unknown, not guessed into a category. Watching the size of that bucket over time is itself a signal: a growing Unknown share often means a new crawler has found you before it has been catalogued.
The boring bots count too
Uptime monitors, feed readers, and link checkers are logged as traditional bots. They are harmless, but seeing them separated out is what makes the human number believable - a count is only as trustworthy as what was excluded from it.
Retention is your call
Everything lands in your own database, so retention is a setting, not a plan tier. Keep a short window on a busy site or a long archive on a quiet one - and prune whenever you choose.
How long to keep the evidence is an editorial decision.
Because the log lives in your database, retention is a policy you set rather than a plan tier you buy - and the right policy follows from what you use the log for. Investigations need days: explaining a spike or confirming a block rarely reaches past the last two weeks. Negotiations need months: if the crawl record is your inventory of what AI operators took, a longer window is what makes the numbers credible. A busy store might keep thirty days of everything; a publisher building a licensing case might keep bot traffic long after human rows have been pruned.
The useful mental model: aggregates are cheap and rows are evidence. Dashboards stay meaningful over long ranges either way; what expires with retention is the ability to produce the specific row - this bot, this URL, this timestamp - and rows are what stand up in a dispute. Decide which questions you want to be able to answer in six months, and set the window to match.
Request log FAQ.
How is this different from my hosting access log?
An access log is a raw text file: no classification, no filtering UI, and on many managed WordPress hosts you cannot even read it. The Viz request log lives in wp-admin, is filterable by category, bot, and time, and every row arrives already classified.
What does the Unknown category actually contain?
Anything Viz cannot identify with confidence: new bots that have not been catalogued yet, scripts with custom user agents, and clients that send misleading strings. Viz keeps them visible as Unknown rather than silently guessing, because an honest unknown is more useful than a confident mislabel.
Will logging every request fill up my database?
You control the retention window, and old rows are pruned automatically. Everything is stored in your own WordPress database, so the trade-off between history and disk space is yours to set - there is no external service deciding for you.
Can bots fake their user agent and get misclassified?
Yes - any client can misrepresent itself, and no analytics tool can fully prevent that. In practice the major AI operators identify themselves honestly because they want robots.txt to apply to them. A bot in disguise shows up as unusual Unknown or human-labeled traffic with bot-like cadence, which is exactly the pattern the request log makes visible.
I just installed Viz. What should I look at in the log first?
Three filters, in order. First, AI training crawlers sorted by URL: that is your archive being read, and it tells you what the models want from you. Second, the Unknown category: scan the raw user agents for anything arriving at volume. Third, pick your single most valuable page and view its full history - seeing every machine that touched one important URL is the fastest way to build intuition for what the aggregate charts are summarizing.