Static HTML scans can't see trackers injected at runtime by tag managers. Here's why, and when to use browser-render mode.
Some trackers are hardcoded: the vendor's snippet sits directly in the page HTML, and anyone fetching the page source can see it. Others are injected at runtime: a loader script (a tag manager container, a consent platform, a personalization tool) runs in the visitor's browser and inserts the tracker into the page after the initial HTML arrives.
The default audit is a static scan: it fetches each page over HTTP and pattern-matches the raw HTML. It reliably catches hardcoded snippets and their identifiers — a directly installed GA4 tag, a hardcoded Meta Pixel, the GTM container snippet itself. What it cannot see is anything the page's JavaScript would have injected after load: the tags inside a GTM container, pixels deployed through Tealium or Segment, A/B testing variations, personalization scripts. On a site whose stack runs through a tag manager, the static scan will systematically undercount.
The audit form states the limitation plainly: static scans may miss trackers injected at runtime by JavaScript, with browser-render mode offered as the remedy. We'd rather report an honest partial inventory than a confident wrong one — and the report marks tag-manager-deployed tags as "via Google Tag Manager (client-side tag)" so you know which rows are verified directly and which are inferred.
Each page loads in headless Chromium, scripts execute, and the audit scans the rendered DOM and network requests instead of the raw HTML. One browser per audit, pages rendered sequentially — so it's meaningfully slower than the static scan, and very large audits should use a smaller page budget or run without rendering first to triage. If rendering fails on a page, the static result is used as fallback rather than dropping the page.