Pageviews: what the metric counts
A pageview is recorded when a page is loaded (or a virtual page is rendered in a single-page app). It is the oldest web-analytics metric and the easiest to misread: pageviews count loads, not people, and modern apps and prefetching can inflate or hide them. This page defines the metric and its caveats.
What this means
A pageview is logged when a page loads. In a classic multi-page site that maps to a browser navigation; in a single-page application (SPA) it maps to a 'virtual pageview' the app fires on each route change. Both are valid, but they are counting render events, not people and not sessions.
How it is measured
Most tools fire a pageview from a small script on load (and on virtual navigation in SPAs). That means anything that loads the page — a prefetch, a bot that executes JavaScript, a refresh — can add a pageview. Server-side counting (from request logs) counts differently again, since it sees requests the browser script never fires for.
- Browser script: counts loads + SPA virtual navigations
- Server logs: count requests, including non-JS clients and bots
- Refreshes, prefetch, and back/forward can add or hide pageviews
Common ways it misleads
Pageviews are not visitors and not sessions — one person can generate many. Comparing pageviews across tools that define them differently (SPA virtual views vs server requests) is apples-to-oranges. And unfiltered bot traffic inflates pageviews without any human reading anything.
How it appears in analytics and logs
A pageview means a page was loaded or a route rendered. A spike can be real interest, a prefetch wave, or bot traffic — pair it with sessions and bot filtering before concluding anything about audience.
Diagnostic use case
Read pageviews as a volume signal for content, while knowing it is not a count of people and can be distorted by SPAs, prefetching, and bots.
What WebmasterID can help detect
WebmasterID records page_view events server-side-classified, so human pageviews are separated from bot pageviews by default — the count you read is the human one unless you ask for bots.
Common mistakes
- Treating pageviews as a count of people.
- Comparing pageviews across tools with different SPA/virtual-view rules.
- Reading a pageview spike before filtering bots.
Privacy and accuracy notes
Counting pageviews needs no cookies or personal identifiers — it is an event count. WebmasterID records page_view events first-party and keeps bot pageviews out of the human total.
Related pages
- Bounce rate: definition and why it misleads
Bounce rate is the percentage of sessions with only one interaction. Its definition shifted: classic tools counted single-pageview sessions; GA4 derives it from engaged sessions instead. A high bounce rate is not inherently bad — for a single-answer page it can mean success — which is why context matters more than the number.
- The page_view event: the base of web analytics
page_view is the event fired when a page loads. It is the base of almost every web-analytics model: sessions, pageviews, and most reports build on it. In classic sites the tracker fires it automatically on load; in single-page apps you fire it on each route change. Its properties (path, title, referrer) drive most downstream reports.
- 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.
- Event Explorer
Drill into the underlying page_view events.
Sources and verification notes
- MDN — Navigation and the page lifecycleBackground on what counts as a page load.
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.