You installed analytics, opened the dashboard, and found an empty screen. Or you made a site change and visits suddenly look much lower. Take a breath. Most cases come down to a few checks you can make without changing your whole site.
Start with one visit you can control. If that visit appears in Hitsteps, the basic connection works and you can focus on why other visits may be missing. If it does not appear, work through the installation checks below in order. Hitsteps is real time, so you can watch the live dashboard while you test.
First, do a two minute check
- Open the website you added in Hitsteps and note which install method you chose. You need one method, not several.
- Purge any page cache or CDN that could still be serving a page from before the install or site change.
- Open a private or incognito window, turn off ad blockers for this test, and browse a public page on your site.
- Watch that site’s live dashboard in Hitsteps. Give yourself enough time to load the page and look at the result, rather than refreshing both windows repeatedly.
- If the visit is missing, check the live page for the tracker and confirm the key belongs to the website you are testing.
A visit that appears after clearing cache points toward an old page. A visit that appears only with a blocker off points toward the browser. An empty dashboard after a clean test calls for a closer look at the install, key, consent settings, or script loading.
If you are testing your own visit, also check whether you excluded your visits in account preferences. That setting can make a working installation look silent during a self-test.
Check that Hitsteps was installed in one place
Hitsteps needs exactly one install method. You can use the manual JavaScript snippet placed before </body>, the WordPress plugin, the Shopify app, the Google Tag Manager template, the Wix app, or the Joomla extension. Choose the method that matches how your site is managed, then make sure it is the only one in use.
How to spot it: Check every place the tracker might have been added. A developer may have pasted the snippet into a theme while someone else installed a plugin. A migration may have left an old tag in Google Tag Manager.
How to fix it: Keep one method and remove the other Hitsteps installs. On Shopify, use the app only. On a WordPress site using the plugin, avoid adding the snippet manually or through Google Tag Manager. Purge caches, then run one private window test.
Duplicate installs can cause double or confusing tracking. Finish checking the first installation before changing methods.
Make sure the key matches the site you are viewing
A tracker can be present on the page and still send data somewhere you are not watching. This is especially easy to miss when you manage several websites, copied settings from a staging site, or recently moved to a new domain.
How to spot it: In Hitsteps, open the website entry you intended to test. Compare its setup information with the live installation. Plugins and apps use that site’s API code. The manual method uses the full JavaScript snippet from that site’s dashboard.
How to fix it: Copy the correct code from the website entry you are checking, update your chosen install method, and purge the page cache or CDN. Then visit the live site in a private window and look at that site’s live dashboard. If you have a staging copy, keep the test tied to the intended site entry.
Do not publish your full API code in a forum or screenshot. Compare it privately with your settings.
Look for the tracker on the page visitors actually receive
Seeing a snippet in a theme editor does not prove it reached the live page. The published theme, a page builder, a template change, or a deployment can leave the code somewhere other than the page people open. Check the live site once, rather than repeatedly reviewing the editor where the code was entered.
How to spot it: Open a public page and inspect its live source for Hitsteps. With a manual installation, the snippet should be before the closing body tag. For a plugin, app, or tag manager install, check the loaded page for the tracker. The theme editor cannot tell you what reached the public URL.
For a manual install, the placement looks like this in general terms:
<body>
<!-- page content -->
<!-- your Hitsteps snippet from the dashboard goes here -->
</body>The comment is a placeholder. Paste the full snippet supplied for your site in Hitsteps. If it is missing from the live page, correct the published template or your chosen plugin, app, or tag manager setup. Save, publish if required, clear cache, and test again.
Clear an old cached version of the page
After an install or site change, a page cache or CDN may still serve a page created before the tracker was added. That can explain an empty test or patchy counts across pages.
How to spot it: Compare your current template with the source of the public page. If the tracker appears in the template but not in the page you receive, a cached response is possible. One page may contain the tracker while another still lacks it.
How to fix it: Purge the page cache and any CDN. Reload the public page, check the source, and run a fresh private window visit. If the tracker is still absent, revisit the published template or selected install method.
Check the platform step that is easy to miss
Some installs have a final step that feels separate from adding the code. If the general checks look right, use the path below that matches your site.
Google Tag Manager: publish and fire on All Pages
How to spot it: The Hitsteps template may be configured in your workspace while the live container has not been published. Or the tag may fire only on a narrow set of pages. In either case, your own test page may never load the tracker.
How to fix it: Use the Hitsteps template with the site’s API code, set it to fire on All Pages, and publish the container. Then confirm it loads on the live page. Do not also install the manual snippet or a plugin for the same site.
Shopify: keep the app as the one method
How to spot it: You installed the Shopify app but later pasted a Hitsteps snippet into theme code while troubleshooting, or you are checking only the theme editor instead of the public storefront.
How to fix it: Use the Shopify app only. Remove a duplicate theme snippet if one was added, then check the live storefront and live dashboard with a private window test.
WordPress.com: check what your plan allows
How to spot it: You followed a WordPress install path, but the method you expected is not available on your WordPress.com plan or the tracker never reaches the public page.
How to fix it: Some WordPress.com plans may need a Text/HTML widget approach. Check the install instructions for your plan, choose the available single method, and verify the public page after saving. For other WordPress sites using the plugin, confirm that the plugin has this site’s API code and that another Hitsteps method is not also active.
Try the visit without an ad blocker
Browser extensions can prevent a tracker from loading or sending a visit. That is common enough to test before treating a lower count as a broken installation. It is also why your own everyday browser is not always a reliable test visitor.
How to spot it: Visit the same public page once in a private or incognito window with ad blockers off and watch the live dashboard. If that visit appears while a visit from your usual browser does not, the difference is likely in the browser setup. You can repeat the comparison once to be confident you were looking at the same site entry.
How to respond: There is no need to redesign the site to count someone who chose to block tracking. Use the clean test to establish that installation works. Expect some real visitors to remain unmeasured and avoid treating every gap between your server activity and analytics as an installation failure.
Check whether consent is holding tracking
A consent banner or consent mode may deliberately hold tracking until a visitor makes a choice. If you test by opening the site and do not respond to the banner, an empty live dashboard may be the expected result of the rules you set. A change to the banner can also explain a sudden difference after the site itself appears unchanged.
How to spot it: In a private window, note whether a consent banner appears and what happens after you make the choice that permits analytics under your site’s configuration. Compare the live dashboard before and after that choice. If the tracker begins to appear only after consent, the install may be working as configured.
How to fix an unintended hold: Review the banner and consent mode setup for the site. Make sure the choice that should allow analytics actually releases the tracker, and that the rule is applied consistently across pages. Test the allowed path again. If the visitor declines, respect that outcome; it is not a missing-data bug.
Hitsteps offers privacy controls such as IP anonymization, an opt-out cookie, Do Not Track handling, and consent modes. Depending on the choices made, fewer visits may be counted. Read a low total in the context of those settings before changing anything. A clean installation and a privacy choice can both be true at once.
See whether your Content Security Policy blocks the script
A Content Security Policy, often called CSP, can block scripts that are not allowed by the site’s policy. Hitsteps loads its tracker script from edgecdnplus.com. If your site recently tightened its policy, this is a useful check after you have confirmed that the installation is present on the live page.
How to spot it: Open browser developer tools on the public page and look for a CSP message related to the tracker script or edgecdnplus.com. The key clue is that the installation is present but the browser refuses to load the script. This is different from a snippet that never reached the page at all.
How to fix it: Ask whoever manages the site’s CSP to review the rule and allow the Hitsteps tracker to load from edgecdnplus.com in the appropriate place. Keep the policy deliberate and specific. After the change is published, reload the page in a private window and look for your test visit in the live dashboard.
Account for pages that change without a full reload
Some sites change pages inside a single page app. A visitor clicks a link, the address changes, and new content appears, but the browser does not load a whole new document. A tracker installed on All Pages or in the main page can work on the first load while later route changes need their own handling. The result can look like fewer pageviews than the paths people actually visited.
How to spot it: Watch the live dashboard while you load the site normally, then move through several screens using the app’s own links. If the first load appears but later screen changes do not, ask whether those changes create a full page load. A route change without one is a likely explanation.
How to fix it: Connect route changes to the tracking approach documented for your framework and chosen Hitsteps install method. In general JavaScript terms, your app might have a handler like function onRouteChange() { /* notify tracking using your install method's instructions */ }. Call it from your router when the page changes. That comment is a placeholder, not a Hitsteps pageview function. With Google Tag Manager, a history change trigger may be relevant; check the Hitsteps install instructions for the correct setup. Test both the first load and later routes, and make sure the same route is not counted twice.
Check whether you excluded your own visits
It can be surprisingly easy to forget a useful preference when you are testing. If your account preferences exclude your own visits, a normal visit from you may leave the live dashboard unchanged even though other visitors are being counted. This matters most when your only proof of failure is your own test.
How to spot it: Review the account preference for excluding your visits. Then compare your test with the settings in mind. If you expect your visit to be excluded, an empty result for that visit does not tell you whether a new visitor would appear.
How to fix the test: If you want your own visit to appear, temporarily remove the exclusion in account preferences and test once, then restore your preference. Keep the exclusion if it helps your normal reporting. The goal is to learn why that test visit was absent.
If the dashboard is working but the total still feels low
Once a clean private window test appears, you have answered the most urgent question: Hitsteps can receive a visit from the live site. A lower total deserves a different investigation. It may reflect blockers, opt-outs, consent choices, Do Not Track handling, or pages that never loaded the tracker. Some of those are deliberate limits. Some point to a particular page or route you can fix.
Compare like with like. Hitsteps reports pageviews, visits, new and returning visitors, and bounces. A pageview is not the same unit as a visit, so those totals need not match. New and returning visitors and bounces answer different questions again. Hitsteps filters bot hits separately, which can also make a raw count from another source look different. Avoid deciding the install is broken just because two unlike numbers do not line up.
Look for a pattern you can test. Did counts change right after a new theme, consent banner, CSP rule, cache change, or app navigation update? Are visits present on one public page but absent on another? Does a private window test work while your regular browser does not? Each answer points to a narrower check above.
Some visitors will always be unmeasured. A blocker can stop a request. A person can opt out or decline consent. Your privacy settings can intentionally reduce what appears. Once the installation is sound, compare trends over time under the same setup instead of trying to chase every single visit. If you change the setup, note when you did it so a later dip has context.
What to send support if it still does not work
If you finish the checks and a clean private window visit still does not appear, send support enough detail to reproduce the problem. A short, specific note is more useful than a long guess about the cause. Include:
- The public site URL and the page you used for the test.
- Your one chosen install method, such as the manual snippet, WordPress plugin, Shopify app, or Google Tag Manager template.
- What you already tried, including any cache or CDN purge, key check, consent test, or CSP finding.
- A screenshot of the live dashboard around your test.
- Whether the visit from a private window with ad blockers off appeared.
If the issue started after a site change, mention what changed and when. Do not publicly post your full API code. Support can use the site URL, install method, and test result to start narrowing down the issue.
A short checklist to keep nearby
- Choose one Hitsteps install method and the correct code for the website.
- Confirm the tracker reaches the live page, then purge page cache and CDN.
- Test a public page in a private window with ad blockers off and watch the live dashboard.
- Check consent, privacy settings, CSP, route changes, and your own visit exclusion if needed.
- If the clean test still fails, send support the site URL, method, steps tried, screenshot, and test result.
One clear test at a time will usually tell you more than another round of reinstalling. When the live visit appears, you can get back to the questions your site data was meant to answer.
