Site has no working analytics, so traffic is unmeasured
why is my analytics dashboard showing zero visitors even though the site gets traffic Usually a placeholder measurement ID, an analytics package that was installed but never rendered into the page, or a fork still reporting into the parent property. Grep the live HTML for the actual tag and fire a real page load to confirm a hit lands. The fix is a verified snippet plus two or three named conversion events, not just reinstalling the library.
Seen in 24 of 450 scanned projects (5%). Based on Deep Scan runs across 450 audited production sites.
How to tell you have it
- Analytics dashboard sits flat at zero or near-zero sessions despite known traffic
- npm ls shows an analytics package installed but no script tag appears in curl output
- The measurement ID in the page source is still the vendor's placeholder value
- A staging or forked deployment shows up mixed into the production property's numbers
- Nobody can say which button or form submit counts as a conversion
Why it matters
Unmeasured traffic means every decision about the site becomes a guess. You cannot tell if a pricing page change helped or hurt, which channel actually drives signups, or whether a marketing spend is paying back, because there is no ground truth to compare against. Teams in this position tend to fall back on gut feel, and gut feel is wrong often enough to matter.
An analytics package sitting in package.json but never rendered is worse than having none, because it creates false confidence. Someone checks the codebase, sees the dependency, assumes tracking works, and moves on. Meanwhile the actual HTML served to visitors never includes the script, and the gap goes unnoticed for months.
Placeholder measurement IDs are an easy trap during scaffolding. A boilerplate ships with G-XXXXXXXXXX or a similar stand-in, someone means to swap it before launch, and the swap never happens. The dashboard doesn't error, it just quietly reports nothing, which is a much harder failure to notice than a crash.
A forked or duplicated site reporting into the parent property corrupts both datasets. Staging traffic, a client demo copy, or an old rebrand can all end up sending hits to the same measurement ID as production, inflating numbers on one side and making funnel math meaningless on the other. Nobody catches this until the totals stop making sense.
How Heygents detects it
Deep Scan runs curl -s against the live URL and greps the rendered HTML for known analytics script patterns, then checks the actual measurement ID in that markup against common placeholder values. It also reads package.json and the repo's env files to see whether an analytics dependency or ID is present without a corresponding tag in the served output.
How to fix it
- Confirm the tag is actually rendered, not just installed Do not trust that the package being in package.json means it fires. Pull the real HTML the server sends and search it directly.
- Check the measurement ID is not a placeholder Boilerplates commonly ship with a stand-in ID. If this is what you find in production, nothing has ever been recorded.
- Verify a real hit lands, don't just check the tag exists A present tag can still be blocked by an ad blocker, a CSP header, or a network rule. Load the page in a fresh browser session and confirm a request actually reaches the analytics endpoint in the network tab, or use the vendor's realtime/debug view and load the page yourself while watching it.
- Rule out a forked deployment double-reporting Search every environment's config for the same measurement ID as production. Staging, demo, and old clones should either use their own ID or send no analytics at all.
- Define two or three named conversion events Page views alone don't tell you if the site works. Wire up explicit events for the entry action and the completed goal, so the funnel between them is measurable, not inferred.
- Respect consent before firing anything If the site serves EU or UK visitors, analytics scripts need to wait for consent, or use a cookie-less approach, before sending any hit. Gate the script load behind the consent state rather than firing on page load unconditionally.
Confirm the tag is actually rendered, not just installed
curl -s https://example.com | grep -i -E 'gtag|googletagmanager|plausible|posthog|matomo'Check the measurement ID is not a placeholder
curl -s https://example.com | grep -o 'G-[A-Z0-9]*'
# compare against the vendor's docs example value, e.g. G-XXXXXXXXXXRule out a forked deployment double-reporting
grep -rn 'G-' --include='*.env*' --include='*.ts' --include='*.js' /var/www/<app>Define two or three named conversion events
gtag('event', 'signup_started', { method: 'email' });
// ...
gtag('event', 'signup_completed', { plan: 'free' });Respect consent before firing anything
if (getConsentState() === 'granted') {
loadAnalyticsScript();
}Find this in your own projects, automatically
Heygents runs a read-only Deep Scan across every project you own, finds issues like this one, and hands you a ready-to-run fix an AI agent can execute and verify. A solo developer gets the audit, the backlog and the fix loop in one place.
Open Heygents →Frequently asked questions
How do I know if my analytics tag is really firing, not just present in the code?
Presence in the HTML is necessary but not sufficient. Open the site in a private browser window with no extensions, watch the network tab, and confirm a request actually reaches the vendor's collection endpoint. A tag can be present and still be blocked by a content security policy, an ad blocker, or a misconfigured consent gate.
Why does my dashboard show zero visitors when I know people are visiting?
The most common causes are a placeholder measurement ID left over from scaffolding, an analytics package that was installed as a dependency but never actually rendered into a script tag, or a consent gate blocking the script for every visitor by default. Grep the live rendered HTML rather than the source code to see what's actually shipped.
What conversion events should a small site track at minimum?
Track the entry action that starts a funnel, such as signup_started or checkout_started, and the completed goal, such as signup_completed or purchase_completed. A third event marking a meaningful mid-funnel step, like plan_selected, helps you see where people drop off rather than just knowing that they did.
Can a forked or staging site mess up my production analytics numbers?
Yes. If a fork, demo copy, or staging deployment still carries the same measurement ID as production, its traffic gets counted as if it were real visitors, inflating totals and skewing conversion rates on both sides. Give every non-production environment its own ID or disable analytics there entirely.
Do I need visitor consent before loading analytics scripts?
If you have visitors in the EU, UK, or other regions with similar rules, yes for cookie-based analytics. Gate the script load behind an explicit consent decision rather than firing it on every page load. Cookie-less analytics tools reduce but do not always eliminate this requirement, so check the specific vendor's compliance stance.