Open the page, view source, and there it is: the tracking snippet, sitting in the head, carrying the right ID. Job done, right? It is easy to think so. We built a check that tests for exactly that one thing, a string in a page's source, and nothing else. It passes every time someone pastes the snippet correctly, and it has nothing to say about whether the property behind that ID ever recorded a single visit.
The gap decides whether any report you read means something. Every dollar spent on ads and every hour spent writing a page meant to rank gets judged against a report pulled from that property. A property collecting nothing cannot judge any of it, no matter how carefully the report itself is built. A decision made against a broken report was never tested at all. The fix means watching the browser, not the source.
The short answer
- A tag in your page source proves it was installed, nothing about whether it works.
- Three quick checks from your browser prove whether data is landing in the property.
- A presence check can also miss a second copy of the tag hiding inside a tag manager container.
Why a tag in the source proves nothing
A build check that scans a deployed page for the right analytics ID proves exactly one thing: the string is there. Ours does that and stops. It never opens a browser, never fires a request, and never asks the analytics property whether it received anything. A page can pass that scan on the same day its property has been silently empty for a month.
There are a handful of reasons a string can be perfect and a property can still be quiet. A consent banner can block the request until someone clicks accept, and in the stricter setup a quick test visit that never clicks accept sends nothing at all. Run the test in a private window with extensions off. A blocker on your own machine hides the very request you are looking for.
A string in the page source is a receipt, not a pulse.
A tag manager container can also hold a version with the right ID that was saved but never published, so the code sits there, correct and inert. None of these show up in a scan of the page's source. They only show up once you watch what the browser does after the page loads, the part a source scan was never built to see, no matter how many times you run it.
The three checks you can run in about ten minutes
You do not need developer access. A browser and a login to the property whose reports you read cover all three checks, start to finish. Watch one network request fire when the page loads. Watch that same visit land in a real time report. Then come back a day later and confirm the property still shows it.
The ten minute check
-
Load the page with the network panel open
Open developer tools, filter the network tab for the word collect or the word google, then load the page in a private window so old data and browser extensions stay out of the way. You want to see exactly one request fire when the page loads, not zero and not several.
-
Watch your own visit land in real time
Open the property's real time report in a second tab and reload the page you just tested. Your visit should show up as an active user within a few minutes. If it never appears, the request left the browser but never reached the property it was aimed at.
-
Come back the next day and check the standard report
Real time only proves the pipe is open right now. Wait a day or two, then look at the standard report for that same page. If your test visit shows up there too, the property is receiving data and keeping it.
A few things can make this check lie to you. Rule them out before you trust the result. Test from a private or incognito window, since a browser extension built to block trackers will block your own test the same way it blocks everyone else's. Give the real time report a few minutes before deciding it failed. A report does not update the instant a request lands, and a check called too early looks the same as one that genuinely failed. Google says the standard report can take 24 to 48 hours to process, so an empty report on the same day usually just means the data has not caught up yet.
One more case is easy to miss on a modern site built with client side page transitions. A tag can fire correctly on the very first page load and then go quiet on every page after that. The page content swaps without a full reload, and nothing tells the analytics script a new page just appeared. A site does not have to call itself an app to behave this way. Test by clicking through to a second page inside the site instead of only loading the first page directly.
What each result tells you
A failed check rarely means the same thing twice. No request at all means the tag never loaded or something blocked it before it could run. A request with no matching real time hit usually means the wrong ID is wired into the page. A real time hit that never reaches the standard report points to a filter inside the property, not a broken install.
Laid out side by side, the pattern is easier to check against your own result.
| What you see | What it means | Where to look next |
|---|---|---|
| No network request fires | The tag never loaded, or something blocked it before it could run | Check consent settings and any ad or privacy blocker on your test browser |
| A request fires but real time stays empty | The request carries the wrong property or measurement ID | Compare the ID in the page source against the ID shown in the property's own settings |
| Real time works but the standard report is still empty after two days | A filter inside the property is removing the traffic, for example an internal traffic filter | Check the property's data filters for a rule that matches your own connection |
A stale internal traffic filter survives a redesign because nobody re-checks old settings once only the pages and the design change. The wrong ID follows a copied template because the snippet still looks right sitting in the page, even when it points at the wrong property. A blocked request is the one you cannot fix from your side alone, since it depends entirely on a visitor's own browser choices and privacy settings. The fix is faster than the find.
The check a source scan will never catch
A presence check confirms the right analytics ID sits in the page. It says nothing about a second copy of that tag, or a different tool entirely, pasted into a tag manager container weeks or months later by someone else. A second copy of the same analytics tag on one page double counts some events, and neither number can be trusted again after that.
This is the gap a build check cannot close by scanning harder. The extra tag is not wrong. It is just unexpected. To a machine reading the page it looks like any other tag. It takes a person, on a schedule, opening the container and reading what is inside it. List every tag inside it and match each one against what the build check expects to find.
A duplicate shows up the same way: a well meaning teammate or a new agency adds a tag through the container's own interface, not realizing an identical one is already built into the page itself. The person adding it has no reason to think anything is wrong, which is exactly why a scheduled look is the only thing that catches it.
Make this a standing habit
A quick check like this one is worth little if you only run it once, at launch. Templates get swapped during a redesign, and a tag manager container gets edited by more than one person over time. A tag rarely announces its own failure. Treat a quiet property as a reason to stop trusting a report and start checking it again.
Every check above touches the same three tools, worth keeping on one short list.
What this check touches
None of this replaces a second set of eyes when the numbers still do not add up after every check above comes back clean. When the wiring itself turns out to be the problem, tracking setup like this is part of what our technical SEO work covers, especially on a site that has changed hands or agencies more than once. When the pipe is fixed but paid traffic still is not converting the way the spend suggests it should, that is a question our Google Ads work looks at next.
Either way, checking a quiet analytics property comes down to one short, ordered list to run now and a second, shorter list to run four times a year, whichever one you happen to be behind on. If you want help closing the gap, get in touch.
Talk to Offer before you decide anything.
You'll talk with Offer, not a sales rep. A short call, no pitch deck.
Talk to OfferThis post was drafted with AI tools from our own project records, anonymized, and checked by us before it published. Read our editorial standards.
