A tracking script can be visible in a page while purchases never reach the right reporting account. The reverse is also possible: a service may work through a setup that a public HTML scan cannot see. Counting detected tools is therefore an inventory exercise, not a measurement-quality verdict.
Begin with a question such as “Does a completed signup produce one event in the intended property?” Use the Sitelemetry report to locate evidence and possible gaps, then verify the actual journey with authorized access to the relevant systems.
What this audit covers
What can be measured
- Static HTML and response headers from the requested page and, when enabled, one additional linked page.
- Public signatures for analytics, advertising pixels, consent tools, tag management and selected verification methods.
- Selected tracking-cookie, insecure-resource, data-pattern and form-privacy review signals.
What it cannot prove
- No execution of client-side tags or proof that an event reaches a provider.
- No access to analytics accounts, tag-manager containers, ad accounts or Search Console permissions.
- Not a full consent assessment, legal opinion or confirmation that a detected product is configured correctly.
Integrations audits are available on Starter, Professional and Enterprise. A detected tool does not unlock or verify that provider account; provider access remains separate.
Define the intended inventory first
List the systems the website is supposed to use: analytics, advertising, a consent manager, customer support and any server-side measurement. Assign an owner and an expected purpose to each. A brochure site may intentionally avoid advertising pixels; their absence is not automatically a defect. An abandoned campaign tag may be less useful than a smaller, well-understood stack.
Then choose a representative public page and a business event to investigate. Separate a page view, form submission and confirmed purchase in your notes. They describe different moments and should not become interchangeable conversions. Keep a record of the expected destination property and event name without publishing private identifiers or customer payloads.
Know the public scan's boundary
Sitelemetry examines delivered HTML and response headers without running the page's JavaScript. The current flow starts with the requested page and can inspect one additional same-site linked page when enabled. Its report identifies the pages actually assessed; do not assume it crawled every template or completed checkout.
Detection includes signatures for analytics, advertising, behavior tools, consent platforms and tag management. Selected search-engine verification signals can also be observed in HTML, headers or DNS. These are public observations. A verification token does not prove that your colleague has access to a Search Console property, and an absent token does not exclude other supported verification methods. Check ownership through the provider's verification process.
Separate presence, absence and failure
“Analytics observed” means recognizable evidence was found in the assessed response. It does not establish that the script executed, consent permitted its behavior, a request succeeded or a provider accepted the event. “Not observed” means the scan did not see the checked signals; server-side delivery, runtime injection and other pages remain possible explanations.
A challenge screen or unavailable page is a measurement problem, not evidence that every integration is missing. DNS timeouts likewise differ from a completed check with no observed record. Read the status and evidence before escalating a finding. If the report identifies an insecure tracker URL, first confirm that it is an active dependency rather than unused markup, then investigate its effect in the browser.
| Observation | Contextual priority | Evidence to confirm | Next action |
|---|---|---|---|
| An event reaches the wrong property | High when confirmed for a business event | Browser request plus authorized provider receipt | Correct the destination and retest once and on retry |
| A tag is not detected | Unconfirmed; not automatically a defect | Check expected architecture and actual event delivery | Verify runtime, server-side or other-page implementation |
| A consent platform signature is present | Further behavior review required | Observe before choice, rejection and acceptance | Check whether actual transmission follows the intended choice |
Trace one event from action to destination
- Open a clean browser session on a site you are authorized to test. Note the consent state and any extensions that alter requests.
- Complete the chosen action once. Inspect the browser network and the provider's debugging tools, using test data.
- Confirm the intended event name, destination and relevant values. Check that a click is not being counted as a completed transaction.
- Check for duplicates after refresh, redirects and retries. For client/server combinations, inspect the provider's deduplication behavior.
For Google Tag Manager, the data-layer documentation explains how events and variables enter the container. Seeing dataLayer in HTML is not proof that a particular action pushes the right values. Fix the responsible trigger or integration rather than adding another tag blindly.
Review consent and personal-data signals carefully
A consent-manager signature establishes presence, not that every choice is respected. Test a fresh session before a choice, after rejection, after acceptance and after a later change. Compare actual tag behavior with your intended configuration. Google distinguishes obtaining a choice from communicating and honoring it in its consent-mode overview; configuration order also matters in its implementation guide.
Sitelemetry can flag patterns resembling personal data near tracking calls or selected cookies in the HTTP response. Treat these as investigation evidence, not an automatic legal verdict. Identify the destination and applicable product rules before changing data. Hashing a value does not automatically make every use permissible. A form-privacy observation similarly calls for review of notice and consent design, not a jurisdiction-specific conclusion.
Retest the configuration, then trust the report
After a change, rerun the same pages to verify that the public evidence changed as intended. Repeat the browser journey and confirm the event in the authorized provider interface. Preserve a small evidence record: tested action, consent state, expected event, observed destination and duplicate check. Avoid putting real email addresses, tokens or payment details in shared screenshots.
Close findings only when their specific claim is resolved. A removed script may clean up inventory while also removing a required conversion. A higher integrations score does not demonstrate accurate attribution, complete event delivery or compliant data handling. Review the stack again after consent changes, new campaigns and checkout updates, because those are concrete opportunities for measurement to drift.
Common questions
Does a detected analytics tag mean analytics works?
No. Detection establishes a public signal. Execution, event values, consent behavior and provider receipt need separate validation.
Does a Search Console token prove I have access?
No. It shows a verification-related artifact. Account ownership and current permissions must be checked with the provider.
Is a missing consent-tool signature a legal violation?
Not by itself. The scan cannot establish all processing, user states or applicable obligations. Review the actual implementation and its context.
Sources & further reading
- Google: the data layerdevelopers.google.com
- Google: consent-mode overviewdevelopers.google.com
- Google: implementing consent modedevelopers.google.com
- Google Search Console: verifying ownershipsupport.google.com
Written by the Sitelemetry team, checked against the product’s audit scope and linked primary sources. Examples are illustrative unless an observed case is explicitly identified.
