Site owners check their own site far more often than they realize, usually without giving it a second thought. A quick look to confirm a new post published correctly, a check that a plugin update didn’t break the layout, a glance at the homepage after tweaking a widget. Every one of those visits gets counted as a pageview by default, and on a smaller site, that self-generated traffic can meaningfully distort what your analytics are actually telling you about real visitors.
Jetpack’s Site Stats module has a built-in way to fix this. Here’s how to set it up properly, and a few things worth knowing about what it does and doesn’t cover.
Why This Matters More Than It Seems
On a high-traffic site with thousands of daily visitors, an admin’s own pageviews barely register as statistical noise. On a smaller site, a blog in its first year, a niche business site, a portfolio, the math changes considerably. If you check your own site five times a day while writing and editing, that’s potentially a meaningful chunk of your reported daily traffic that has nothing to do with actual visitor interest.
This distortion compounds in specific ways. Bounce rate looks artificially better because you’re a returning visitor who already knows the site structure and doesn’t bounce the way a first-time visitor might. Average session duration skews because you’re often actively working on the site rather than reading it. And traffic trends over time become harder to trust, since a spike in your own editing activity during a busy content week can look, at a glance, like a genuine traffic increase.
Setting Up the Exclusion
Jetpack makes this a straightforward toggle rather than a technical workaround. Install and activate the Jetpack plugin if it isn’t already active on your site. From your WordPress dashboard, open the Jetpack menu, then go to the Settings tab. Scroll to the Traffic section and click Configure next to Site Stats.
In the Site Stats configuration screen, look for the option labeled “Don’t count pageviews from logged-in users” and turn it on. This is the core setting, and for most site owners running a solo blog or a small business site with a single dashboard account, it’s the only one that matters. If you have additional staff or contributors with dashboard access whose pageviews you also want excluded, there’s typically an option to exclude specific user roles as well, check the box next to that setting and select the roles you want left out of your visitor counts.
Save your settings once configured. From that point forward, Jetpack will stop counting pageviews generated while you’re logged in, giving you a cleaner picture of what your actual audience is doing on the site.
What This Setting Does and Doesn’t Cover
It’s worth being precise about the scope here. This exclusion only applies while you’re logged into WordPress. If you check your site from your phone in a private browser tab, or from a different device where you’re not logged in, those visits still count normally. The setting tracks login state, not you as a person across every device and browsing context.
This matters if you’re trying to get a fully accurate picture, since a lot of casual “just checking the site” visits happen from a phone where you might not be logged into the dashboard at all. For those situations, excluding your own IP address, covered below, closes that additional gap.
Excluding Specific IP Addresses Too
If you have a consistent static IP address, from a home office or a fixed business location, you can exclude that IP directly regardless of login state. This is useful if you sometimes browse your own site logged out, or if other people on your same network, family members, coworkers, occasionally visit the site without logging in themselves.
To set this up, go to the WordPress Jetpack settings page, click on the Security tab, and scroll down to the brute force attack prevention section. From there you can enter your IP address or addresses under a whitelisted IP addresses field. Keep in mind this only works cleanly with a static IP; if your internet provider assigns a dynamic IP that changes periodically, you’ll need to update this setting whenever it changes, which makes it a less reliable long-term solution than the logged-in exclusion for most home connections.
A Realistic Example of Why This Matters
Picture a small business site getting roughly forty pageviews a day. The owner logs in each morning to check overnight orders, edits a product description mid-afternoon, previews a blog draft twice before publishing, and checks the homepage once more after publishing to confirm it displays correctly. That’s easily five or six pageviews from a single person on a site averaging forty total, which means somewhere around fifteen percent of the reported traffic on a given day might simply be the owner going about routine site maintenance, not real visitor interest.
Scale that pattern across a full month and the distortion becomes significant enough to genuinely mislead decisions. A marketing campaign that appears to be driving modest but real growth might actually be flat once admin activity gets subtracted out, or a period that looks quiet might actually show healthier real visitor numbers than the raw total suggests, simply because the owner happened to be traveling and checking the site less that week.
How Contributor and Editor Roles Factor In
Solo site owners are the simplest case, but many WordPress sites have multiple people with dashboard access: a co-founder, a marketing contractor, a guest contributor previewing their draft repeatedly before it goes live. Each of these people generates the same kind of self-inflicted pageview inflation an owner does, just at a smaller individual scale that adds up across a team.
When configuring the role-based exclusion mentioned earlier, think through who actually has regular dashboard access rather than just excluding the administrator role by default. A contributor who logs in weekly to draft and preview posts is generating exactly the kind of non-representative traffic this setting is meant to filter out, even though they’re not an admin. Reviewing your site’s user list periodically and matching the exclusion settings to who’s actually active keeps this accurate as your team changes over time.
Comparing This to How Other Analytics Tools Handle the Same Problem
Google Analytics addresses this through a different mechanism: IP-based filters configured directly in the Analytics interface rather than a WordPress plugin setting. This means Google Analytics exclusions work regardless of whether you’re logged into WordPress, since they’re based on network location rather than authentication state, but they carry the same dynamic-IP limitation described earlier for Jetpack’s IP whitelist feature.
Matomo, a privacy-focused, often self-hosted alternative, offers similar exclusion options along with more granular control over what counts as a bot or automated visit in the first place. If you’re already running Jetpack for its other features, caching, security, image optimization, its built-in Stats exclusion is the path of least resistance. If you’re building out a more serious analytics setup from scratch, it’s worth comparing how each tool handles this specific problem before committing, since the configuration approach differs meaningfully between them.
Interpreting Your Numbers After Making the Change
Once the exclusion is active, resist the urge to directly compare your new numbers against historical data from before the change without accounting for the shift. A dip in reported traffic right after enabling this setting doesn’t mean your site suddenly lost visitors. It likely means your numbers just became more accurate, and the previous baseline was always somewhat inflated by your own activity.
Give it a few weeks of clean data, ideally spanning at least one full week of your normal posting and promotional rhythm, before drawing any real conclusions about trends. This is also a good moment to note the date you made the change somewhere you’ll remember, in a spreadsheet, a note in your content calendar, so that months later you don’t mistake a permanent, honest baseline shift for an unexplained traffic drop.
When You Might Actually Want to Keep Your Own Views Counted
Excluding your own traffic isn’t automatically the right call for every site. If you’re running a personal blog or portfolio where your own return visits are a genuine part of how you use the site, checking back to reread something you wrote, showing it to someone in person, excluding that activity might understate real engagement in a way that doesn’t actually serve you. In that specific case, it may make more sense to leave pageview tracking on entirely, or find a way to filter out your own visits only in certain contexts, like when you’re actively editing versus casually browsing.
The more common case, though, especially for a business site or a blog you’re actively promoting to build an audience, is that excluding admin views gives you a materially more honest read on whether your actual marketing and content efforts are working.
Site Stats Has Real Limits Worth Knowing
Jetpack’s Site Stats module gives you a solid baseline: pageviews, unique visitors, top posts, and referrer sources. It’s not, however, a comprehensive analytics platform. It won’t give you detailed conversion funnels, granular event tracking on specific button clicks, or the kind of segmentation a dedicated analytics tool provides. If your site’s growth stage genuinely requires that level of detail, tools like Google Analytics or a privacy-focused alternative like Matomo fill that gap, and both support similar admin-exclusion settings of their own.
Running Jetpack Stats alongside a more detailed analytics tool isn’t redundant. Jetpack’s numbers are convenient to check right from your WordPress dashboard without switching to another platform, while a dedicated analytics tool handles the deeper investigation once you notice something in Jetpack worth digging into further.
Double-Checking the Setting Actually Worked
After enabling the exclusion, it’s worth confirming it’s working as expected rather than assuming the toggle did what it says. Stay logged in and visit a few pages on your site, then check your Jetpack Stats dashboard after a short delay to see whether those visits show up. If your own pageviews still appear to be counting, double check that you’re logged in under the same account the exclusion applies to, and confirm the setting actually saved correctly, since a page refresh or a caching plugin can occasionally interfere with settings changes taking effect immediately.
How This Fits Into a Broader Accurate-Tracking Setup
Excluding admin views is one piece of a bigger picture if you want genuinely reliable traffic numbers. Bot traffic is another common source of distortion that a basic setup like this doesn’t address; a decent security or firewall plugin typically filters a meaningful share of that automatically. If your site has multiple contributors or an editorial team, extending the logged-in exclusion to cover their roles too, not just your own admin account, keeps the numbers clean across everyone with regular dashboard access rather than just the site owner.
None of this needs to be perfect. The goal isn’t flawless data, it’s removing the most obvious and avoidable distortion so the trends you’re looking at actually reflect what your real audience is doing.
Other Sources of Traffic Distortion Worth Ruling Out
Admin views are one common source of misleading numbers, but they’re rarely the only one on a smaller site. Search engine and monitoring bots hit most sites constantly, and a portion of that automated traffic can slip through into pageview counts if a site isn’t running any kind of bot filtering. Uptime monitoring services, if you’re using one to alert you when your site goes down, also generate regular automated visits that have nothing to do with real audience interest.
A caching plugin misconfiguration can occasionally cause the same page to register multiple counted views from a single real visit too, if cached and uncached versions of a page are being tracked inconsistently. None of these are reasons to distrust your analytics entirely, but they’re worth ruling out if your numbers seem persistently higher than what direct evidence, comments, form submissions, actual sales, would suggest is realistic.
A Simple Monthly Check-In Worth Building Into Your Routine
Once the exclusion setting is in place, it mostly runs quietly in the background without needing further attention. Still, a brief monthly glance at your Jetpack Stats dashboard is worth the few minutes it takes: confirm the numbers look reasonable relative to what you know about your actual promotional activity that month, check whether any contributor roles need to be added to the exclusion list following a team change, and note anything that looks like an unexplained spike or drop worth investigating further.
This kind of light, regular check catches configuration drift, a plugin update resetting a setting, a new contributor account that wasn’t added to the exclusion list, before it has a chance to quietly distort a full quarter’s worth of data without anyone noticing.
Frequently Asked Questions
Will this setting affect SEO or search engine crawling in any way? No. This setting only affects what Jetpack counts in its own analytics dashboard. It has no effect on how search engines crawl or index your site.
Does this work if I use a different analytics tool alongside Jetpack? This specific setting only controls Jetpack’s own Site Stats. If you’re also running Google Analytics or another tool, you’ll need to configure a similar exclusion separately within that tool, since they track independently of each other.
What if I forget I’m logged in and my views are still being excluded when I want them counted? Simply log out of WordPress if you want a specific visit counted normally, or temporarily disable the setting if you need accurate tracking of your own testing activity for a specific reason.
Is there a way to see how much traffic this setting is actually excluding? Jetpack doesn’t provide a before-and-after comparison natively. If you want to measure the actual impact, note your current numbers before enabling the setting, then compare trends over a similar time period after, keeping in mind other variables like seasonal traffic changes will also be in play.
Should I exclude every logged-in role, or just administrators? That depends on how those other roles actually use the dashboard. A subscriber-level account that only exists for a member-only content area shouldn’t be excluded, since those genuinely are real visitors browsing your site. A contributor or editor account that’s only used to draft and preview content is closer to admin-style activity and probably belongs on the exclusion list.
The Bottom Line
A five-minute settings change removes one of the more common, and more overlooked, sources of inflated traffic numbers on a smaller WordPress site. It won’t turn Jetpack into a full analytics suite, but it does mean the numbers you’re checking each morning reflect actual visitors rather than your own habit of refreshing the homepage to admire a new post.
Small accuracy fixes like this one rarely feel urgent, which is exactly why they get skipped. But a decision about whether to run a marketing campaign, invest in more content, or change strategy based on traffic trends is only as good as the data behind it. Spending five minutes now to make sure that data actually reflects reality is worth more than it looks like on the surface.