cPanel AWStats vs Webalizer: Why Your Visitor Stats Don't Match
You check AWStats and it says 4,200 visitors this month. You open Webalizer for the same domain and it says 1,800. Google Analytics, sitting on the same site, says 900. None of them are lying to you - they're just counting completely different things. Here's what each cPanel stats tool actually measures, why the numbers never line up, and which one to trust when a client asks "how much traffic did we get?"
Symptom: three tools, three different traffic numbers
Log into cPanel → Metrics and you'll usually see three or four options sitting side by side: AWStats, Webalizer, sometimes Analog, plus a raw access log viewer. Click through each one for the same domain and the same month, and the "visitor" counts rarely match - sometimes they're off by 2-3x. If you're also running Google Analytics or a Cloudflare dashboard, add a fourth number to the pile.
This throws people off constantly, especially when a client is trying to report traffic numbers to their own boss or a marketing agency. The instinct is to assume one tool is broken. Usually none of them are.
Cause: they're not measuring the same thing
AWStats, Webalizer, and Analog all work the same basic way: they parse your Apache/Nginx access_log file after the fact and count requests. Google Analytics and most CDN dashboards work differently - they run JavaScript in the visitor's browser or watch live edge traffic. That difference alone explains most of the gap.
| Tool | Data source | Counts bots? | Best for |
|---|---|---|---|
| AWStats | Parses raw access logs, updates on a schedule | Filters known bots via regex list, but list gets stale | Bandwidth breakdown, referrers, file types, crawler activity |
| Webalizer | Parses raw access logs, rebuilds each run | Weaker bot filtering than AWStats | Quick daily/hourly hit graphs |
| Analog | Parses raw access logs, static report generator | No real bot filtering | Legacy setups only - largely unmaintained since 2004 |
| Google Analytics / GA4 | JavaScript beacon fired in the browser | Mostly excludes bots (no JS execution) | Real human sessions, conversions, behavior |
A few concrete reasons the numbers diverge:
- Bots inflate the log-based tools. Every crawler, uptime monitor, security scanner, and RSS reader that hits your server shows up in the access log. AWStats tries to filter these with a bot signature list in
awstats.conf, but that list needs updating - new bots ship every month and old ones fake normal user-agents. - Cached pages never hit the log. If a page is served from LiteSpeed Cache, Varnish, or Cloudflare's edge, the origin server's access log never sees that request - so AWStats and Webalizer undercount real visits that were served from cache. Meanwhile Google Analytics still fires because the JS loads in the visitor's browser regardless of caching.
- "Visits" is defined differently per tool. AWStats counts a "visit" as requests from one IP with no gap longer than a configurable timeout (default 30 minutes). Webalizer uses a similar but not identical window. GA4 uses its own session model based on engagement time and events. Change the definition, change the number - same raw traffic.
- Ad blockers and privacy settings kill GA, not the log tools. A meaningful share of real visitors block Google Analytics outright. Those hits still land in the server log, so the two systems will never converge - GA typically under-reports real visits, log-based tools typically over-report them once you factor in bots.
- Stale or rotated logs mean stale reports. AWStats and Webalizer both build their totals incrementally from the current log file. If logrotate has already compressed and archived part of the month before the stats tool ran, and it isn't configured to read the rotated archive, you get a partial month that looks like a traffic drop.
Fix: get each tool reading cleanly, and pick one source of truth
1. Make sure the stats tool is actually enabled for the domain
In cPanel, go to Metrics → Awstats (or Webalizer/Analog) and confirm the domain is listed with a green "view" link, not greyed out. On some configurations these have to be turned on per-domain by your host - if a domain was added after the account was provisioned, its stats module sometimes isn't enabled yet. Ask your host to confirm awstats is active for that specific domain in WHM if you don't see data at all.
2. Force an AWStats update instead of waiting for cron
AWStats normally updates once a day via a system cron job, which is why "today's" numbers often look empty until the next run. To force a fresh parse over SSH:
cd /usr/local/cpanel/3rdparty/bin
./perl awstats.pl -config=yourdomain.com -updateIf you don't have shell access, most WHM setups also expose Run AWStats under cPanel → Metrics → Awstats → Update Now for the account owner, or your host can trigger it from WHM.
3. Point the tool at rotated logs, not just the live file
Check how logs are archived for the account:
ls -la ~/access-logs/
# yourdomain.com <- current, unrotated
# yourdomain.com-Jul-2026.gz <- archived by logrotateAWStats' config (/etc/awstats/awstats.yourdomain.com.conf) needs LogFile pointing at the right source, and if you archive logs before AWStats processes them, you need LogFile to reference the compressed archive with a decompression command, e.g. "gunzip -c /home/user/access-logs/yourdomain.com-%YYYY%-%MM%.gz |". Without this, a full month never gets counted once it rotates out of the live log.
4. Refresh the bot-exclusion list periodically
AWStats ships with a built-in SkipHosts / SkipUserAgents filter, but it goes stale. Add known noisy bots and internal monitors explicitly in awstats.conf:
SkipUserAgents="UptimeRobot Pingdom BLEXBot SemrushBot AhrefsBot MJ12bot"Re-run the update after editing the config so the exclusion takes effect on the next parse.
5. Decide which number the client actually needs
For SEO/marketing reporting - real people, real sessions, conversion tracking - Google Analytics (or a privacy-friendly alternative like Plausible/Fathom) is the right source, not AWStats. For server-side questions - "what's eating my bandwidth," "which crawler is hammering us," "did that DDoS-shaped spike come from one IP" - AWStats and raw log analysis are the right tool, because they see every request regardless of ad blockers or cache hits. Stop trying to reconcile the two; they answer different questions.
Prevention: keep one tool trustworthy instead of running three loosely
- Pick AWStats as your log-based tool and disable Webalizer/Analog if you don't need them - one less number to explain, and it's the most actively maintained of the three.
- Schedule a mid-month manual AWStats update if your traffic reporting deadline falls before the daily cron typically runs.
- Review and extend the bot-exclusion list every few months, especially after seeing a sudden "traffic spike" that doesn't match any real campaign.
- If you're behind Cloudflare or a caching layer, use its analytics dashboard for edge-level traffic and reserve AWStats for origin-server diagnostics.
- Document which tool is "official" for client reporting so nobody re-litigates the discrepancy every month.
FAQ
Frequently asked questions
Which cPanel stats tool is the most accurate?
None of them are "accurate" for real human traffic on their own - they all count server-log hits, which includes bots and misses cached requests. AWStats is the most actively maintained and has the best bot filtering of the three, so it's the best default if you need a log-based number. For real visitor counts, use Google Analytics or a JS-based alternative instead.
Why does AWStats show 0 visitors for today?
AWStats usually updates once a day via a scheduled cron job, not in real time. If you're checking before that job has run, today's data simply hasn't been parsed yet. Force an update manually with awstats.pl -update over SSH, or use the "Update Now" option in cPanel's Awstats page.
Can I delete old AWStats data to reset the counts?
Yes, but do it carefully. AWStats stores its historical data in per-month database files under /var/lib/awstats (or a similar path depending on your OS). Removing the file for a specific month forces a full re-parse from the log archive next time it updates - useful if a config change (like a new bot filter) needs to apply retroactively, but you'll lose any log data that's already been rotated and deleted.
Why do Webalizer and AWStats disagree even for the same month?
They use different session-timeout windows to define a "visit," different bot-detection rules, and sometimes read the log files at different points in the rotation cycle. Treat both as directional, not exact, and don't expect them to match down to the visitor.
Should I just turn off AWStats and Webalizer and rely on Google Analytics?
For marketing and traffic reporting, yes - GA (or a privacy-first alternative) is the better source. Keep AWStats enabled anyway; it's the fastest way to see raw request patterns, referrers, and bot activity when you're diagnosing a bandwidth spike or a suspicious traffic surge, since it doesn't rely on JavaScript executing in a browser.