GA4 Traffic Looks Wrong After Website Setup? Check Consent M

Direct Answer

If GA4 traffic looks wrong after website setup, check three things first: Consent Mode, GA4 data filters, and cross-domain tracking. In my experience, most “bad GA4 data” cases are not random. They come from a cookie banner blocking analytics, an internal traffic filter excluding real users, or a checkout domain starting a new session. Fix those before reinstalling your analytics plugin or Tag Manager container.

Explanation

GA4 traffic can look wrong because GA4 is not just counting page loads. It counts users, sessions, events, consent states, attribution, and identity signals. When one of those pieces changes after website setup, your reports can drop, split, or double count.

Consent Mode is the first place I check. If your cookie banner sets analytics_storage to denied before the GA4 tag loads, GA4 may receive less complete data. On one client site, traffic dropped by about 36% after a new cookie banner went live. The missing users were visitors who never clicked Accept for analytics cookies.

Filters are another common cause. GA4 data filters can remove internal traffic, developer traffic, or traffic marked with a specific traffic_type. Google’s official GA4 data filters documentation explains that data filters control which events are included in reports. I’ve seen setups where the office IP was added correctly, but the filter was too broad and removed visitors from the same network range.

Cross-domain tracking causes a different problem. Your main site may show one user, then your checkout, booking, or payment domain may show a second user. If the GA4 linker does not pass the client ID, GA4 treats the move as a new session. I once saw a service site lose 18% of conversions because the booking domain was not in the GA4 cross-domain list.

There is also a reporting delay. GA4 can take 24-48 hours to settle, especially after tag changes. If you changed Consent Mode at 2 p.m. and checked reports at 3 p.m., the dashboard may still be mixing old and new data.

Do not compare GA4 users directly with Google Search Console clicks. They measure different things. Search Console clicks count search result clicks, while GA4 users count people who reached the site and passed your tag, consent, and filter setup. If you need help with that comparison, read Fix Google Search Console Data Not Showing.

When This Fix Works

This fix works when GA4 traffic changed right after website setup, a cookie banner launch, a Tag Manager update, or a new domain was added. It also works when traffic looks normal in Realtime but low in standard reports.

It works well when you can reproduce the issue yourself. For example, open the site in a private window, decline cookies, accept cookies, move to the checkout domain, and watch what GA4 records.

It also works when the drop is specific. If only organic traffic is low, check Consent Mode and Search Console. If only office visits are missing, check internal traffic filters. If sessions split between example.com and checkout.example.net, check cross-domain tracking.

When This Does NOT Work

This does not fix old GA4 data. Active data filters usually affect future reports, not data collected before the change. Consent Mode changes also do not rewrite the past.

This does not make GA4 match another analytics tool exactly. GA4, Cloudflare Web Analytics, server logs, and ad platforms use different rules. I treat server logs as a useful check, not a perfect match.

This will not fix every privacy-related gap. Some visitors block scripts, use private browsing, or reject analytics cookies. You can reduce bad setup, but you cannot force every browser to send the same data.

This also does not solve every attribution problem. GA4 may move traffic between Direct, Organic Search, Paid Search, or Referral based on session source rules. If the problem is attribution, you need to check campaign tags and referrer settings too.

Step-by-Step Instructions

1. Check your GA4 Data Stream ID.

Open GA4 and click Admin in the lower left. Under Data collection and modification, click Data streams. Open your web stream and copy the Measurement ID, which looks like G-XXXXXXXXXX.

Go to your website source, Tag Manager container, or WordPress analytics plugin. Confirm the same G- ID is used everywhere. If you find two different GA4 properties, pick one as the main property and remove the duplicate. If your tag is missing from the site, start with Install Google Analytics 4 on WordPress.

2. Check whether the GA4 tag fires in Google Tag Manager.

Open Google Tag Manager and click Preview in the upper right. Enter your website URL and click Connect.

In Tag Assistant, click through your home page, a service page, and the main conversion page. On the left, open Tags Fired. Your GA4 Configuration tag or Google tag should fire on All Pages. If it does not fire, fix the base tag before touching filters or cross-domain settings. If you use GTM on WordPress, this guide may help: Set Up Google Tag Manager on WordPress.

3. Check Consent Mode before the GA4 tag loads.

Open your cookie banner settings. Look for the analytics category and check whether it controls analytics_storage. If you run ads in the EEA, also check ad_storage, ad_user_data, and ad_personalization.

In GTM, open Consent and click Consent Overview. You want to see a default consent state before page load. The clean setup I like uses a Consent Initialization - All Pages trigger for the CMP update, then the GA4 tag fires after that update.

If the GA4 tag fires before the cookie banner sets consent, your reports can look wrong. In that case, move the CMP consent update earlier in the page load sequence.

4. Test accepted and declined consent states.

Open your site in a private browser window. Decline analytics cookies, then reload the page. Open Preview in GTM and check the consent state for analytics_storage.

Now accept analytics cookies and reload the page. Check the consent state again. You should see a clear change from denied to granted.

If nothing changes after you click Accept, your cookie banner is not sending the right consent signal to GTM. This is a common issue with custom WordPress cookie banners and old CMP scripts.

5. Check GA4 data filters.

Open GA4 and click Admin. Under Data collection and modification, click Data settings. Click Data filters.

Check each filter status. Testing means the filter is being evaluated but not fully active. Active means the filter is removing matching events from reports. Inactive means it is not running.

If you see an internal traffic filter, open it and check the IP rule. Do not use a broad CIDR range unless you are sure it only covers your office or VPN. I once saw a filter that removed an entire mobile carrier range, which made mobile traffic look weak.

6. Check the traffic_type parameter.

