Understand analytics coverage across monitored pages

The Analytics section of Site Resources summarizes supported measurement packages found across enabled monitored pages with stored page-check snapshots. It helps identify uneven deployment. It is not an inventory of every URL and does not itself open a site-resource incident.

Understand the denominator

Coverage is calculated from the latest stored analytics values for enabled monitored pages that have check snapshots. Each package's percentage is:

pages where the package was detected / checked enabled monitored pages

The result is rounded to the nearest whole percentage. Packages are sorted by highest coverage, then alphabetically. A package counts once per page even if that page contains several property IDs for it.

For example, Google Tag Manager on 9 of 10 checked pages shows 90% coverage. If only 4 enabled monitored pages have snapshots, those 4 form the denominator. Disabled pages are excluded.

The card says Not checked yet when no enabled monitored page has a snapshot. It says No supported analytics detected when snapshots exist but none contains a supported, sufficiently confident detection. Neither label is a failure by itself.

Coverage is not updated by the daily site-resource request. It changes when normal page checks complete and store new snapshots. Selecting Check now in Site Resources does not crawl all monitored pages or recalculate tags from live HTML independently.

Understand what detection examines

During a page check, TechDash can examine raw and rendered HTML, script URLs, browser network requests, inline JavaScript, and selected fallback markup.

Detectors combine vendor script locations, initialization calls, requests, and identifiers. Low-confidence matches are discarded. Some vendors can be detected without a property ID. Google Analytics requires a valid G- or UA- identifier plus corroborating activity. Google Tag Manager uses a valid GTM- container ID. A gtag('config') stub without the expected script or collect activity is ignored.

Supported names include Google Analytics, Google Tag Manager, Microsoft Clarity, Hotjar, Cloudflare Web Analytics, Matomo, Plausible, Adobe Analytics, Piwik PRO, Fathom, Simple Analytics, and other registry entries.

Google Analytics rows distinguish Google Analytics (v4) and Universal Analytics when IDs identify the product. Paid-media IDs such as AW-, DC-, and GT- are excluded. Meta Pixel and other paid-media pixels are not part of this analytics registry.

Detection proves only that relevant code or network activity was observed. It does not prove consent was granted, hits reached the property, configuration is correct, or reports are accurate.

Read the related page checks

Coverage is descriptive. Analytics and tag presence is evaluated per page crawl:

• Good means analytics tags are stable against the prior page snapshot, or no comparable removal or change exists. The first observed state establishes a baseline.
• Analytics tags removed is Warning when a previously detected analytics vendor or tag manager disappears entirely from the page. Measurement of organic performance can be lost even though rankings are not directly affected.
• Analytics tags changed is Advisory when a vendor, property ID, or container ID changes while supported analytics remains. Historical reporting can split or become difficult to compare.

Evidence shows the URL plus Expected and Current package or identifier summaries. If Google Tag Manager remains but Google Analytics disappears, the message distinguishes them.

Analytics comes from completed snapshots. Not checked yet means no snapshot exists, not that a check passed. No supported analytics detected means snapshots exist but yielded no supported detections.

Use coverage to investigate deployment

A package below your intended coverage often points to:

• A tag missing from one CMS template
• Consent behavior that differs by page or test conditions
• A script blocked by Content Security Policy, a CDN, or an extension
• A container present without the expected analytics product
• Pages checked before a recent deployment
• Deliberate exclusions, such as checkout or privacy-sensitive pages

Identify which enabled pages contribute to the row and which have no detection. Compare raw and rendered behavior, consent state, script loading, requests, and expected IDs.

Missing analytics can damage measurement and decision-making, but TechDash does not classify it as a direct search-ranking failure. Decide the required package and coverage based on your measurement plan. A marketing site may target full coverage, while account, payment, or consent pages may intentionally differ.

Benign cases include intentional exclusions on checkout or account pages, consent behavior, planned property migrations, or different products by template.

For an unexpected removal, restore the script or container and check Content Security Policy, CDN, consent, and request blocking. For an unexpected ID change, confirm the intended property and correct the deployment.

Verify coverage and incidents

Do not use Check now in Site Resources to verify analytics. It does not run monitored pages or independently recalculate tags.

Use Run now for affected pages, wait for new snapshots, confirm Analytics and tag presence is Good or an intentional change is documented, then verify package names and coverage in Site Resources.

If the percentage still looks stale, verify that the intended pages are enabled and have completed snapshots. Coverage can legitimately remain below 100% when exclusions are deliberate.

Related articles

• Understand analytics and tag checks