Exclude Your Own Visits, Bots and Specific Traffic

SlimStat excludes your own visits from Settings, Exclusions tab, at admin.php?page=slimconfig&tab=4, where fifteen settings filter traffic by WordPress user, capability, IP range, country, language, user agent, operating system, permalink, referrer and content type. Every rule runs inside the tracker, so excluded traffic is never written to the database.

Which Exclusion Setting To Use

The Exclusions tab holds two sections: User Properties carries eleven settings about who is visiting, and Page Properties carries four settings about what is being requested. Toggles take no value, and every textarea is a comma-separated list whose entries are trimmed of surrounding spaces.

The Order SlimStat Applies Exclusions

SlimStat evaluates exclusions in one fixed order inside src/Tracker/Processor.php, returning a numbered tracker code the moment a rule matches and skipping everything below it. IP addresses are the first Exclusions setting tested, ahead of permalinks, referrers, users, countries and bots, so a matching CIDR range makes every later setting irrelevant.

Code 311 fires only while a geolocation provider is active and consent permits personal data, because SlimStat reads the visitor country inside that same guard. With geolocation disabled in the geolocation setup, the Countries field never matches anything.

How Each Field Is Parsed

Seven textareas are split on commas and then matched by Utils::isBlacklisted(), which anchors each pattern to the start and end of the value and compares case-insensitively: Usernames, Capabilities, Permalinks, Referring Sites, Content Types, User Agents and Operating Systems. An entry must equal the whole value unless you add a wildcard.

• * stands for any string including an empty one, so user* matches user12 and userfoo.
• ! stands for a single character, so user!0 matches user10 and user90.
• Countries and Languages skip that engine entirely and run a case-insensitive substring search, which is why wildcards are documented as unsupported there.
• ignore_ip compares CIDR ranges such as 54.12.0.0/16 against both the public IP and the originating IP, and a bare address is treated as /32 for IPv4 or /128 for IPv6.

Exclude Yourself And Your Team

Setting ignore_wp_users to on drops every logged-in WordPress account, on the front end and in the backend, and the shipped value is no, so a fresh install does record your own visits. Leave the toggle off when you want only some accounts excluded.

1. Open SlimStat, click Settings, then open the Exclusions tab.
2. Switch WP Users to on to exclude every logged-in account.
3. Enter individual logins in Usernames to exclude only certain accounts.
4. Enter manage_options in Capabilities to exclude everyone who can administer the site.
5. Add your office range to IP Addresses in CIDR form, such as 203.0.113.0/24.
6. Click Save Changes.
7. Reload a public page as that user and check the Real-time report.

Capabilities matches role slugs as well as capability keys, so editor and edit_posts both exclude an editor. Saving the Exclusions tab needs the capability named under Access Control, Settings, Minimum Capability, which is manage_options until you change it.

Excluding Traffic In Code

slimstat_filter_pre_tracking receives a boolean in wp-slimstat.php while the plugin loads, and returning false stops SlimStat registering the tracker for that request, before any Exclusions setting is read. SlimStat already passes false for its own internal endpoints, so return the incoming value whenever your own condition does not apply.

add_filter('slimstat_filter_pre_tracking', function ($is_tracking) {
    return $is_tracking && empty($_GET['preview']);
});

The slimstat_filter_pre_tracking reference carries the full signature. Two later hooks drop an already-collected pageview when a callback returns an empty array: slimstat_filter_pageview_stat_init records code 302, and slimstat_filter_pageview_stat records code 316.

Confirming An Exclusion Fired

SlimStat stores the last tracker outcome under Settings, Maintenance tab, in the Troubleshooting section labelled Tracker Error, as a timestamp plus the numeric code. Code 304 means an IP matched, 309 a WordPress user, 313 a bot and 311 a country. The Reset this error link beside the message clears the record.

The Tracker Error record is rewritten at most once every 900 seconds while the code stays the same, so the timestamp will not advance on every excluded hit. Tracking Mode set to Client also weakens bot filtering, because crawlers that run no JavaScript send no request for ignore_bots to reject; the tracker troubleshooting checklist covers that mode in detail.