GA4 Not Tracking All Pages? Why Pageviews Disappear

GA4 shows fewer pageviews than expected. Pages are missing from reports. Here's why -- SPAs, consent banners, ad blockers, GTM misconfig, and filters -- and how to fix each one.

GA4pageviewstroubleshootingSPAconsent modead blockersGTM

You check GA4 and your blog shows 12 pageviews yesterday. You know it gets more traffic than that. Or your product pages show up in reports but your checkout pages don’t. Or your total pageviews dropped 40% last month and nothing changed on the site.

GA4 not tracking all pages is one of the most common analytics problems — and it has at least six different causes. Here’s how to diagnose which one is affecting you and fix it.

Cause 1: Single-Page Application (SPA) Navigation

Symptoms: Only the first page a user visits shows up in GA4. Subsequent page navigations don’t trigger pageviews.

Why it happens: SPAs (React, Vue, Angular, Next.js, Nuxt, etc.) don’t do traditional page loads when users navigate. They swap content dynamically without reloading the page. GA4’s page_view event fires on page load — if the page never “loads” again, no subsequent pageviews are recorded.

How to check:

  1. Open your site in a browser
  2. Open GA4 Realtime report
  3. Click around your site — navigate to 5 different pages
  4. Check Realtime: if only the first page appears, you have an SPA tracking problem

Fix with GTM:

Create a trigger that fires on History Change events (SPAs use the browser’s history API to update the URL):

  1. GTM → Triggers → New
  2. Trigger type: History Change
  3. Save

Then update your GA4 page_view tag to fire on both Page View AND History Change:

  1. Edit your GA4 Event tag (or GA4 Configuration tag if using the older setup)
  2. Under Triggering, add the History Change trigger alongside All Pages
  3. In the tag configuration, make sure these fields are set dynamically:
    • page_location: {{Page URL}}
    • page_title: {{Page Title}} (may need a custom variable for SPAs)

Fix with gtag.js (no GTM):

If your SPA uses a router with navigation events:

// React Router example
import { useEffect } from 'react';
import { useLocation } from 'react-router-dom';

function usePageTracking() {
  const location = useLocation();
  
  useEffect(() => {
    window.gtag('event', 'page_view', {
      page_location: window.location.href,
      page_title: document.title
    });
  }, [location]);
}

Fix with Next.js App Router:

Next.js App Router doesn’t trigger traditional page loads. Use the usePathname hook:

'use client';
import { usePathname } from 'next/navigation';
import { useEffect } from 'react';

export function Analytics() {
  const pathname = usePathname();
  
  useEffect(() => {
    window.gtag('event', 'page_view', {
      page_location: window.location.href,
      page_title: document.title
    });
  }, [pathname]);
  
  return null;
}

Symptoms: Pageviews dropped significantly after installing a consent banner (cookie consent popup). European traffic disappeared. Mobile traffic specifically dropped.

Why it happens: If your consent banner blocks GA4 from firing until the user clicks “Accept,” everyone who dismisses or ignores the banner generates zero pageviews. Consent opt-in rates are typically 40-70%, meaning you lose 30-60% of your data.

How to check:

  1. Open your site in an incognito window
  2. DON’T click the consent banner
  3. Open GA4 Realtime — does your visit appear?
  4. If not, GA4 is being blocked until consent is given

Fix — implement Consent Mode v2:

Instead of blocking GA4 entirely, Consent Mode v2 lets GA4 load in a restricted mode. It doesn’t set cookies without consent, but it does send cookieless pings that GA4 uses for behavioral modeling.

// Set default consent state BEFORE GA4 loads
gtag('consent', 'default', {
  'analytics_storage': 'denied',
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied'
});

// When user accepts, update consent
gtag('consent', 'update', {
  'analytics_storage': 'granted',
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted'
});

With Consent Mode, GA4 recovers ~70% of the data that would otherwise be lost from non-consented users. The data is modeled (not directly observed), but it’s far better than zero.

Important: Your cookie consent banner configuration must integrate with Consent Mode. Not all banners do this correctly.

Cause 3: Ad Blockers

Symptoms: Pageviews are 15-30% lower than server-side page load counts. Desktop traffic is disproportionately affected.

Why it happens: Ad blockers (uBlock Origin, AdBlock Plus, Brave browser, etc.) block requests to google-analytics.com and googletagmanager.com. When these requests are blocked, GA4 never receives the event data.

How to check:

  1. Compare GA4 pageviews against server-side metrics (Cloudflare analytics, server access logs, CDN reports)
  2. If server-side shows 30% more traffic, ad blockers are the likely cause
  3. Check GA4 by device category — if desktop is disproportionately low, ad blockers (more common on desktop) are contributing

Ad blocker impact by segment:

AudienceEstimated Block Rate
General consumer15-25%
Tech-savvy audience30-50%
Developer/IT audience50-70%
Enterprise B2B20-30% (corporate firewalls)

Fixes (in order of complexity):

  1. Accept it. For most businesses, the 15-25% loss is consistent and can be factored in. If your analytics inform decisions directionally (not absolutely), the data is still useful.

  2. Server-side tracking. Send events from your server to GA4’s Measurement Protocol instead of from the browser. Ad blockers can’t block server-to-server requests. This is the same approach used for server-side tracking in general.

  3. First-party proxy. Route GA4 requests through your own domain (e.g., analytics.yoursite.com instead of google-analytics.com). Some ad blockers won’t block first-party requests. Note: this is a gray area ethically and technically — some ad blockers specifically detect this pattern.

