Troubleshoot Missing Pageviews in Plausible
1. Pin down which pageviews are missing
Start with one failing URL. Write down the page address, the time you tested it, and whether the Plausible report shows visits to other pages on the same site. A specific example, such as a product page that is absent while the homepage appears, is more useful than “analytics is broken.”
Compare the failing page with one that tracks correctly. Check whether the two pages use the same template, load from the same hostname, and appear under the same Plausible site. A difference in any of those details gives you a place to investigate before changing code.
Separate direct visits from in-site navigation. Open the affected URL in a fresh tab, then reach it by clicking a link from another page. If direct visits appear in the report but clicks do not, the issue may involve how the site handles navigation; if neither appears, start with the tracking code or browser conditions.
Keep a short test record. Note the exact URL, the route you took to reach it, the browser, and the result you saw. That record lets you repeat the same test after a change instead of relying on memory.
2. Check whether the browser sends a pageview event
Open the affected page and its browser developer tools. In the Network panel, reload the page and look for requests associated with Plausible.
If a request appears, inspect its details rather than stopping at “it loaded.” Check whether the page URL in the request is the affected page, whether the request completed, and whether the browser shows a blocked or failed status. A request that reports the homepage instead of a nested route points toward URL handling, not necessarily a missing script.
If no request appears, check the Network panel’s filters first. A text filter can hide the request you are looking for, and a preserved log can mix activity from earlier page loads with the current test. Clear the filter, reload once, and inspect the new activity.
Use the Console panel as a second check. A script-loading error, a content security policy message, or a JavaScript exception may explain why the request never happens. Copy the exact message and the affected page URL before changing anything; those two details make it easier to distinguish a site error from a browser block.
To understand how to fix missing pageview tracking in Plausible, first establish whether the browser sends a pageview request at all. That single observation narrows the next step: investigate script execution when no request exists, or inspect the request and report setup when one does.
3. Rule out browser and consent blockers
Repeat the test in a clean browser profile or a private window with extensions disabled where possible. Ad blockers, tracking protection, and privacy extensions can prevent an analytics request from being sent, so one browser result is not enough to establish that every visitor sees the same problem.
Test the consent flow as a visitor would. Load the page before making a choice, then accept analytics consent if the site offers it and reload or revisit the affected route. If the request appears only after consent, inspect the consent manager’s configuration and confirm that its analytics category is connected to the Plausible script.
Do not treat a refusal of optional analytics consent as a bug by itself. The important check is whether the behavior matches the site’s intended consent rules and the configuration in use. For background on privacy-oriented measurement choices, see what changed in privacy-first analytics.
Check the Console for errors that appear only after the consent banner loads. If a banner’s script fails before it releases the analytics script, the page may look normal while the tracking request remains absent. When the banner is part of the problem, test whether its controls can be reached with a keyboard; this guide explains how to check if a website publishes an accessibility statement.
4. Compare the affected page’s rendered tracking code
Inspect the page as delivered to the browser, not only the source file or content management system setting. A template may omit the tracking snippet on one page type, or a tag manager may inject it only on selected routes. Compare the rendered code on one working URL and one failing URL.
Look for the Plausible script and the site or domain value associated with it. A typo in the configured domain, or a hostname that differs from the one registered for the site, can send you looking in the wrong report.
Check whether the script is present more than once. Duplicate installation can complicate testing and make the results harder to interpret. If the two pages differ, identify which system supplies the code—such as the page template, tag manager, or a plugin—then make the correction in that source rather than adding another copy by hand.
When comparing rendered code, account for script timing. A consent manager or tag manager may add the script after the initial HTML has loaded, so a quick view of the page source may not show the final state. Use the browser’s Elements panel and Network panel together to see whether the script element appears and whether the browser requests it.
5. Test direct loads separately from client-side navigation
Open the affected route directly in a new tab, then navigate to it from another page without a full reload. Record the result for each path. A site built as a single-page application can change the displayed route without making the browser load a new document, so check whether that navigation produces a pageview.
If direct loads are counted but in-site clicks are not, check the site router and the Plausible integration for client-side navigation support. Check the integration documentation to see how it handles route changes.
If navigation is counted but a direct load is missing, inspect the initial page response and the route’s template. The server may deliver a different document or omit the tracking code for that route. Compare the rendered code and request details for the initial load with those recorded after a click.
Test a route with query parameters or a trailing slash only if visitors actually use those forms. The URL recorded by the browser and the URL you expect in the report may differ in these cases; record the exact address rather than assuming two similar-looking URLs are treated identically.
6. Check Plausible’s report scope and filters
Before treating an absent row as a collection failure, confirm that the dashboard is showing the intended Plausible site. A report for a staging domain, alternate hostname, or similarly named project will not answer whether the production pageview arrived.
Set the date range to include the test, then review any filters or segments applied to the report. A narrow date selection or an active filter can hide a page that was recorded. If you tested at a known time, use that time to keep the report check tied to the browser test.
Search or inspect the page report using the same path the browser sent, including any relevant trailing slash or query string.
Also distinguish a pageview from a custom event. If the implementation sends a named event when a route loads, check the request and look for that event in the appropriate report area rather than assuming it is an ordinary pageview.
7. Retest the fix across the failing cases
Change one thing at a time. If you corrected a domain value, retest before also changing consent rules or router code. A single change makes it clear whether the request began working and prevents a second issue from hiding the first.
Repeat the original test matrix: load each affected URL directly, reach it through an internal link, and compare both results with a known working page. Use the same browser conditions and consent choice you recorded earlier. If the site supports several templates, include one failing example from each affected template.
For every test, verify two points: the browser sends the expected pageview request for the correct URL, and the new pageview appears in the intended Plausible site report. If the request is present but the report remains empty, return to the selected site, date range, and filters before changing the site code again.
Keep the working test record with the code change or support ticket. Include the affected URLs, browser results, relevant Console errors, and the report scope you checked. That evidence gives the next person a repeatable test instead of a vague report that pageviews are missing.
