Hi @tkbuhler ,
Thanks for flagging this — really appreciate you taking the time to report it in detail.
We investigated all four areas you mentioned (bots, content types, permalinks, and users) and ran a full suite of automated tests against v5.4.3. Here’s what we found:
Bot exclusion, permalink exclusion, and user exclusion are all working correctly in v5.4.3. If you have “Ignore Bots” enabled under SlimStat > Settings > Exclusions, crawlers detected by Browscap are filtered out. Same for permalink patterns in “Resources to Ignore” and user exclusion settings — they’re functioning as expected.
Custom post type (CPT) exclusion — this is where we found the problem, and it’s on us. To exclude a custom post type like “product”, you need to enter it as cpt:product (with the cpt: prefix) in the “Content Types” exclusion field. The settings UI didn’t explain this, so entering just product would silently fail to exclude anything. That’s confusing and shouldn’t have happened.
We’ve already fixed the settings description to make the cpt: prefix requirement clear, and we’re tracking this under our GitHub issue:
https://github.com/wp-slimstat/wp-slimstat/issues/233
To fix it on your end right now: go to SlimStat > Settings > Exclusions > Content Types, and change any custom post type entries to use the cpt: prefix (e.g., cpt:product instead of just product).
Could you try that and let us know if the CPT exclusion starts working for you? That’ll help us confirm the fix covers your setup.
Thanks for your patience!
Cheers
Hello… thanks for your help with this. I’ll try the CPT setting in the exclusions.
As for my other problems, i’m definitely still having the issue with User exclusions in particular. I do have WP Users set to be excluded, and in addition i also have the specific usernames excluded from tracking. Despite these settings, Slimstat is still showing the tracking of this logged-in user on the site (this is a recent problem for me… until a recent update this wasn’t the case).
Hi @tkbuhler ,
Thanks for the follow-up — we hear you, and we want to get to the bottom of this.
After your report, we wrote a dedicated set of automated tests specifically for user exclusion — covering both the “Exclude WP Users” toggle and the username blacklist, across every tracking transport (AJAX, REST, and even simulated stale-nonce scenarios). All five tests pass: excluded users produce zero rows in the database, exactly as expected.
So the exclusion logic itself is solid, which means something in your environment is likely interfering with how WordPress identifies logged-in users during the tracking request. The most common culprit we see is a page caching plugin (WP Super Cache, W3 Total Cache, LiteSpeed Cache, etc.) or a CDN like Cloudflare — these can serve cached pages where the tracking script doesn’t know you’re logged in, so the server-side exclusion never kicks in.
Could you let us know if you’re running any caching plugin or CDN? That’ll help us narrow it down quickly.
Thanks for sticking with us on this!
Cheers
Thanks for your help… i don’t currently have a caching plugin or CDN running for my site.
Also, i’ve just noticed that a CPT exclusion i have set (cpt:attachment) is still tracking hits for that content type on my site.
Hi @tkbuhler ,
Thanks for confirming — that rules out caching as the cause, and we appreciate you staying with this.
Two updates:
cpt:attachment — this one is on us. We’ve confirmed it’s a bug and filed it here:
https://github.com/wp-slimstat/wp-slimstat/issues/236
The short version: WordPress handles attachment pages differently from other content types internally, and our exclusion code wasn’t accounting for that difference, so cpt:attachment never matched regardless of how it was entered. Nothing wrong with your settings — the problem is in the code. A fix will land in the next release.
For user exclusion — since caching and CDN are off the table, we’d like to narrow it down. Could you check one setting for us: go to SlimStat > Settings > General > Tracker and let us know whether it’s set to “Server” or “Client (JavaScript)”? That’ll point us to exactly which code path is involved in your setup.
Thanks again for your patience with this.
Cheers
It is currently set to Server.
Thank you.
To follow up (from my original post) on what i see as Bots being tracked on my site:
Even though many views on individual site pages, SlimStat shows 0 sessions today (typical recently), and also 0 Human Visits under Audience. There is a lot of activity under Pageviews, but why does this not correspond to hits under Human Visits (unless these are Bots or Crawlers)?
Also i have another statistics plugin that shows no corresponding hits, and basically zero overlap with what SlimStat shows me. Overall — the behavior of these “visitors” to my site doesn’t correspond with expected behavior on my site; the locations appear to be very random, international sources i also wouldn’t normally expect (also recently, many of them are hitting the robot.txt file at my site root).
Hi @tkbuhler ,
Thanks for this follow-up — it’s the detail that cracked it.
We found the root cause: it’s a bug in server-side tracking mode. When the tracker is set to “Server” (as yours is), session IDs aren’t being assigned to pageviews. Every record gets a session ID of zero. The “Human Visits” chart only counts visits with a valid session ID, which is why it shows 0 — even though the pageviews are real and being recorded.
This also explains why the traffic looks bot-like: without session IDs, every pageview appears as a standalone hit with no visitor continuity, which mimics crawler behavior. And it’s likely why your user exclusion appeared broken — without session context, it’s difficult to distinguish which pageviews belong to you vs. anonymous traffic.
We’ve filed this as a bug: https://github.com/wp-slimstat/wp-slimstat/issues/257
Workaround until the fix ships: switch the tracker to Client (JavaScript) under SlimStat > Settings > General > Tracker. This mode assigns session IDs correctly and will give you accurate Human Visits and Sessions data right away.
For the cpt:attachment exclusion — that fix shipped in v5.4.5. Please update and it should work correctly now.
For user exclusion — once the server-mode fix lands (or after you switch to Client mode), could you check again whether your excluded user is still being tracked? With proper session IDs in place, we’ll be able to tell definitively whether there’s a separate issue there.
Thanks for sticking with this — your persistence uncovered a significant bug that affects all server-mode users.
Cheers
That all sounds great, thanks. So far with the recent update i have not had the problem with user being tracked.
Hi @tkbuhler ,
Great to hear the user exclusion is working again — thanks for confirming.
We just released v5.4.6, and it addresses everything we worked through in this thread. Upgrading to 5.4.x broke tracking for many users: visitor counts dropped to zero, IPs were masked without permission, and a consent banner appeared on sites that never asked for one. This release fixes all of that. After updating, your site works the way it did before 5.4.0 — no manual steps required.
If you’re running a caching plugin, clear your cache after updating.
Once you’ve updated, visit a few pages on your site and check the Access Log to confirm new data is being recorded. If anything still looks off, we’re right here.
Cheers
