SlimStat Is Not Recording Visits: A Diagnostic Checklist

SlimStat records why it stopped tracking. Open Settings > Maintenance and read the Tracker Error row, which holds the last failure code, its label and the time it was recorded. Then work down this checklist in order: Enable Tracking, the consent gate, Tracking Mode, exclusion filters, caching, ad blockers.

Step 1: Read the tracker error SlimStat already stored

SlimStat writes the last failure into the Tracker Error row at Settings > Maintenance, under Troubleshooting. The row shows the code, its plain-language label and the timestamp, followed by a “Reset this error” link. An install that has never failed shows the text “So far so good.” instead.

1. Open Settings > Maintenance and scroll to the Troubleshooting section.
2. Read the Tracker Error row and match its code against the table above.
3. Click “Reset this error” to clear the stored code.
4. Load a front-end page in a private window, then reload Settings > Maintenance.
5. Read the row again: a returning code is live, not a stale record.

For the full configuration dump, request /wp-json/slimstat/v1/tracker-health. The endpoint needs manage_options and a REST nonce, so run it from the browser console on /wp-admin/: fetch('/wp-json/slimstat/v1/tracker-health', {headers:{'X-WP-Nonce': wpApiSettings.nonce}}).then(r => r.json()).then(console.log). The response carries javascript_mode, gdpr_enabled, tracking_request_method, every exclusion setting, and the last error and warning.

Step 2: Confirm Enable Tracking is still on

Enable Tracking (is_tracking) lives at Settings > General, under Tracker, and defaults to on. With the toggle off, the tracker returns code 204 and stores nothing. Track Backend (track_admin_pages) defaults to no, so wp-admin pageviews are excluded by design.

Code 204 also warns that the client-side code is still attached to your pages, which means a cache is serving HTML generated while tracking was on. Clear every cache layer after switching the toggle.

Step 3: Check the consent gate before anything else

GDPR Compliance Mode (gdpr_enabled) defaults to off, and switching it on adds a consent check before tracking: a denied signal logs code 301 and records nothing. Both switches sit at Settings > Tracker, under Consent Management, alongside Consent Plugin Integration (consent_integration).

1. Read GDPR Compliance Mode. Off skips the CMP check; DNT and the slimstat_can_track filter can still return 301.
2. If on, read Consent Plugin Integration: “SlimStat Consent Banner (Recommended)” blocks every visitor who has not clicked Accept, whenever the configuration collects PII (a tracking cookie, or IPs neither anonymized nor hashed).
3. Selecting “Via WP Consent API” without the WP Consent API plugin installed falls back to SlimStat’s own banner.
4. Request /wp-json/slimstat/v1/consent-health, which returns can_track and pii_allowed for the current request.
5. Check Respect Do Not Track (DNT) under Data Protection: with do_not_track on, a browser sending DNT: 1 is never tracked, whatever the consent settings say.

Cookie-name matching for third-party banners is covered in GDPR banner plugin integration.

Step 4: Match Tracking Mode to your caching setup

Tracking Mode (javascript_mode) defaults to Client, which is the value to keep behind any page cache. Server mode records the visit during the PHP request, and a cached page never runs PHP, so nothing is recorded.

Minifiers are the second half: wp-slimstat.min.js ships already minified, so exclude it from any minifier. See excluding SlimStat from caching and minification for the exclusion each caching plugin needs.

Step 5: Rule out the exclusion filters

The tracker-health payload reports fourteen exclusion settings under ignore_settings, and three ship switched on: Bots (ignore_bots), Spammers (ignore_spammers) and Prefetch Requests (ignore_prefetch). Every match logs its own 3xx code, so the Tracker Error row names the filter that fired.

• Bots discards “crawlers, spiders, search engine bots, and other automated tools”, so test with a real browser.
• IP Addresses (ignore_ip) takes single addresses, and subnets in CIDR notation: 192.168.0.0/24 excludes that whole range.
• WP Users (ignore_wp_users) defaults to no; switched on, no logged-in user is tracked anywhere.
• Permalinks (ignore_resources) and Content Types (ignore_content_types) accept * and ! wildcards, so one broad pattern silences a section.

Step 6: Change the request method if a blocker intercepts it

Tracking Request Method (tracking_request_method) defaults to Admin-AJAX and offers three values: REST API, Admin-AJAX and Ad-Blocker Bypass. Fallback is always on, so a failed method is retried through the next one. Ad-Blocker Bypass routes the hit through a 32-character hashed path under /request/.

Switch to Ad-Blocker Bypass at Settings > General and save; SlimStat flushes the WordPress rewrite rules itself when the method changes. See bypassing ad blockers.

Step 7: Turn on Tracker Debug Mode and watch one request

Tracker Debug Mode (slimstat_debug) sits at Settings > Maintenance, under Troubleshooting, and is also active whenever WP_DEBUG is true. With the toggle on, tracking responses carry X-SlimStat-Transport and X-SlimStat-Outcome headers, plus X-SlimStat-Error-Code on a failure, and the browser records every transport attempt in window.__slimstatDebug.

1. Enable Tracker Debug Mode and save.
2. Open a front-end page in a private window with DevTools on the Network tab.
3. Find the tracking request and read X-SlimStat-Outcome: success means the row was written.
4. On error, read X-SlimStat-Error-Code: a negative number such as -301, listed in the table above.
5. Run window.__slimstatDebug.lastPageview in the console for selectedTransport, every attempt and finalOutcome.
6. Switch Tracker Debug Mode back off once the cause is identified.