You've launched your website. Google Search Console shows impressions and clicks. People are discovering your pages through Google Search. Your website is receiving real traffic.

But when you open Google Analytics 4 (GA4), something strange happens.

Zero visitors. Zero pageviews. Almost no activity.

You check your website source code. The Google Analytics script is there. Your Measurement ID looks correct. There are no obvious JavaScript errors.

So, what's going wrong?

This is a frustrating problem because everything can look correct while your analytics system silently fails to collect the events you actually need.

I've explored this problem from a practical development perspective, and there are several important things every developer should understand before trusting their analytics dashboard.

Let's break it down.

1. Installing Google Analytics Doesn't Mean Tracking Is Working

One of the biggest misconceptions about Google Analytics is that adding its tracking script automatically means everything is configured correctly.

It doesn't.

Consider this example:

<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>

<script>
  window.dataLayer = window.dataLayer || [];

  function gtag() {
    dataLayer.push(arguments);
  }

  gtag('js', new Date());
  gtag('config', 'G-XXXXXXXXXX');
</script>

At first glance, everything looks fine.

The script loads. The Measurement ID exists. The configuration runs.

But there are still several things that can go wrong:

• The script loads but the configuration never executes.
• The wrong Measurement ID is being used.
• Events are sent with an incorrect payload.
• JavaScript executes before the tracking library is ready.
• A Content Security Policy blocks Google Analytics requests.
• Consent settings prevent analytics collection.
• An ad blocker blocks tracking requests.
• The website sends events to a different GA4 property.

The important lesson: Never assume that analytics works just because the tracking script exists in your HTML.

You need to verify the actual events being sent.

2. Google Search Console and Google Analytics Measure Different Things

This is an important distinction.

Google Search Console and Google Analytics 4 are not measuring the same activity.

Google Search Console (GSC) tells you how your website performs in Google Search.

It provides information such as:

• Search impressions.
• Search clicks.
• Average search position.
• Search queries.
• Indexed pages.

Google Analytics 4 (GA4) measures activity on your website when its tracking system successfully collects events.

It provides information such as:

• Users.
• Sessions.
• Pageviews.
• Engagement.
• Events.
• Conversions.

Imagine this situation:

These numbers don't necessarily indicate that Google is reporting incorrect information.

They indicate that the two systems are observing different stages of the user journey.

Google Search Console can record a search click without your website successfully sending a GA4 event.

For example, a visitor might open your website, but:

1. The browser blocks the analytics request.
2. The tracking code fails to execute.
3. The page closes before the event is sent.
4. Consent settings prevent tracking.

This explains why Search Console activity and Analytics activity can differ.

If GSC shows real clicks but GA4 shows nothing, investigate your tracking implementation before assuming your website has no visitors.

3. Server-Side Rendering Creates Additional Tracking Challenges

Modern websites don't all work like traditional static HTML websites.

Frameworks such as Next.js use different rendering strategies, including:

• Server-Side Rendering (SSR).
• Static Site Generation (SSG).
• Client-Side Rendering (CSR).
• Incremental Static Regeneration (ISR).

Some websites also inject scripts through reverse proxies, gateways, or server-side middleware.

These approaches can introduce additional tracking challenges.

For example, imagine a website where the gateway injects Google Analytics directly into the HTML response.

The browser receives the tracking script as part of the rendered HTML.

This approach can work perfectly well, but developers need to understand where and when the script executes.

Potential problems include:

• The tracking script is injected more than once.
• The script is present in the HTML but never initialized.
• Client-side navigation doesn't trigger additional pageviews.
• The gateway modifies or removes required script attributes.
• The application and gateway both attempt to manage analytics.

For SSR applications, inspect the actual HTML delivered to the browser.

Don't rely exclusively on your React components or application source code.

You can inspect the response using:

curl -L https://example.com -o page.html

Then search the downloaded HTML for your Measurement ID:

grep -o "G-[A-Z0-9]*" page.html

You can also open DevTools and inspect the Network tab to see whether the analytics requests are actually being sent.

4. The Hidden Problem: Incorrect Event Configuration

This is where things become particularly interesting.

Google Analytics 4 uses an event-based measurement model.

Instead of simply counting page visits, GA4 receives events such as:

• page_view
• session_start
• first_visit
• scroll
• click
• purchase

A website can load the Google Analytics library successfully but still fail to send the expected events.

For example:

gtag('event', 'page_view', {
  page_title: document.title,
  page_location: window.location.href,
  page_path: window.location.pathname
});

This is a basic example of sending a pageview event.

However, the configuration must match the GA4 implementation, and the event must reach the correct measurement destination.

Don't just copy code from an old tutorial and assume it is correct for your setup.

Check the current Google Analytics documentation for the supported event parameters and configuration.

Official documentation:

https://developers.google.com/analytics/devguides/collection/ga4

5. How to Debug Google Analytics Properly

If GA4 reports zero visitors, don't immediately rewrite your entire tracking implementation.

Debug it systematically.

Here is the process I recommend.

Step 1: Verify Your Measurement ID

Open your GA4 property.

Navigate to:

Admin → Data Streams → Your Web Stream

Check the Measurement ID.

It should look similar to:

G-XXXXXXXXXX

Compare it with the ID used by your website.

Make sure you're checking the correct GA4 property.

Step 2: Inspect the Network Requests

Open your website in Chrome.

Press:

