SlimStat Is Not Recording Visits: A Diagnostic Checklist

When a request reaches the tracker, SlimStat can record why it stopped tracking. A blocked script or request can leave no server-side diagnostic. 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 an authenticated diagnostic, use the slimstat/v1/tracker-health REST route with administrator capability (manage_options). Cookie authentication also requires a valid REST nonce. It returns tracking settings, exclusions and recent diagnostics. Do not publish its output.

On an admin screen that loads WordPress’s wpApiSettings, this console example uses the installation’s REST root, including subdirectories. It deliberately stops if that configuration is unavailable:

if (typeof wpApiSettings === 'undefined') {
  throw new Error('This admin screen has not loaded the WordPress REST client settings.');
}
fetch(wpApiSettings.root + 'slimstat/v1/tracker-health', {
  headers: { 'X-WP-Nonce': wpApiSettings.nonce }
}).then(response => {
  if (!response.ok) throw new Error(`Health request failed: ${response.status}`);
  return response.json();
}).then(console.log);

A health request describes its authenticated request context, not the consent state of a separate anonymous visitor.

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. The GDPR switch sits 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)” can block visitors before acceptance when the banner is enabled and the configuration collects PII (a tracking cookie, or IPs neither anonymized nor hashed).
3. Selecting “Via WP Consent API” requires the API and a configured integration. Verify that the API is available; do not assume a missing integration will show a fallback banner.
4. The authenticated slimstat/v1/consent-health REST route returns can_track and pii_allowed for that request. It also requires administrator permission and valid authentication; test the actual visitor journey separately.
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.

If a script optimizer breaks or delays tracking, isolate that optimization and exclude the actual tracker URL when needed. Static JavaScript can remain cached. See excluding SlimStat from caching and minification for the script and endpoint checks.

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. Network or protocol failures can trigger fallback to another available method. Explicit tracking rejections stop the request. 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 indicates an accepted tracking response. Confirm the intended pageview or interaction in the reports rather than treating this header as proof of a new row.
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.