GA4 page_view Not Firing
Updated
Usually the tag is not running on the page the visitor actually lands on. Check the final URL after redirects, the GA4 measurement ID, that the tag or GTM container is published (not just in Preview), consent settings and the GTM trigger, then validate in DebugView rather than standard reports.
A fast troubleshooting sequence for when the page loads but GA4 does not show the page_view you expect.
Treat the problem as a chain rather than a single GA4 setting. First confirm you are testing the correct final URL, then verify that the Google tag or GTM container is actually published and visible, and only after that investigate event configuration and reporting.
What to check
1. Confirm the final URL
If the campaign redirects, make sure you are debugging the page that actually receives the visitor.
2. Confirm the measurement ID
A tag can be present but point to the wrong GA4 property or data stream.
3. Confirm the tag is live
Preview configuration is not enough. Verify the published page is loading the expected Google tag or GTM container.
4. Check consent behavior
Analytics storage or consent rules can delay or prevent measurement until the user makes a choice.
5. Check GTM triggers
If GA4 is deployed through GTM, confirm the configuration tag or Google tag trigger runs on the tested page.
6. Separate realtime debugging from standard reports
Standard reports can lag. Use live debugging surfaces when testing implementation changes.
7. Look for duplicate or conflicting setup
Multiple Google tags, duplicate GTM containers or mixed hardcoded/GTM setups can create confusing results.
What you see and what it usually means
No request containing /g/collect in the Network tab
The Google tag is not running on this page at all. Check that the snippet or GTM container is on the final URL and that the published version includes the GA4 tag.
The request is sent, but with a different G- ID
The tag works and reports to another property or data stream. Compare the tid value in the request with the measurement ID of the stream you are looking at.
page_view appears only after accepting cookies
Consent settings are holding measurement back until analytics storage is granted. That is expected behaviour; test both consent states before calling it a bug.
Visible in DebugView, missing in standard reports
Standard reports can take 24 to 48 hours to process. Check Realtime or DebugView first, then look for data filters that exclude internal or developer traffic.
A typical case
Worked verification (illustrative, not a measured AdVault customer result): open a clean browser profile on the final shop.example.com/promo URL and record the consent choice. In Network, filter for collect and inspect the event name and destination measurement ID. A request for page_view with the intended tid is evidence of browser delivery, not proof that GA4 accepted or attributed the event. Use DebugView to confirm reception in the intended property. After fixing the missing shop-subdomain tag, repeat the same entry URL, consent choice and navigation. Keep the before/after URL, tag version, timestamp and event evidence; redact client identifiers before sharing. If no request appears, inspect blockers and tag triggers before changing GA4 reports.
Before you call it fixed
- Correct GA4 measurement ID
- Published tag visible
- Correct final URL tested
- Consent state understood
- GTM trigger matches page
- No obvious duplicate deployment
- Realtime/debug validation completed
Check the production URL
A correct configuration on paper can still fail after redirects, deployment or consent logic. Use the exact URL your campaign will send traffic to.
Check a campaign URLVerify the signal directly
Related troubleshooting guides
Common questions
How long does it take for page_view to show up in GA4?
Realtime and DebugView show events within seconds to a couple of minutes. Standard reports and explorations are processed later and can lag by 24 to 48 hours.
Does GA4 send page_view automatically?
Yes, when the Google tag loads with its default settings, and again on browser history changes if enhanced measurement is on. If send_page_view is set to false, or the tag is blocked, nothing is sent until you fire the event yourself.
Can an ad blocker be the reason?
Yes. Many blockers and some browsers stop requests to Google Analytics. Repeat the test in a clean browser profile without extensions before changing the setup.
Scan the full campaign route.
See where the click lands, what survives the redirect chain and which supported tracking signals are visible on the final page.