F12

Navigate to:

Network → Filter: collect

Reload your website.

Look for requests sent to Google Analytics collection endpoints, particularly:

https://www.google-analytics.com/g/collect

Check whether the requests are successful.

A successful network response is useful evidence, but it doesn't independently prove that every event has been processed and displayed in your reports.

Also inspect the request payload and confirm:

• The correct Measurement ID is present.
• The event name is correct.
• The page URL is correct.
• The request isn't blocked or cancelled.

Step 3: Use GA4 DebugView

DebugView is one of the most useful tools for diagnosing event tracking.

Open:

Google Analytics → Admin → Data Display → DebugView

Then enable debug mode for your test browser.

For example, you can use:

gtag('config', 'G-XXXXXXXXXX', {
  debug_mode: true
});

Reload your website and interact with it.

If events appear in DebugView, your implementation is sending events that GA4 can receive in debug mode.

If nothing appears, investigate the browser requests, configuration, consent settings, and measurement destination.

Step 4: Check Realtime Reports

Open:

Reports → Realtime

Visit your website from another browser or device.

Check whether your activity appears.

Remember that Realtime and DebugView serve different purposes. DebugView is especially useful for inspecting individual test events.

Step 5: Test More Than One Page

Don't test only your homepage.

Visit several pages:

/
 /about
 /blog
 /pricing
 /contact

If you use client-side navigation, move between pages without refreshing the browser.

Check whether each page generates the expected pageview event.

This is especially important for Next.js applications and other single-page application architectures.

6. The Duplicate Pageview Problem

Fixing missing analytics events is only half the job.

Another common problem is duplicate tracking.

Imagine you have enabled automatic pageview tracking through GA4 configuration:

gtag('config', 'G-XXXXXXXXXX');

Then you also manually send pageviews:

gtag('event', 'page_view', {
  page_location: window.location.href
});

Depending on your configuration, both mechanisms may send pageviews for the same navigation.

The result?

One actual visit can generate multiple pageview events.

Your dashboard starts reporting inflated numbers.

This can happen when developers combine:

• GA4 Enhanced Measurement.
• Automatic pageview tracking.
• Manual pageview events.
• Framework-specific route tracking.
• Multiple analytics integrations.

The solution is to establish one clear owner for pageview tracking.

If automatic tracking handles initial pageviews, don't send another initial pageview manually.

If you implement manual route tracking, configure automatic pageview behavior appropriately and ensure that route changes are tracked exactly once.

For example, a manual configuration might look like:

gtag('config', 'G-XXXXXXXXXX', {
  send_page_view: false
});

You can then send pageview events through your own route-tracking implementation.

However, be careful: disabling automatic pageviews also means you must correctly handle the initial pageview and subsequent navigation events yourself.

7. A Practical GA4 Debugging Checklist

Before considering your analytics implementation complete, verify these items.

Installation

• [ ] Correct Measurement ID.
• [ ] Tracking script appears in the actual browser HTML.
• [ ] Script executes without JavaScript errors.
• [ ] No unintended duplicate script installations.

Event Collection

• [ ] Initial pageview is received.
• [ ] Page URL is correct.
• [ ] Page title is correct.
• [ ] Events reach the intended GA4 property.
• [ ] Network requests aren't blocked.

Next.js and SSR

• [ ] Server-rendered pages include the tracking implementation.
• [ ] Client-side navigation generates the expected pageviews.
• [ ] Gateway injection doesn't create duplicate scripts.
• [ ] Tracking doesn't run twice after hydration.

Data Quality

• [ ] Realtime reports show test activity.
• [ ] DebugView receives expected test events.
• [ ] Enhanced Measurement settings are understood.
• [ ] Manual and automatic pageview tracking don't overlap.

8. Don't Trust Analytics Until You've Tested It

One mistake developers make is treating analytics as a feature that is finished once the integration code is deployed.

In reality, analytics needs its own testing and verification process.

A production website can have:

• A perfectly working frontend.
• A functioning backend.
• Indexed pages in Google.
• Real search traffic.
• A correctly installed analytics library.

And still have broken event collection.

This is why I recommend adding analytics verification to your deployment checklist.

After every major deployment, test the live website.

Verify the actual network requests, inspect the events, and confirm that the expected data reaches the correct property.

Also remember that browser privacy settings, consent requirements, and ad blockers can legitimately prevent some visits from being measured.

Your goal isn't to force every visitor to be tracked. Your goal is to ensure that tracking works correctly when collection is permitted.

Final Thoughts

Google Analytics problems aren't always caused by missing scripts or incorrect Measurement IDs.

Sometimes the tracking code is installed, the website is working, and Google Search Console is reporting real traffic, but the event implementation is still broken.

Other times, the problem is the opposite: multiple tracking systems are sending the same events and inflating your numbers.

The best approach is simple:

Don't just check whether Google Analytics is installed. Check whether the right events are actually being sent, received, and measured.

For developers working with Next.js, SSR, reverse proxies, or custom analytics integrations, this distinction can save hours of debugging.

Because at the end of the day, having analytics code in your website and having reliable analytics data are two completely different things.

Useful Resources

• Google Analytics 4 Documentation
• GA4 Events Documentation
• Google Analytics DebugView
• Google Tag Assistant
• Google Search Console

webdev #javascript #nextjs #googleanalytics #analytics #debugging #webdevelopment #programming