Analytics Not Installed or Not Firing

Without analytics, every business decision about your website becomes a guess. You can't see which pages convert, where users drop off, which channels drive traffic, or whether changes improve performance. This is the foundation of data-driven optimization — if it's missing, you're flying blind.

Start here

Before You Fix It: What This Check Means

Instrumentation quality determines whether growth and conversion decisions are based on trusted data. In plain terms, this tells you whether you can trust your traffic and conversion numbers before making growth decisions. Scavo inspects script sources and inline scripts for known provider fingerprints, then looks for Google IDs.

Why this matters in practice: operational drift here often causes hard-to-debug regressions across environments.

How to use this result: treat this as directional evidence, not final truth. Page-level markers cannot prove full event taxonomy quality or downstream warehouse correctness. First, confirm the issue in live output: verify events in debug tooling and backend logs with dedupe checks Then ship one controlled change: Keep analytics bootstrap in shared layout/head partials. Finally, re-scan the same URL to confirm the result improves.

TL;DR: No analytics tool (GA4 or similar) is detected on your pages, meaning you can't track visitor behaviour or measure performance.

Without analytics, every business decision about your website becomes a guess. You can't see which pages convert, where users drop off, which channels drive traffic, or whether changes improve performance. This is the foundation of data-driven optimization — if it's missing, you're flying blind.

What Scavo checks (plain English)

Scavo inspects script sources and inline scripts for known provider fingerprints, then looks for Google IDs.

Current logic:

  • Info: page HTML unavailable, so the check cannot run
  • Warning: no common analytics/tag-manager providers detected
  • Warning: Google signals detected but no GA4 ID (G-...) or GTM container ID (GTM-...) found
  • Pass: provider signals detected and no ID/visibility warning triggered

Scavo stores useful detail fields, including provider labels, sampled script sources, and discovered GA4/GTM IDs.

How Scavo scores this check

Scavo assigns one result state for this check on the tested page:

  • Pass: baseline signals for this check were found.
  • Warning: partial coverage or risk signals were found and should be reviewed.
  • Fail: required signals were missing or risky behavior was confirmed.
  • Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.

In your scan report, this appears under What failed / What needs attention / What is working for analytics_instrumentation, followed by Recommended next steps and Technical evidence (for developers) when needed.

  • Scan key: analytics_instrumentation
  • Category: TECHNICAL

Why fixing this matters

If baseline instrumentation is broken, conversion analysis and marketing attribution become unreliable. Teams then chase false alarms or miss real regressions.

This is also a release-discipline check: analytics often breaks during template, consent, or tag-manager changes.

If you are not technical

  1. Confirm one person owns production analytics integrity.
  2. Ask for proof on live pages (home, pricing, signup/checkout).
  3. Verify your production IDs are correct (not staging IDs).
  4. Re-run Scavo and confirm warning clears.

Technical handoff message

Copy and share this with your developer.

Scavo flagged Analytics instrumentation (analytics_instrumentation). Please verify live analytics/tag-manager provider loading and confirm GA4/GTM production IDs are correctly embedded across key templates. Share proof and re-run the scan.

If you are technical

  1. Keep analytics bootstrap in shared layout/head partials.
  2. Validate environment config so production IDs cannot silently drift.
  3. Ensure consent gating delays optional tags correctly, but does not block valid post-consent initialization.
  4. Prevent duplicate initialization in SPA route transitions.
  5. Add smoke tests for critical pages after release.

How to verify

  • Use Tag Assistant and GA4 DebugView on live URLs.
  • Confirm only one expected initialization path per page load.
  • Confirm expected production IDs are present.
  • Re-run Scavo and check provider + ID fields in details.

What this scan cannot confirm

  • It does not validate event naming quality or business taxonomy.
  • It does not guarantee downstream reporting pipelines are correct.
  • It does not prove every conversion event is firing with correct parameters.

Owner checklist

  • [ ] Assign analytics implementation owner.
  • [ ] Keep production IDs in controlled config.
  • [ ] Add post-release tag smoke tests on key funnels.
  • [ ] Re-audit after consent/CMP or head-template changes.

FAQ

Can this pass if only one provider is detected?

Yes. The check validates baseline detectability, not your full analytics strategy.

Why warn when Google scripts are visible?

Because scripts alone are not enough if usable GA4/GTM IDs are not detected.

Does pass mean attribution is perfect?

No. It means instrumentation signals are present; attribution modeling still needs analytics QA.

Which pages should we validate first?

Pages tied directly to revenue actions: pricing, signup, checkout, and high-intent landing pages.

Sources


Need a production analytics smoke-test checklist tailored to your funnel? Send support your key conversion routes.

More checks in this area

redirect_chain_hygiene

Redirect Chain Too Long — Multiple Hops Before the Real Page Loads

Learn how Scavo measures redirect hops, why chains slow users and crawlers down, and how to flatten protocol, host, and legacy URL redirects into cleaner routes.

Open guide
not_found_status

404 Page Returns Wrong HTTP Status Code

When a deleted or broken URL returns HTTP 200, search engines index it as a real page — polluting your index with dead content and wasting crawl budget. This is called a "soft 404" and Google specifically warns against it. Your 404 page should return a proper 404 status code while still showing a helpful message to users.

Open guide
cms_fingerprint

CMS or Server Version Exposed in Headers

When attackers can see you're running WordPress 6.3 or Apache 2.4.51, they can check public CVE databases for known exploits specific to your exact version. Removing version disclosure is simple server hardening — it doesn't fix vulnerabilities, but it removes the signpost that tells attackers exactly where to look.

Open guide