A tracking audit loads your page the way a browser does, inventories every analytics and advertising script it finds, and then tests seventeen specific things about how those scripts are configured. It answers one question: is the measurement on this page complete, compliant, and clean enough to trust? Below is every check, what a pass and a fail actually mean, and — just as important — the things a page-level audit cannot see.
What an audit actually looks at
The audit fetches your URL, renders it, and reads two things: the HTML that comes back, and the scripts that page loads. From those it extracts measurement IDs, container IDs, pixel initialisations, consent calls, and the total byte weight of everything tracking-related.
That is a deliberately narrow lens, and it is the right one for a first pass. A large share of real tracking failures are visible from the outside — a missing measurement ID, a pixel that was never initialised, a consent signal that never fires, a debug container shipped to production. You do not need account access to catch any of those.
Every check returns one of three statuses:
| Status | Meaning |
|---|---|
| Pass | The thing is present and configured the way it should be. |
| Warn | Missing or unusual, but legitimately optional — you may not run TikTok ads. |
| Fail | Broken, non-compliant, or actively leaking. Fix these first. |
Foundation: is measurement even present?
1. GA4 measurement ID. The audit looks for a loaded GA4 measurement ID (the G-XXXXXXX identifier). No ID means no analytics — nothing else in your reporting stack matters if this fails. This is the single most common hard failure on small-business sites, usually because the tag was installed on a staging theme that later got replaced.
2. GTM container. A container ID (GTM-XXXXXXX) that is actually loading. This one warns rather than fails, because tags hardcoded directly into your HTML do work. They are just far harder to audit, change, or govern — every edit becomes a developer ticket and a deploy. See what Google Tag Manager actually is if you are deciding whether you need one.
3. Tracking on deep pages. The audit also fetches one page past the homepage — a product, collection, or article — and checks that the same measurement IDs load there. A surprising number of sites are tracked on the homepage only, because the tag was added to one template and never to the others. Everything downstream of that page is invisible to analytics.
4. DataLayer initialised. Does the page create window.dataLayer before the tag manager loads? Most templating frameworks do not do this for you, and a dataLayer that is initialised after GTM loads silently drops the events pushed before it. Warn, not fail — but it is the root cause of an enormous share of "the event fires sometimes" bugs.
Consent and privacy
5. Consent Mode v2. The audit looks for gtag('consent', …) calls in the initial HTML. Since March 2024, Google requires these signals to keep serving personalised advertising and remarketing to EEA and UK users. No signals means your EU conversion data degrades and your remarketing audiences stop filling. This is a fail, not a warning.
6. Consent banner. A recognised consent-management platform (OneTrust, Cookiebot, Osano, and dozens more) loading on the page. A banner without Consent Mode v2 wiring is theatre; Consent Mode v2 without a banner has nothing to read. You generally need both.
7. Consent on custom pixels. Tags added through the native GTM templates inherit Consent Mode handling automatically. A pixel pasted into a Custom HTML tag gets none of that: it fires exactly when its trigger says, including for visitors who refused tracking. The audit reads the published container and flags advertising pixels deployed this way without a consent gate.
8. PII in URL. The audited URL is scanned for anything that looks like an email address or phone number. This one matters more than people expect: a URL is sent to every analytics and advertising pixel on the page as the page location. One checkout confirmation page with the customer email in a query string leaks that email to Google, Meta, and everyone else in your stack simultaneously — and it is a documented cause of Google deleting analytics data. Keeping PII out of GA4 covers the cleanup.
Advertising pixels
9. Meta Pixel. Whether fbq is initialised on the page.
10. TikTok Pixel. Whether the TikTok pixel loads.
11. Google Ads conversion tag. Whether an AW- conversion ID is present.
All three warn rather than fail when absent, because not advertising on a channel is a perfectly good reason not to have its pixel. What they catch is the expensive version of this problem: you are spending on the channel, and the pixel quietly disappeared during a theme update. Ad platforms do not tell you that conversions stopped arriving — they just optimise worse, month after month.
Commerce and double counting
12. Purchase event carries revenue. When the container has a GA4 purchase tag, the audit checks that it is wired to send a value. A purchase event with no revenue attached still counts as a conversion, so the event count looks healthy while revenue reports and ROAS read zero. This is the failure that survives the longest, because nothing in the data looks obviously broken.
13. Duplicate GA4 event tags. The same event name wired to two live tags in the container. Usually one was added by a developer and one by a marketer, neither aware of the other. It inflates conversions and teaches advertising platforms to bid on numbers that do not exist.
Hygiene, performance, and leaks
14. Tracking script weight. The total bytes of identified analytics and tag-management scripts. Under 200 KB passes; 200–400 KB warns; above 400 KB fails. This is not pedantry — tracking scripts are render-blocking often enough to move your Largest Contentful Paint, and Lighthouse penalises the page accordingly. Sites that fail this check usually have three overlapping analytics tools nobody has audited in two years.
15. GTM debug mode. The presence of gtm_preview or gtm_auth parameters on your production container URL. This means real customer traffic is loading a debug container — data goes to the wrong place, and anyone can read your container configuration. Rare, always serious, always a fail.
16. HTTPS. The page must be served over HTTPS. Over plain HTTP, cookies set by analytics and advertising pixels cannot be marked Secure, and Consent Mode v2 does not behave correctly.
17. Single GA4 property. More than one distinct GA4 measurement ID on the same page. Occasionally deliberate (a parallel property during a migration), far more often the fingerprint of two installs stacked on top of each other — one from your theme, one from an app or plugin. The result is inflated sessions and double-counted conversions.
How the score is calculated
The score is earned weight divided by achievable weight, not divided by a fixed total. Checks are weighted by how much user-facing damage the failure causes: a missing GA4 ID or leaked PII costs far more than an absent TikTok pixel.
The practical consequence: checks that legitimately do not apply to you are excluded from the denominator, so a business that does not advertise on TikTok is not permanently capped below 100%. A warn earns partial credit. A fail earns none.
What a page-level audit cannot see
Being honest about the boundary is what makes the result useful:
- Server-side events. Conversions API and Measurement Protocol calls happen server to server. Nothing about them is visible in your HTML.
- Events behind interaction. Add-to-cart, form submissions, and checkout steps fire after a click. A single-page fetch never triggers them.
- Consent-gated tags. Tags correctly held back until consent is granted look identical, from outside, to tags that are broken.
- Logged-in and checkout flows. The most valuable pages are usually the ones a crawler cannot reach.
- Payload correctness. An audit can confirm a purchase tag exists. It cannot confirm the revenue value it sends is right.
That second layer is what container-level auditing and synthetic journeys are for: they log in, click through a real funnel, and record what actually fired with what values.
How to act on the result
Work in this order, because it maps to how the damage compounds:
- Fails involving privacy or leaks first — PII in URL, missing Consent Mode v2, exposed debug mode. These carry legal and account-level risk, not just reporting noise.
- Missing foundational measurement next — no GA4 ID, no dataLayer. Nothing downstream can be fixed while these are broken.
- Pixels for channels you actually pay for. Every day a pixel is missing is a day of ad spend optimising blind.
- Weight and duplicates last. Real, but they degrade quality rather than eliminate it.
Then re-run the audit after each change. The most common outcome is not a single dramatic bug — it is four small ones that have been quietly compounding since the last theme update.
FAQ
How long does a tracking audit take?
A page-level audit like this one takes a few seconds — it fetches and parses a single URL. A full container audit, which reviews every tag, trigger, and variable in your GTM container, takes longer because it needs account access.
Do I need to give an audit tool access to my analytics account?
Not for the seventeen checks described here. They all run against publicly available page output, which is why the free audit works on any URL, including your competitors. Deeper checks — tag inventory, container drift, event payload validation — do require an authorised connection.
What score should I be aiming for?
Above 80% is a healthy configuration. Below 60% almost always means at least one hard failure that is costing you conversion data right now. Because the score is calculated against achievable weight, 100% is a realistic target rather than a theoretical one.
Why does my site show a warning for pixels I do not use?
Because a page-level audit cannot know your media plan. A missing TikTok pixel on a site that never advertises on TikTok is correctly a warning, not a failure, and it does not reduce your achievable score.
How often should I re-run an audit?
After every theme update, plugin install, site migration, or checkout change — those are the four events that break tracking most often. Beyond that, monthly is enough for most sites, and continuous monitoring is worth it once ad spend is meaningful.
Run the same thirteen checks against any URL with the free tracking audit — no signup, results in seconds.