WP Engine Visitor Counting: Why Your Bill Is Higher Than Google Analytics

How WP Engine counts visits (official definition)

From WP Engine's own support documentation:

A billable visit is one unique IP address logged per day (UTC).

That means:

• The same IP visiting 50 pages in one day counts as 1 visit
• The same person visiting from two different networks (home WiFi and mobile data) counts as 2 visits
• An entire office behind one shared IP counts as 1 visit
• A visitor who bounces in 2 seconds counts the same as one who reads for an hour

Tracking comes from raw server logs, not JavaScript. WP Engine does not need a tracking script to load, a cookie to be set, or a browser to execute anything. If the server sees a request from an IP that produces a response code other than 403, it counts.

What's excluded: static asset requests (images, CSS, JS files), known bot user agents, suspected non-human traffic (since September 2025), and requests that return 403 Forbidden.

Why the number is always higher than Google Analytics

Google Analytics and WP Engine are measuring different things for different reasons. GA tracks marketing-relevant human behavior using client-side JavaScript. WP Engine tracks server resource consumption using server-side logs. The gap isn't a bug in either system. It's structural.

The specific traffic WP Engine catches that GA misses:

• No-JavaScript visitors. Ad blockers, privacy browsers, and script-disabled setups never fire GA's tracking script. They're invisible to GA but visible to the server.
• Quick bounces. A visitor who clicks away before the page finishes loading won't trigger GA (the script hasn't executed), but the server logged the IP.
• Multi-network visitors. One person visiting from their phone (mobile IP) and laptop (home WiFi) creates two unique IPs on WP Engine but typically one user in GA (via cookies).
• RSS readers and pre-fetchers. Apps and browsers that pre-fetch pages generate server requests without running JavaScript.

None of these categories are fake traffic. They're real requests that consume server resources. WP Engine's position, stated in their docs, is that they track resource consumption, not marketing metrics. The problem isn't that the counting is wrong. It's that the plan limits are marketed in "visits" without clarifying that their definition of a visit produces a substantially larger number than the analytics tool most customers use to estimate their traffic.

The wp-login.php problem

Beyond the methodological gap, there's a more concrete issue: WordPress login pages attract automated traffic. Brute-force bots hit wp-login.php and xmlrpc.php constantly, often from thousands of different IP addresses. Independent analysis of managed WordPress sites has documented 25,000+ monthly requests to wp-login.php alone from varied IPs with no referrer data, which is a clear automated pattern.

Whether these get counted as billable visits depends on WP Engine's bot detection. Their September 2025 update (below) improved filtering, but bot operators continually rotate IPs and user agents to avoid detection. The gray area: a brute-force attempt from a residential IP with a standard Chrome user agent looks indistinguishable from a real visitor in server logs.

This matters because wp-login.php traffic scales with your site's visibility, not your actual audience. A site with 10,000 real monthly visitors can easily receive 5,000-15,000 monthly login-page bot hits from unique IPs. If even a fraction of those pass the bot filter, your billable count climbs.

The September 2025 bot filtering update

Credit where it's due: in September 2025, WP Engine updated their counting to exclude "requests appearing non-human." This is a real improvement over the previous system, which only filtered known bot user agents (a narrow list that missed most automated traffic).

The details of the new filter aren't public, so it's hard to assess how much of the previous 20-50% gap it closes. If you're evaluating WP Engine now, the gap may be smaller than older reviews suggest. But the fundamental methodology difference (server-log IP counting vs JavaScript session tracking) remains, and some discrepancy will always exist by design.

If you're already on WP Engine, compare your portal's visit count to your GA sessions for the same period. The ratio tells you how much the gap affects your specific site.

No auto-alerts: the billing design problem

The counting methodology becomes a billing problem because of one design choice: WP Engine does not send automatic notifications when you approach your visit limit. Overages are charged monthly in arrears at $2 per 1,000 excess visits.

The combination is rough:

1. Your plan says 25,000 visits
2. You check Google Analytics, which shows 22,000. Comfortable.
3. WP Engine's server logs counted 30,000 (the 20-50% gap)
4. No alert was sent when you crossed 25,000
5. End of month: $10 overage charge on your bill

$10 isn't catastrophic, but the pattern compounds. A site that consistently runs 40% above its GA-estimated traffic gets hit every month. One documented case from a review: a customer on a $250/mo plan received a $188 overage charge in a single month despite Google Analytics showing traffic within plan limits.

WP Engine's recommendation: check your usage through the WP Engine portal (not Google Analytics) and do it weekly. That's practical advice, but it places the monitoring burden on the customer for a discrepancy that originates in the host's counting methodology.

How to reduce your counted visits

Four approaches, in order of impact:

1. Block wp-login.php brute-force traffic. Use a plugin like Limit Login Attempts Reloaded or add .htaccess rules to block repeated failed login IPs. This can cut thousands of counted visits per month. WP Engine returns 403 for blocked requests, and 403s are excluded from billing.
2. Use Cloudflare or a DNS-level firewall. Traffic filtered before it reaches WP Engine's servers doesn't hit their logs at all. WP Engine themselves recommend this for visit-count alignment. A free Cloudflare plan handles most bot traffic.
3. Set up WP Engine access rules. Return 403 for known bad paths (xmlrpc.php if you don't use it, common exploit URLs). Every 403 is a visit that doesn't count.
4. Monitor in the WP Engine portal, not GA. Check weekly, not monthly. Catching a spike early lets you investigate the source before the overage compounds across the full billing period.

These measures reduce the gap but won't eliminate it. The structural difference (server logs vs JavaScript tracking) means WP Engine will always count more visits than GA for the same traffic. Budget for a 15-30% buffer above your GA sessions when choosing a WP Engine plan tier.

FAQ