The short answer
To check website tracking properly, collect four different kinds of evidence:
Found in public HTML: the page contains a GTM container ID, Google tag, GA4 measurement ID, Google Ads conversion ID, consent clue, or conversion-point markup.
Configured in the live GTM container: the published container contains the expected tag, trigger, variables, identifiers, and blocking conditions.
Observed in a browser: the tag fires – or is correctly blocked – during the intended page load, click, form submission, booking, or purchase journey.
Received by the destination: GA4, Google Ads, or another platform records the expected event and parameters.
Each layer answers a different question. A static scan can discover IDs and suspicious coverage gaps quickly. A GTM inventory explains what the live container is configured to do. Tag Assistant and GA4 DebugView provide runtime evidence. None of those layers should impersonate the others.
The useful output is not a list of scripts. It is a page-by-page evidence matrix and a prioritized queue of checks.
What “tracking is installed” can mean
Teams often use “installed” for four states that are not equivalent.
Evidence state | What it establishes | What it does not establish |
|---|---|---|
Identifier or loader found in HTML | A tracking-related reference was served in the page response | That JavaScript executed, consent allowed it, or an event was sent |
Tag found in live GTM configuration | The published container includes the tag and its wiring | That the container loaded on this page or the trigger conditions occurred |
Tag observed in Tag Assistant | The browser evaluated the container and shows firing behavior for that test | That every user, device, consent state, or journey behaves identically |
Event visible in a destination | The platform received data for the tested event | That naming, parameters, deduplication, attribution, and business meaning are correct |
That distinction prevents two common mistakes: declaring tracking healthy because an ID exists, or declaring tracking absent because a static fetch could not see JavaScript-rendered or consent-gated code.
Start with a measurement map, not a crawler
Before scanning, define the website journeys that matter. A B2B site may need the homepage, pricing, demo request, contact, booking, and thank-you pages. Ecommerce may need category, product, cart, checkout, and confirmation pages.
For each journey, record:
the business outcome
the page or interaction where it occurs
the expected platform destination
the expected identifier, event name, or conversion action when known
the consent state that should allow or block collection
the human owner who can validate the result
This becomes the expectation column in the audit. Without it, AI can tell you what it found but not whether the implementation covers the business.
Include confirmation pages explicitly when they are not linked from the public site. Do not submit real customer information during testing. Use approved test details and a test environment where the journey changes production data, inventory, or bookings.
A reliable website tracking audit workflow
1. Select representative pages
Start with the base URL and a small set of high-value journeys. A useful first pass usually includes:
homepage
pricing or product page
contact or demo page
form or booking page
checkout page where applicable
confirmation or thank-you page
Do not crawl hundreds of pages before understanding the signal. Coverage patterns across a few representative pages often reveal inconsistent container IDs, missing loaders, broken redirects, or pages that need browser testing.
2. Scan the publicly served HTML
Ask the AI to scan public pages for tracking and conversion-point signals. Capture each page’s requested URL, final URL after redirects, HTTP status, and any page-level error.
Useful discovery signals include:
GTM container IDs and install-loader clues
GA4 measurement IDs and Google Ads conversion IDs
legacy Universal Analytics IDs
the Google tag loader
forms, telephone links, email links, and embedded frames
recognizable form and booking providers
consent-management signals
JavaScript-framework clues
Keep the raw page-level findings. A cross-page summary is helpful, but it can hide the exact URL where a different container appeared.
3. Compare coverage across pages
Create one row per page and one column per expected signal. Then flag:
no GTM ID on an important page
multiple GTM IDs across the site
the same container appearing more than once in executable loader positions
a GA4 or Google Ads ID that changes between comparable pages
legacy Analytics identifiers that still appear
forms or booking widgets without an obvious measurement path
redirects that move the visitor to another domain or page family
failed or blocked page fetches
Treat duplicate and inconsistency flags as review candidates. Themes, consent tools, server-side rendering, embedded applications, serialized code, and intentional multi-container designs can produce confusing evidence. Inspect before removing anything.
4. Downgrade confidence when static evidence is incomplete
A static HTML scan does not run the page. It cannot wait for a consent choice, execute client-side JavaScript, click a button, submit a form, complete a booking, or trigger a single-page-application route change.
If the scan detects a JavaScript framework, embedded application, consent manager, login boundary, or interaction-based conversion, mark negative findings as inconclusive. “Not found in the initial response” is the accurate statement. “Tracking is missing” is not.
Also remember that direct gtag.js implementations may not use GTM at all. The absence of a GTM-* identifier does not prove the site is unmeasured.
5. Resolve the container and inspect the live configuration
When the public scan finds a GTM ID, resolve it to the accessible account and internal container. Then inspect the live published inventory – not an arbitrary workspace – when the question is what production visitors should receive.
Review:
Google tags, GA4 event tags, and Google Ads conversion or remarketing tags
tag identifiers, event names, and conversion labels
firing and blocking triggers
trigger conditions
paused state
variables that supply URLs, selectors, values, IDs, or event parameters
folders and naming patterns that help establish ownership
A workspace may contain unpublished changes. Inspect it only when reviewing work in progress, and label it as unpublished. Do not describe workspace inventory as the production setup.
6. Reconcile the website evidence with GTM wiring
Compare what the public pages served with what the live container contains.
Pattern | Plausible explanations | Next check |
|---|---|---|
GTM ID appears across pages and the live inventory contains expected tags | Basic installation and configuration evidence exists | Run the real journeys in Preview mode |
GTM ID is absent on one important page | Separate application, template gap, consent gating, blocked fetch, or missing snippet | Open the page in a browser and inspect the network and DOM |
Website ID differs from the intended live container | Old deployment, separate property, environment mix-up, or intentional multi-container setup | Confirm ownership and deployment before editing GTM |
Tag exists in GTM but no public container loader is found | Static-scan limitation, consent or JavaScript loading, or missing deployment | Test page load in Tag Assistant and browser developer tools |
Form exists but no matching tag or trigger is visible | Measurement may be direct-coded, server-side, embedded, or absent | Submit an approved test and inspect runtime events |
Duplicate installation is suspected | Theme/plugin duplication, repeated loader, or false-positive source reference | Count executable loaders and verify firing order before removing code |
Legacy Universal Analytics ID appears | Old code, plugin, or migration residue | Confirm whether it sends requests; remove only after dependency review |
This step narrows the runtime test. Instead of “check the whole site,” the analyst can test one page, one trigger, one consent state, and one destination.
7. Validate the critical journeys in a browser
Use GTM Preview mode and Tag Assistant for the important paths. Google’s debug interface shows which tags fired, which did not, their order, trigger decisions, and the data processed during the session.
For each journey, record:
page and device
consent state
action performed
expected tag and event
observed firing or blocking status
important parameters and values
duplicate firing
destination receipt
For GA4, use DebugView to confirm that the test device’s events and parameters arrive. A tag marked “fired” in Tag Assistant is valuable evidence, but destination receipt closes another gap in the chain.
Test more than the happy path when the implementation depends on consent or redirects. At minimum, check the relevant accepted and denied consent states, mobile and desktop where behavior differs, and the final confirmation step.
8. Produce an evidence-based action queue
Classify each issue by evidence strength and risk:
Confirmed: directly observed in the relevant layer
Likely: several signals agree, but runtime or destination evidence is missing
Inconclusive: the method cannot see the required behavior
Expected: the tag is correctly absent or blocked for the tested state
Prioritize high-value journeys, broken destination receipt, missing sitewide base tags, inconsistent production containers, duplicate conversions, and privacy-sensitive consent behavior. Put naming cleanup and organizational debt below revenue or compliance risk unless they are causing errors.
Every action should include the affected page or journey, evidence, next test or proposed repair, owner, and review gate. Do not let AI publish a GTM change merely because a pattern looks suspicious.
The exact prompt
Copyable prompt
Audit the tracking installed on my public website. Start with [BASE_URL]. Do not change Google Tag Manager or the website.
1. Discover and scan up to six representative public pages, prioritizing the homepage, pricing or product, contact or demo, booking or form, checkout, and confirmation pages. Force-include these known pages: [ADDITIONAL_URLS].
2. For every page, show the requested URL, final URL, HTTP status, page-level errors, GTM container IDs and loader signals, GA4 measurement IDs, Google Ads conversion IDs, legacy Universal Analytics IDs, Google tag clues, forms, telephone and email links, embedded frames, recognized form or booking providers, consent signals, and JavaScript-framework clues.
3. Produce a page-by-page coverage matrix. Flag inconsistent identifiers, suspected duplicate GTM installation, failed pages, redirects, and important conversion points that need deeper review. Treat every flag as a review candidate, not a confirmed defect.
4. Explicitly label static-scan limitations. If JavaScript, consent, login, an embedded application, or an interaction may hide a signal, say “not visible in static HTML” rather than “missing.”
5. If a GTM ID is found and I have access, resolve it to the matching account and container. Inspect the live published container inventory. Keep workspace configuration separate and label it unpublished if I ask for it later.
6. Compare the website evidence with the live GTM tags, firing and blocking triggers, important conditions, variables, identifiers, event names, labels, paused state, and folders.
7. For each business journey, classify the evidence as found in public HTML, configured in live GTM, observed firing, received by the destination, or still unverified. Do not infer later layers from an earlier one.
8. End with a prioritized browser-QA plan for Tag Assistant and the relevant destination debug view. Include page, device, consent state, action, expected tag or event, parameters, and pass condition.
9. Produce a final action queue with confidence, business risk, owner, and human review gate. Do not create, edit, version, or publish anything.How HireOtto helps with this audit
HireOtto can scan public website HTML without requiring a GTM platform connection. It starts from the supplied site, uses sitemap discovery when possible, falls back to homepage links, and prioritizes likely conversion pages. The default is six pages, with a maximum of ten; you can force-include known pages such as an unlinked thank-you URL.
The scan can surface GTM, GA4, Google Ads, and legacy Analytics identifiers; forms, phone and email links; embedded providers; consent and JavaScript-framework clues; redirects; page errors; inconsistent IDs; and suspected duplicate installations.
When you connect the read-only GTM server, HireOtto can resolve an accessible public container ID, inspect the live or selected workspace inventory, join tags with firing and blocking triggers, and export the wiring. That makes it practical to compare what the site served with what the container is configured to do.
HireOtto cannot execute the page, choose consent, click or submit elements, prove runtime firing, confirm destination receipt, edit GTM, create a version, or publish. A practitioner must validate critical journeys in Tag Assistant and destination tools, decide whether an apparent inconsistency is intentional, and approve every repair.
Use the GTM tools reference for the website-scan inputs and limits, the container inventory guide for live-versus-workspace review, and the GTM quickstart for connection steps. To add HireOtto to a new AI client, follow Connect a HireOtto server.
What the final audit should look like
The audit should preserve the evidence chain instead of collapsing it into “working” or “broken.”
Field | Required output |
|---|---|
Journey | Page, device, consent state, action, and business outcome |
Public-page evidence | Served identifiers, loader clues, form or booking signals, redirects, and scan limitations |
GTM evidence | Live tag, trigger, blocking condition, important variables, and source context |
Runtime evidence | Tag Assistant firing or blocking result and relevant parameters |
Destination evidence | Received event, timestamp, parameters, and any processing caveat |
Conclusion | Confirmed, likely, inconclusive, or expected |
Next action | Owner, priority, exact test or repair, and approval gate |
That format is useful to the PPC operator, analytics owner, developer, and privacy reviewer. Each person sees the same journey without treating a source-code clue as a completed implementation.
Common mistakes
Checking only the homepage
The homepage may use a different template from checkout, booking, authentication, or embedded applications. Include the pages where business outcomes actually happen.
Treating View Source as runtime truth
View Source shows the initial response. Modern sites can add tags, forms, and routes after JavaScript executes. Consent may also change what loads. Use static evidence to choose browser tests.
Inspecting a workspace and calling it live
Workspaces contain unpublished configuration. Use the published container for production-state questions and preserve the source label in every conclusion.
Removing a suspected duplicate immediately
A repeated identifier in HTML can come from serialized source, a plugin, a theme, a real duplicate loader, or an intentional setup. Confirm executable loaders and firing behavior first.
Proving firing but not receipt
Tag Assistant can show that a tag fired. Confirm that the destination received the correct event and parameters, especially for conversions that affect reporting or bidding.
Frequently asked questions
Can AI tell whether a website has Google Analytics?
It can detect common GA4 or Google tag identifiers in accessible public HTML and inspect related GTM configuration. A negative static result is inconclusive when the site loads tracking through JavaScript, consent, an embedded application, authentication, or server-side measurement.
Can the scan prove that a conversion tag fires?
No. A static scan does not execute the interaction. Use GTM Preview mode and Tag Assistant to observe the trigger decision, then confirm receipt in the destination.
Does the website scan require Google Tag Manager access?
No GTM authorization is needed to read publicly served HTML. A connected HireOtto server and eligible access are still required. GTM access is needed when you want to resolve an accessible container or inspect its configuration.
What if the site does not use GTM?
Direct Google tag installations and other tag managers are possible. Inventory the identifiers and network requests that exist, then adapt the runtime validation. Do not interpret “no GTM ID” as “no tracking.”
Should every page have the same tracking identifiers?
Often, a sitewide base implementation should be consistent. But multiple applications, domains, regional properties, consent requirements, and intentionally separate containers can make variation legitimate. Verify the measurement design before standardizing it.
About Me
I’m Suyash – badminton junkie, ex‑GroupM ad‑ops grunt, first marketer at a B2B SaaS startup, and creator of Hiretto: MCP servers for performance marketers.
My mission: less clicking, more thinking.
Let’s build leverage together.