Google Analytics Not Tracking on WordPress? Here's the Fix
You check Google Analytics, and it's flat — zero users, zero sessions, even though you know people are on the site right now. Or worse, GA4 shows numbers, but they're way lower than what your ad platform or payment gateway reports. Before you assume the site is actually dead, walk through this. Nine times out of ten it's a tracking setup problem, not a traffic problem.
Symptom: Real-Time Reports Show Nobody, But the Site Has Visitors
You open GA4's Realtime report, load your own site in another tab, click around — and nothing shows up. Or the numbers eventually appear but are inconsistent, days behind, or missing entire sections of the site (like the blog, or checkout pages). WordPress hosting support tickets for this almost always start the same way: "I installed Analytics months ago, it worked, now it doesn't."
Cause 1: The Tracking Code Never Actually Loads
This is the most common one. Somewhere between the plugin you used to add the code and the page WordPress renders, the script gets dropped. A few ways this happens:
- You added the GA4 snippet through a theme's "custom header scripts" field, then switched themes or updated one that wiped the setting.
- You're using both a dedicated Analytics plugin (like Site Kit or MonsterInsights) and a manually pasted snippet — one overwrites or conflicts with the other, and only one (or neither) fires cleanly.
- The snippet was added inside a page builder's "custom code" widget instead of the theme's global header, so it only loads on that one page.
Check it directly instead of trusting the plugin's settings screen. View the page source (Ctrl+U or Cmd+Option+U) and search for gtag( or your GTM container ID (looks like GTM-XXXXXXX). If it's not in the raw HTML, no plugin setting will fix it until the underlying cause does.
Cause 2: A Caching Plugin or Server Cache Is Serving an Old Page
This is the one that trips up hosting teams the most, because everything looks correctly configured in WordPress admin — and still doesn't work for visitors. If you added or changed your GA4 measurement ID recently, a page cache (WP Rocket, LiteSpeed Cache, W3 Total Cache, or server-level caching on your hosting) can keep serving a version of the page generated before the change.
To confirm this is the culprit, open the site in an incognito window and view source again. If the measurement ID in the HTML doesn't match what's in your GA4 property settings, you're looking at cached HTML, not the current one.
Fix
- Purge the caching plugin's cache from its settings page.
- If you're on Getwebup hosting with LiteSpeed or server-side caching enabled, also purge the object/page cache from cPanel → LiteSpeed Cache Manager, or ask support to flush it.
- If you're behind Cloudflare, purge the Cloudflare cache separately — plugin and CDN caches are two different layers, and clearing one doesn't touch the other.
- Reload in an incognito window (not just a hard refresh — your browser also caches JS files) and re-check the source.
Cause 3: A Consent/Cookie Banner Is Blocking the Script by Default
If you added a GDPR or cookie-consent plugin recently — and Analytics stopped tracking around the same time — this is almost certainly it. Consent plugins are designed to block third-party scripts, including Analytics, until the visitor actively accepts cookies. That's correct behavior for compliance, but it means your Realtime report will only ever show visitors who clicked "Accept," not everyone who landed on the page.
Check the consent plugin's category settings. Google Analytics needs to be tagged under "Analytics" or "Statistics" cookies, and depending on your configuration, you may be running it in "consent mode" where GA4 still receives anonymized pings even before consent — but only if that's explicitly enabled. If it isn't, your numbers will always look lower than actual traffic, and that's by design, not a bug to fix.
Cause 4: Wrong Container, Wrong Property, or a Leftover Old ID
Easy to overlook: if the site was migrated, rebuilt, or the Analytics account was recreated at some point, you can end up with the old measurement ID still hardcoded somewhere (a child theme's functions.php, an old plugin, a snippet manager) while your team is looking at a new GA4 property that never receives data. Search your codebase and plugin settings for every instance of G- or GTM- and confirm each one matches the property you're actually checking.
If you're using Google Tag Manager as the layer above GA4 (recommended, since it lets you manage tags without touching code), also confirm the container is actually published. It's common to build and test a tag in GTM's preview mode, forget to click "Submit," and leave the live site running an older container version that doesn't include the new tag.
Cause 5: An Ad Blocker or Browser Privacy Setting (On Your End, Not the Visitor's)
If you're testing from your own browser and seeing nothing, rule yourself out first. Ad blockers, uBlock Origin, Brave's shields, and even some VPN/DNS-level ad blocking (like Pi-hole or certain router firewalls) block google-analytics.com and googletagmanager.com outright. Test in a plain incognito window with no extensions before concluding the site itself is broken.
Quick Diagnostic Checklist
| Check | How | What It Tells You |
|---|---|---|
| View page source | Ctrl+U, search for gtag( or GTM- | Is the script in the HTML at all? |
| Incognito + no extensions | New private window, disable ad blockers | Rules out your own browser/network blocking it |
| Compare ID in source vs GA4 | Match G-XXXX in source to Admin → Data Streams | Catches caching and wrong-property issues |
| GTM Preview mode | Tag Manager → Preview, browse the live site | Confirms tags fire and the container is published |
| Consent plugin settings | Check cookie categories | Confirms Analytics isn't gated behind consent |
| Chrome extension: Tag Assistant | Google's official tag-debugging extension | Shows exactly which tags fired and any errors |
Prevention
Once it's working again, a few habits keep it from breaking silently next time:
- Use Google Tag Manager instead of pasting snippets directly. One script in the theme header, and every future change happens inside GTM — no more hunting through plugin settings or theme files.
- Set a caching exclusion for GTM/GA scripts if you self-host them. Most sites load these from Google's CDN anyway, which sidesteps this, but if a plugin bundles them locally, exclude those files from aggressive minification/caching.
- Purge cache immediately after any tracking change — treat it the same as clearing cache after a plugin update.
- Check Realtime data right after any theme, plugin, or consent-tool update. A five-second check catches this before a week of missing data does.
- Keep one canonical measurement ID documented somewhere your team can find it, so nobody re-adds an old one during a redesign.
If you've gone through all of this and Analytics is still silent, it's worth having your hosting provider check whether a server-level firewall rule, WAF, or bot-mitigation setting is blocking outbound requests to google-analytics.com — rare, but it happens on servers with aggressive third-party-script restrictions.
Frequently asked questions
Why does GA4 show fewer visitors than my ad platform or payment gateway?
This is usually consent mode or ad-blocker loss, not a bug. GA4 only counts visitors whose browser actually let the tracking script run and, if you have a consent banner, who accepted cookies. Ad platforms and payment gateways often use server-side or first-party tracking that isn't affected by the same blockers, so some gap between the two is normal — a huge gap points to consent settings being too restrictive.
I added the GA4 code through a plugin — why isn't it showing in the page source?
Some plugins only inject the script on certain page types (e.g., only posts, not pages), or the setting silently failed to save. Re-save the plugin's tracking ID field, then view source on a few different page types — home, a post, a product page — since the issue can be page-type specific.
Does clearing my browser cache fix this, or do I need to clear something on the server?
Both, potentially. Your browser cache only affects what you personally see. If a caching plugin or your host's server-side cache generated the page before you updated the tracking code, every visitor gets the old version until that cache is purged — clearing your own browser won't touch it.
Can Cloudflare block Google Analytics from loading?
Not by default, but a Cloudflare Page Rule, a WAF custom rule, or an overly aggressive 'Rocket Loader' JS optimization setting can interfere with how the script loads. If Rocket Loader is on, try excluding your analytics script or disabling it temporarily to see if tracking resumes.
Is it normal for Realtime to show data but the daily/weekly reports to be empty?
Yes, this is expected for new properties or IDs — GA4's standard reports (as opposed to Realtime) can take 24-48 hours to populate after a measurement ID starts receiving data. If Realtime works, tracking is functioning; give the standard reports time to catch up before troubleshooting further.