If you use GTM, open your GA4 Configuration tag or Google tag. Look under Configuration parameters. Check whether traffic_type is set.

This parameter is useful when you want to exclude test traffic, but it can break reports if it is used incorrectly. For example, if every page view is marked as internal or test traffic, GA4 may remove normal users from reports.

Remove bad traffic_type values unless you have a clear reason to keep them. Save the container and publish only after testing.

7. Check internal IP filtering.

Go to a site such as whatismyipaddress.com from your office network and copy your public IP address. In GA4, go to Admin, then Data settings, then Data filters. Open your internal traffic filter and confirm the IP rule.

If you work from home, your IP may change often. In that case, do not keep adding single home IPs. Use a stable office VPN IP range or mark only known test devices in a separate browser profile.

8. Set up cross-domain tracking.

Open GA4 and go to Admin. Under Data collection and modification, click Data streams. Open your web stream.

Scroll to Configure tag settings. Under Configure your domains, click it. Add each domain where the same user journey continues, such as example.com, shop.example.net, booking.example.org, or pay.example.com.

Use the base domain when possible, but include separate root domains when the user moves between them. Do not add every random referrer. Only add domains that are part of your owned customer journey.

9. Test the cross-domain handoff.

Open your main domain in a private browser window. Click the link that sends users to the checkout, booking, or payment domain.

Look at the destination URL. You should see a _gl parameter in the URL, such as _gl=1*abc123*.... That parameter helps GA4 carry the same client ID across domains.

Open browser DevTools, go to the Application tab, then Cookies. Compare the _ga cookie before and after the domain switch. If the client ID changes, cross-domain tracking is still broken.

10. Check Realtime and DebugView.

In GA4, go to Reports, then Realtime. Open your site in a private window and accept analytics cookies. You should see your visit appear within a minute or two.

Then go to Admin, click DebugView, and repeat the test. Open your main page, move to the second domain, and trigger the key conversion event. You should see one user flow, not two separate users.

11. Check the main reports after 24-48 hours.

After you publish fixes, wait at least 24 hours. GA4 standard reports can lag behind Realtime.

Compare the same date range before and after the fix. Check Reports, then Acquisition, then Traffic acquisition. Also check Engagement, then Landing page.

If traffic returns but conversions still look low, check your conversion events next. If both traffic and conversions are still wrong, move to the related fixes below.

Alternatives / Related Fixes

1. Fix the cookie banner order.

If Consent Mode looks wrong, the problem may be the order of scripts. The CMP must set default consent before the GA4 tag fires.

In GTM, place the CMP update on Consent Initialization - All Pages. Keep the GA4 tag on Initialization - All Pages or All Pages, depending on your setup. I prefer testing this with the GTM Preview mode before publishing.

2. Check WordPress caching and plugin conflicts.

If you use WordPress, clear the site cache after changing analytics tags. Caching can serve an old GA4 snippet or old cookie banner script.

Also check whether you have multiple analytics plugins active. A common setup has Site Kit, a theme option, and a manual header script all adding GA4. That can create duplicate hits or conflicting consent states.

3. Fix duplicated tags.

Open GTM Preview and check whether the GA4 tag fires once per page. If it fires twice, users and page views can look wrong.

Also check your theme header, SEO plugin, and analytics plugin. Remove duplicate GA4 snippets. Keep one clean source of truth, usually GTM or one verified WordPress plugin.

4. Review campaign tags and referrers.

If traffic looks wrong only in source and medium reports, check your UTM tags. A broken campaign tag can push users into Direct, Referral, or Unassigned.

Use Google’s Campaign URL Builder for paid and email links. Keep naming consistent. Do not mix utm_source=facebook, utm_source=Facebook, and utm_source=Meta Ads for the same channel.

5. Reinstall or reset only as the last step.

I treat reinstall or reset as the last option. It can wipe working settings, break consent history, and create duplicate tags if you forget to remove the old code.

Reset only after you confirm the GA4 ID, Consent Mode, data filters, and cross-domain setup are still wrong. Before reset, export your GTM container and write down your current GA4 settings.

Decision Summary

If traffic dropped after a cookie banner launch → check Consent Mode first.

If Realtime works but standard reports look low → wait 24-48 hours, then check filters and attribution.

If office or VPN visits are missing → check Data filters and internal IP rules.

If users split between your main site and checkout domain → fix cross-domain tracking.

If Search Console clicks do not match GA4 users → compare landing pages and sessions, not clicks against users.

If the GA4 tag is missing or firing twice → fix the base install before changing advanced settings.

FAQ

Q: Why did my GA4 traffic drop after website setup?

A: The most common reasons are Consent Mode, data filters, duplicate tags, or cross-domain tracking. A cookie banner can block analytics until a visitor accepts. A filter can remove real traffic. A second domain can start a new session and split your numbers.

Q: Can Consent Mode make GA4 traffic look lower?

A: Yes. If analytics_storage is denied, GA4 may receive limited or modeled data depending on your setup. This is normal in privacy-focused setups, but the consent signal must still be configured correctly. I always test both accept and decline states before publishing.

Q: How do I know if cross-domain tracking is broken?

A: Click from your main domain to your checkout, booking, or payment domain. Check whether the destination URL has a _gl parameter. Then compare the _ga cookie client ID before and after the click. If the client ID changes, GA4 is likely treating the journey as two users.

Q: Do GA4 filters remove old data?

A: No. Active filters

Related Guides

• Website Setup — Browse all guides in this category
• Understanding Sitemap & Indexing: How to Fix Crawling Issues — Direct Answer: Understanding Sitemap & Indexing is crucial for fixing crawling issues and boosting y
• undefined —
• undefined —