The question comes up in an audit, before a pitch, or when a client says they are "definitely not running anything else". The usual answer is a scanner: paste the URL, get a list. Those are useful and they share one blind spot worth understanding before you rely on the output.
What a source scan can and cannot see
Most detectors fetch the page and look through the HTML for known signatures — a
gtm.js snippet, a Meta Pixel base code, an analytics loader. Anything sitting in the
markup is found reliably. Anything that arrives later is not in the markup at all:
- Tags a consent tool injects once somebody answers the banner. Before the choice they do not exist; after it they do.
- Tags fired by other tags. A container that loads a partner pixel, which loads another one. None of them are in the page source.
- Interaction-only tags. A conversion pixel that fires on add-to-cart, a chat widget that loads its own analytics when opened.
- Anything inside an iframe. An embedded booking or checkout widget runs its own tracking in its own document.
The reliable list is not the one in the source. It is the one on the wire: every tracking request the page actually sent, whatever put it there. That list cannot be incomplete in the same way, because a tag that sends nothing is a tag that does nothing.
Reading the requests instead
Open the page with a network view running and use it the way a visitor would — land, scroll, click something, add to cart. Each tracking request identifies its platform by the endpoint it goes to and its account by a parameter inside it. What comes out is a list of vendors and, for each, the ID the page is reporting to.
That last part is what makes the difference between "this site uses Meta" and "this site reports to pixel 000000000000000, and also to a second one nobody mentioned".
Do the walk three times
One pass is not an audit. The same page produces three different lists depending on what it has been told:
- Before answering the banner. Whatever fires here fires without consent, which is the finding that matters most in Europe.
- After rejecting. Should be the same list or shorter. Anything that appears here and not in the first pass is a vendor treating a rejection as an answer to ignore.
- After accepting. The full picture, and the one most scanners approximate.
The gap between the first two is a Consent Mode question rather than a discovery question, and it is the one worth writing down.
What to do with the list
Most audits end with a spreadsheet nobody reads. A shorter useful output is three columns: the vendor, the account it reports to, and whether it fired before consent. That is enough to start a conversation with whoever owns the site, and specific enough that it cannot be waved away.
Questions
Can I see what tags a site uses without access to it?
Yes. Everything a page sends leaves the browser as a network request, and requests are readable by anyone loading the page. No container access, no code change, nothing asked of the site.
Why do scanners miss tags?
Most read the HTML source. A tag injected after load — by a consent tool once you choose, by another tag, or on an interaction — is not in the source and never will be.
Do I need to accept cookies to see the tags?
No, and you should look both ways. What fires before a choice, what fires after accepting, and what fires after rejecting are three different lists, and the difference between them is usually the interesting part.
The rest of this group: Beyond Google
- Meta Pixel and CAPI: why purchases are counted twice
- Test Events for TikTok, Snap, UET and five more
- Tracking inside an embedded widget
Try it on your own site
Tag Master is free, needs no account, and collects no data.
Add to Chrome — Free