Google Analytics not tracking WordPress does not always mean Site Kit is broken. A quiet GA4 report can come from the wrong property, a date-range delay, denied consent, a tag that never fires, a request blocked by the browser, or a form event that was never configured. Reinstalling the plugin before you know which signal is missing can erase useful evidence without fixing the cause.
Start outside WordPress. Compare what Google Search Console recorded, what GA4 Realtime sees in a fresh browser session, whether the Google tag is present, and whether consent allowed the analytics request. That order separates a real traffic loss from a measurement failure.
This guide gives WordPress owners six checks, a symptom-to-cause matrix, and a clear handoff point for professional help. It also explains what Site Kit can configure and what still belongs to your consent platform, caching layer, theme, forms, or GA4 property.
First decide which number disappeared
“Analytics is empty” can describe several different failures. Name the missing signal before changing the site.
| What you can still see | What may be missing | First useful check |
|---|---|---|
| Search Console clicks, but almost no GA4 sessions | The website received search visits, but analytics did not record all browser sessions | Test GA4 Realtime in a fresh consented browser and inspect tag delivery |
| GA4 page views, but no form, chat, or checkout events | The base tag works, but the business action is not configured or does not fire | Complete one test action and inspect its event separately |
| Site Kit says Analytics is connected, but Realtime stays empty | Connection and browser measurement are different layers | Confirm the property, web stream, consent state, and outgoing request |
| Only your own test visits are missing | Internal traffic rules, browser privacy, an extension, or consent may exclude the test | Use a clean browser profile and a second network before editing WordPress |
| Traffic fell in Search Console and GA4 at the same time | The site may have lost visits rather than measurement | Check the same dates, landing pages, indexing, uptime, and acquisition channels |
The first row is especially useful. Search Console counts eligible Google Search clicks before a visitor lands. GA4 starts only after the page loads far enough for its tag to run and the browser permits measurement. A gap between them is evidence to investigate, not proof that either report is wrong.
Check 1: align the property, stream, date, and time zone
Open the GA4 property that Site Kit says it uses. Confirm the property name, measurement ID, web stream URL, reporting time zone, and date range. Then compare the same complete dates in Search Console and GA4.
Do not diagnose yesterday from one dashboard while viewing the last 28 days in another. Search Console can also finish processing later than Realtime, while standard GA4 reports may take time to settle. Use Realtime for a controlled visit and completed historical days for the trend.
If the site was redesigned, migrated, cloned, or moved between agencies, check for an old measurement ID in the theme, a tag manager container, a consent platform, or another analytics plugin. Two tags can duplicate data. The wrong tag can send valid data to a property nobody is viewing.
Check 2: run one clean Realtime test
Use a browser profile where you are not logged into WordPress. Disable ad-blocking extensions for the test, accept the analytics consent option if your banner offers one, and open a page with a harmless query such as ?analytics-test=1. Move to a second page and wait briefly while GA4 Realtime is open.
Record the page, time, browser, consent choice, and network. A single missing test is not enough to rewrite the site. Repeat it once on a different browser or mobile connection. If one environment appears and another does not, the difference is diagnostic evidence.
Stop here if Realtime works and only an older report appears low. Reinstalling Site Kit will not make historical sessions appear. Continue to the next checks when a fresh, consented visit remains absent.
Check 3: confirm the Google tag reaches the public page
Site Kit can show a connected service while a public page fails to deliver the expected tag. Check the rendered page while logged out, because page builders, cache exclusions, consent rules, and optimization settings can behave differently for administrators.
Look for the expected measurement ID or Google tag in the final page source and browser developer tools. Then check whether the browser sends an analytics request. The distinction matters:
- No tag in the public page: inspect Site Kit placement, theme templates, conditional scripts, and cache output.
- Tag present but no request: inspect consent, JavaScript errors, browser blocking, and script optimization.
- Request sent to the expected property: inspect GA4 filters, stream settings, report identity, and event configuration.
- Request sent to another property: remove the duplicate or obsolete implementation through a controlled change.
Do not paste a second GA4 snippet into the header as a quick fix. That can turn missing measurement into duplicated measurement and make the next diagnosis harder.
Check 4: test consent before blaming Site Kit
A consent banner can correctly prevent analytics storage until a visitor chooses. It can also be misconfigured: the visible choice changes, but the Google consent signal does not; consent defaults arrive after the tag; one page template omits the consent script; or a cache serves an outdated configuration.
Google’s official Site Kit consent mode documentation explains that Site Kit can enable consent mode, but a supported consent management platform is still responsible for collecting the visitor’s choice and communicating it correctly. A connected Analytics module does not by itself prove that consent updates reach the tag.
Run the Realtime test twice: once after accepting analytics and once after declining it. Record the observed behavior rather than assuming every missing request is an error. Your legal and consent requirements depend on the site and audience; the technical goal is to make the implemented choice behave consistently.
Check 5: isolate caching and JavaScript optimization
Page caching usually does not change the GA4 property by itself, but cached HTML and script optimization can preserve an old tag, delay consent code, reorder dependencies, or exclude one visitor state incorrectly. The public cached page is the product visitors receive, so test that version.
Use this controlled order:
- Save screenshots or request evidence from the failed public visit.
- Confirm the expected measurement ID in clean and cache-busted page output.
- Check the browser console for relevant JavaScript errors.
- Temporarily exclude only the identified analytics or consent script from delay or optimization when evidence supports it.
- Purge the affected cache layers in their real delivery order.
- Repeat the same consented Realtime test.
- Restore the previous setting if the result does not change.
Changing five performance settings at once may make the number return, but it does not tell you which change mattered. It can also reduce site speed for every visitor without repairing the underlying consent or property problem.
Check 6: test the event that creates business value
A working page view does not prove that a lead form, live chat, phone link, checkout, purchase, or subscription is measured. Test the exact action and verify it in both the destination system and GA4.
| Business action | Independent evidence | Analytics evidence | Do not claim success until |
|---|---|---|---|
| Contact form | The form stores or delivers the test enquiry | The intended submit or success event appears once | The event follows a real success state, not just a button click |
| Live chat | The chat window opens and the provider receives the session | The configured chat-open event appears | Mobile and desktop produce one useful event each |
| WooCommerce checkout | The order exists with the expected status and total | Checkout and purchase events carry the right values | Refreshes or payment redirects do not duplicate the purchase |
| Phone or email link | The device opens the intended app or action | The click event uses a clear name and destination | The report distinguishes intent from a completed enquiry |
In a Webless measurement check on August 26, 2026, GA4 separated Organic Search from its newer AI Assistant channel, while Search Console supplied page and query visibility. That combination answered more than a single traffic total. It still did not prove a sale: the business event needed its own evidence.
This is the same principle behind the free ChatGPT traffic guide. Use the data you already own first, but verify that the signal survives the complete WordPress journey.
Use this diagnostic order instead of reinstalling everything
- Define the missing signal. Traffic, page views, one source, or one business event are different failures.
- Align the reports. Confirm property, stream, dates, time zone, filters, and landing page.
- Test one fresh session. Use Realtime, a logged-out browser, a recorded consent choice, and a second environment.
- Trace delivery. Confirm the expected tag in public HTML and the outgoing browser request.
- Trace permission. Verify consent defaults and updates before changing the analytics plugin.
- Trace value. Complete the form, chat, or checkout and compare analytics with the system that received it.
If a step passes, preserve that evidence and move forward. If it fails, repair that layer and retest before changing another one. This approach creates a defensible before-and-after result.
Who owns each part of the WordPress tracking path?
Site Kit makes several Google services easier to connect, but it does not own every layer that can suppress or distort analytics.
- GA4 property: stream, filters, events, attribution, reporting identity, and key-event configuration.
- Site Kit or tag manager: the selected property and how the base Google tag reaches WordPress.
- Consent platform: the visitor choice, stored consent state, and consent update sent to Google tags.
- Theme and plugins: page templates, script conflicts, form success states, chat callbacks, and ecommerce hooks.
- Cache and CDN: the public HTML, script transformations, exclusions, and purged versions visitors receive.
- Business owner: the actions worth measuring and the independent record that proves a lead or order happened.
Professional help becomes appropriate when the tag appears but requests or events disagree across consent states, templates, devices, domains, payment redirects, or cache layers. It is also useful when changing production tracking could duplicate revenue, breach the intended consent behavior, or hide a real acquisition decline.
Frequently asked questions
Why does Search Console show clicks that GA4 does not show?
The tools measure different parts of the journey. Search Console can record an eligible Google Search click before the destination page runs analytics. GA4 may miss or classify the visit differently when the page fails, consent denies storage, the tag is blocked, or the report uses another date, property, or attribution dimension.
Can I fix missing GA4 data by clearing the WordPress cache?
Only when stale or transformed public output is part of the cause. Check the expected tag and consent behavior before and after a controlled purge. A cache purge cannot recover historical sessions or repair the wrong GA4 property.
Should I reinstall Site Kit?
Not as the first step. Reconnect only after you record the property, measurement ID, consent behavior, public tag, and failed test. If the tag already sends a request to the correct property, reinstalling the plugin targets the wrong layer.
Does a page view prove that my contact form tracking works?
No. Complete a real test form and verify both the received enquiry and a single success-based event. A click on the submit button can fire even when validation or delivery fails.
Repair the failed layer, then verify the whole path
When Google Analytics is not tracking WordPress, start with evidence rather than a reinstall. Align the property and dates, run a clean Realtime visit, trace the public tag, test consent, isolate optimization carefully, and verify the business event against an independent record.
The useful result is not merely “GA4 has numbers again.” It is a documented path from a real visitor, through the correct consent state and WordPress page, to a form, chat, checkout, or other action the business can verify.