Cause 4: GTM Configuration Errors

Symptoms: Some pages track fine, others don’t. New pages aren’t appearing. A specific section of the site has zero data.

Why it happens: GTM tags misconfigured, triggers too narrow, or GTM not installed on all pages.

Diagnostic steps:

Is GTM installed on every page?

  1. Visit a page that ISN’T tracking
  2. View page source (Ctrl+U)
  3. Search for gtm.js or your GTM container ID (GTM-XXXXXXX)
  4. If it’s missing, GTM isn’t installed on that page

Common places GTM is missing:

  • Checkout pages (especially on Shopify, which restricts checkout customization)
  • Subdomain pages (blog.yoursite.com if GTM is only on www.yoursite.com)
  • AMP pages
  • Newly added landing pages
  • Pages served by a different CMS or platform

Is the GA4 tag firing?

  1. Open GTM Preview Mode
  2. Navigate to the page that isn’t tracking
  3. Check: does the GA4 tag appear in “Tags Fired on This Page”?
  4. If it’s in “Tags Not Fired,” check the trigger conditions

Is the trigger too restrictive?

If your GA4 tag fires on a specific trigger (not All Pages), check the conditions:

Trigger IssueExampleFix
URL filter too narrowFires only on /blog/*Change to All Pages
DOM Ready vs Page ViewFires on DOM Ready but page doesn’t fully loadSwitch to Page View trigger
Custom event dependencyWaits for a dataLayer event that doesn’t fire on some pagesAdd fallback trigger

If your GA4 data isn’t showing up at all, the problem may be more fundamental than a page-level issue — start there first.

Cause 5: Internal Traffic Filters

Symptoms: Your own visits don’t appear in GA4. Pageviews from the office network are missing.

Why it happens: GA4 data filters can exclude traffic by IP address, or you may have an internal traffic filter enabled that you forgot about.

How to check:

  1. GA4 → Admin → Property → Data Streams → [your stream] → Configure Tag Settings → Define Internal Traffic
  2. Check if your IP range is listed
  3. GA4 → Admin → Property → Data Settings → Data Filters
  4. Check if the Internal Traffic filter is set to Exclude

Fix: If you intentionally excluded internal traffic, this is working as designed — your filtered pageviews won’t show up. If you accidentally excluded real user traffic (wrong IP range), update the IP definition.

See our guide on excluding internal traffic for the correct setup.

Cause 6: Bot Traffic Filtering

Symptoms: Sudden drop in pageviews, or pageviews lower than expected from the start.

Why it happens: GA4 automatically filters known bot traffic. Unlike Universal Analytics where you had to enable bot filtering, GA4 does it by default. This is generally good — but it means some “visits” that appear in server logs won’t appear in GA4.

How to check: Compare GA4 against server logs. If the discrepancy is mostly from known bot user agents (Googlebot, Bingbot, etc.), GA4 is correctly filtering them.

Fix: This usually doesn’t need fixing. If GA4 is filtering legitimate human traffic as bots, there’s no setting to disable it — but this is rare.

Cause 7: Sampling

Symptoms: GA4 shows an orange shield icon in reports with a message about “data is based on X% of sessions.”

Why it happens: For properties with high traffic, GA4 samples data in some reports (especially Explorations). Sampled data means GA4 analyzes a subset and extrapolates.

How to check: Look for the sampling indicator in any report. Hover over it to see the sample rate.

Fix:

  • Shorten the date range (less data = less likely to sample)
  • Use standard reports instead of Explorations (standard reports use unsampled data)
  • Use the BigQuery export for unsampled queries
  • Upgrade to GA4 360 (removes most sampling limits — but costs $50K+/year)

Diagnostic Flowchart

Are ANY pageviews showing in GA4?
├── No → Is GTM/GA4 installed? Check page source for gtm.js
│        → Is there a consent banner blocking everything?
│        → Is the GA4 Measurement ID correct?
│        → Check: /blog/ga4-data-not-showing-up

├── Yes, but some pages missing
│   ├── SPA? → Add History Change trigger
│   ├── Different domain/subdomain? → Check GTM installation on that domain
│   ├── Specific page type? → Check trigger conditions in GTM
│   └── Checkout pages? → Platform limitation (Shopify, etc.)

└── Yes, but fewer than expected
    ├── Consent banner installed recently? → Implement Consent Mode
    ├── Tech-savvy audience? → Ad blockers (15-50% loss)
    ├── Internal traffic filtered? → Check GA4 data filters
    └── High-traffic property? → Check for sampling

Checklist

  • GA4 Realtime shows your own visits
  • GTM container ID present on ALL pages (check 5+ different page types)
  • SPA navigation triggers pageviews (test by clicking through your site)
  • Consent banner integrates with Consent Mode v2
  • Internal traffic filter is correctly scoped (not over-filtering)
  • Server-side pageviews and GA4 pageviews are within 25% of each other
  • No sampling indicators on key reports

Missing pageviews means missing data, which means bad decisions. If GA4 is only capturing 60% of your traffic, your conversion rates, traffic sources, and user behavior reports are all skewed.

Want to find out what your GA4 is missing? Run a free scan — we check tag installation, consent mode configuration, and tracking completeness.