You see zero active users in your dashboard. Google analytics is not working on your wordpress site because you are logged in as an administrator, your caching plugin needs purging, or you are still using a dead Universal Analytics tag. You can fix this by testing in an incognito window, clearing your cache, and updating to a GA4 measurement ID.
When google analytics is not working on your wordpress site, you lose visibility over your traffic and conversions. The problem is rarely a broken Google server. The issue sits inside your WordPress environment. You need to isolate the exact block preventing the script from firing.
You are testing while logged in as an administrator
WordPress analytics plugins like MonsterInsights or Site Kit by Google have a default setting that excludes logged in administrators from tracking. This stops your own editing sessions from inflating your traffic data. It also causes a false negative when you try to test your own installation.
You install the tracking code, open your website in a new tab, and check the Realtime report. Nothing happens. The script is actively hiding from you because you are logged in.
To test your tracking properly, open a private browsing window. Do not log into WordPress. Visit your homepage and click around a few different pages. Open your Google Analytics dashboard in your normal browser window and check the Realtime report. If you see yourself moving through the site, your tracking works perfectly.
You can also change the settings inside your plugin. In MonsterInsights, go to the advanced settings and look for the tracking exclusions. You can remove the administrator role from the list. Just remember to add it back after you finish testing, or your own visits will ruin your conversion data. If you are trying to verify complex ecommerce events and nothing is showing up, you can review our past work to see how proper testing protocols are structured.
Your site is still running a Universal Analytics code
Google deleted Universal Analytics entirely. If your tracking code starts with the letters UA, it is dead. Google Analytics 4 is the only version that collects data today.
You need to check what code is actually loading on your live pages. You can run your domain through a Google Analytics checker to see exactly which tags are firing on your site right now. It tells you immediately if your site is running a valid GA4 tag or an obsolete UA tag.
If it finds a UA tag, you have to replace it. To fix this, log into your Google Analytics account. Go to the Admin section. Click on Data Streams and select your website. You will see a Measurement ID starting with the letter G. Copy this ID.
Go back to your WordPress dashboard. Open your analytics plugin and paste the new ID over the old one. Save your settings. If you hardcoded the script into your theme, you must delete the old script entirely and paste the new Google tag snippet in its place.
A caching plugin is serving an old version of your site
WordPress runs on caching plugins like WP Rocket, W3 Total Cache, or LiteSpeed Cache. These tools save a static copy of your website to make it load faster for visitors. When you add a new Google Analytics script or update a plugin, the cache does not always update immediately.
Your live visitors are still downloading the old version of your website from yesterday. That old version does not have your new tracking code.
You fix this by clearing your cache. Go to the top bar of your WordPress dashboard. Find your caching plugin icon and click the option to purge all caches.
You must also check for server level caching. Hosts like WP Engine, SiteGround, and Kinsta have their own caching systems built into the server. You need to log into your hosting panel and flush the server cache. If you use a Content Delivery Network like Cloudflare, you must log into that account and purge the cache there as well. Once every cache is clear, visit your site in an incognito window to force the new tracking code to load.
Your cookie consent banner is blocking the script
Privacy laws require websites to ask for permission before tracking users. WordPress cookie consent plugins are designed to block Google Analytics entirely until the visitor clicks accept.
If you recently installed a consent management platform, it is doing its job. The problem is that many visitors ignore the banner or click reject. Google Analytics will not record those visits. This makes your traffic look like it dropped overnight.
You can confirm this by visiting your site in an incognito window. Do not click accept on the cookie banner. Right click the page and select Inspect. Open the Network tab in your developer tools. Type the word collect into the filter box. Refresh the page. If nothing appears, the script is blocked.
Now click accept on the cookie banner. If a network request containing the word collect suddenly appears, your consent plugin is controlling the script. This is normal behaviour. Google now requires Consent Mode to be active for European traffic. If your plugin is not configured for Consent Mode, Google might reject your data even if the user clicks accept.
The tracking code is pasted in the wrong place
Google requires the tracking snippet to sit high up in the code of your website. Specifically, it must go immediately after the opening head HTML tag.
Many site owners paste the code into the footer, into a random text widget, or inside the body content of a page. When the script is placed too low, a visitor might click away from the page before the browser has time to load the tracking code. This results in missing data.
According to official Google tag setup documentation, placing the snippet anywhere other than the head section is an incorrect installation.
To fix this without breaking your site, install a dedicated plugin like WPCode. Go to the headers and footers section of the plugin. Paste your Google Analytics snippet into the global header box. Save the changes and purge your cache. This ensures the script loads in the exact location Google expects, on every single page of your website. Never paste the code into a page builder text block.
You have installed duplicate tracking codes
You might have installed Google Analytics multiple times without realising it. This happens when you use Site Kit to connect your account, but you also have MonsterInsights running, and you also pasted the raw code into your theme header.
Multiple tracking codes on the same page cause severe conflicts. They send duplicate pageviews, inflate your bounce rate incorrectly, or cancel each other out entirely.
You need to audit your WordPress setup and choose one single method for tracking. Go to your plugins list. Look for anything with the word analytics or tracking in the name. Deactivate everything except your primary choice. If you have inherited a messy website and cannot find where the old codes are hidden, you can contact us to audit your installation.
Next, go to Appearance and click on Theme File Editor. Check your header file to ensure no manual scripts are pasted there. Finally, check your Google Tag Manager container if you use one. If you are deploying Google Analytics through Tag Manager, you must not have a separate Google Analytics plugin active in WordPress. Pick one delivery method and delete the rest.
You are looking at standard reports instead of Realtime
Google Analytics 4 does not process data instantly. The standard reports you see on your main dashboard take between 24 and 48 hours to populate.
If you just installed the code today, your main reports will show zero traffic. This does not mean the setup is broken. It means the data is still sitting in the processing queue.
You must use the Realtime report to verify a new installation. Click on Reports in the left menu, then click Realtime. This screen shows activity from the last thirty minutes. If you see active users here, your code is working. You just have to wait until tomorrow for the numbers to appear in your main traffic acquisition reports.
Do not make changes to your WordPress site if the Realtime report is showing active users. You will break a working setup out of impatience. Let the system process the data overnight.
A theme update erased your manual code
If you pasted your tracking code directly into the header file of your WordPress theme, you made a mistake. When the theme developer releases an update, WordPress overwrites all the core files. Your manual edits are deleted instantly.
Your tracking works perfectly for six months, then stops on a random Tuesday because an automatic theme update wiped the code.
You can prevent this by never editing the main theme files directly. You have two options to make the code permanent.
- Use a child theme. A child theme inherits the design of the main theme but keeps your custom code safe during updates. You can paste the tracking script into the header file of the child theme.
- Use an injection plugin. A plugin like WPCode injects the script independently of your theme. When the theme updates, the plugin remains untouched and your tracking stays active.
If your code was erased, you must retrieve your Measurement ID from Google Analytics and reinstall it using one of these two safe methods.
Script conflicts are breaking the execution
WordPress is a modular system. You might have forty different plugins running at the same time. Sometimes, a performance optimisation plugin or a security tool will block external scripts from executing.
Tools that minify Javascript or defer script loading are the most common culprits. They take your Google Analytics code, compress it, and push it to the bottom of the loading queue to make your text render faster. This compression can break the tracking code entirely.
To test for a conflict, you need to isolate the variables.
- Turn off your Javascript minification settings in your caching plugin.
- Disable any feature that delays third party scripts.
- Turn off your security plugin temporarily.
- Clear your cache and test the site in an incognito window.
If the tracking starts working, turn your plugins back on one by one. Test the site after every single activation. When the tracking breaks again, you have found the plugin causing the conflict. You will need to add an exception in that plugin settings to leave the Google Analytics script alone. Fixing these conflicts takes time. If you want a professional to handle your technical stack, you can review our pricing for ongoing system management.
Browser extensions are blocking your own tests
You might be doing everything right on the WordPress side, but your own browser is hiding the truth. Ad blockers and privacy extensions like uBlock Origin, Ghostery, or Brave Shields block Google Analytics by default.
If you have one of these extensions active, you will never see your own visits in the Realtime report. You will spend hours trying to fix a WordPress site that is not actually broken.
Disable all ad blockers in your browser. Turn off strict tracking protection. Better yet, use a completely clean browser profile with zero extensions installed when you test your analytics setups.
You can also use the official Google Tag Assistant tool. Go to the Tag Assistant website, enter your domain, and click connect. It will open your site in a debug window and tell you exactly which tags are firing. This bypasses most local browser restrictions and proves whether the code is actually present on the page.
Moving to a more stable tracking setup
Relying on browser based tracking means you are always fighting against ad blockers, cookie banners, and plugin conflicts. Every time a visitor uses a strict privacy browser, you lose their data.
If you run lead generation campaigns or rely on accurate conversion data, you need to move the tracking away from the visitor browser. You can send the data directly from your server to Google Analytics. This bypasses ad blockers entirely and gives you a much clearer picture of your actual traffic.
It also speeds up your WordPress site because the visitor does not have to download the Google script. If you are tired of fixing broken scripts, look into upgrading your infrastructure. We build custom setups for businesses that need reliable data. You can read about how we implement server side tracking to permanently solve these collection issues.