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.

Analytics Not Installed or Not Firing featured image

Start here

Before you fix it: what this check means

Scavo looks for common analytics and tag-manager code in the downloaded HTML. It does not confirm that visits or conversions are recorded correctly. Scavo inspects script sources and inline scripts for known provider fingerprints, then looks for Google IDs.

Why this matters in practice: checking the reported setting helps you keep the site working as intended.

Use this as evidence, not a final verdict. Finding analytics code does not prove that events reach your account or that totals are correct. Check the live site first. Check a test visit in your analytics tool and confirm each expected event appears once Make one controlled change. Keep analytics bootstrap in shared layout/head partials. Re-scan the same URL and compare the finding; check the feature yourself as well.

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 (quick version)

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

404 Page Returns Wrong HTTP Status Code featured image
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 or Server Version Exposed in Headers featured image
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