The short version: Your GA4 landing page report is almost never “broken”, it’s fragmented, usually by query strings, trailing slashes, or redirects splitting one page into ten rows. Fix the data collection (not the report) and the numbers sort themselves out. I’ve spent whole afternoons on this exact problem for clients, and it’s rarely the dramatic bug people assume it is.
Useful alongside this: Should You Index Your PPC Landing Pages for SEO?.
I got a panicked email from a client last year: “Lilach, our best landing page has disappeared from GA4.” It hadn’t disappeared. It had split into 14 different rows because their PPC agency was appending fbclid, gclid, and three different utm_content variations to the same URL. Fourteen rows, each showing 20 to 40 sessions, none of them looking like “the top landing page” anymore. The page was fine. The tracking was a mess.
This is the pattern I see over and over when someone tells me their landing page isn’t “showing correctly” in GA4. The page is loading fine. The tag is firing fine. The data is just scattered across variations of the same URL, or hidden behind a redirect, or sitting under “(not set)” where nobody thinks to look.
Query strings are the number one culprit
GA4 builds its Landing page dimension from the full page_location parameter, which by default includes everything after the question mark. UA used to have a built in setting, “Exclude URL Query Parameters”, that quietly stripped this for you. GA4 does not do this automatically for the plain “Landing page” dimension in every context, and that trips up almost everyone moving over from Universal Analytics.
So a single ad linking to /black-friday-sale?utm_source=facebook&utm_medium=cpc&fbclid=abc123 can generate a different row for every unique click ID appended by Facebook, because fbclid changes on every single click. I’ve watched a client’s “top landing page” data fragment into over 40 separate rows in a single week because of this one parameter alone.
The fix, practically:
- In GA4’s Explore reports, use the “Landing page” dimension (not “Page path + query string”) wherever it’s available, since this version is meant to be the cleaner, query-string-stripped one.
- Better still, fix it at the source in Google Tag Manager: create a Custom JavaScript variable that strips the query string from the page URL, then in your GA4 Configuration tag go to Fields to Set and override page_location with that cleaned variable, applied across all page view and event tags.
- If you’re not confident touching GTM yourself, this is exactly the kind of quiet, unglamorous fix an AI consultant for small business or analytics specialist should be doing in the first month of any engagement, because it affects every report downstream, not just this one.
Trailing slashes: the split nobody notices
Here’s one that catches even experienced marketers out. yoursite.com/shop and yoursite.com/shop/ are, to a browser and to most humans, the same page. To GA4, they are two completely different strings, and therefore two completely different landing page rows.
I checked this on a client’s site last month out of habit and found their traffic to one core service page split 61% to the no-slash version and 39% to the slash version, purely because of internal links, old backlinks, and a CMS that generated URLs inconsistently depending on which template built the page. Neither number on its own looked like the real total. The real total was the sum, and nobody had ever added them together.
Fix this with a 301 redirect at the server level so one version always resolves to the other (this is squarely in the territory of technical SEO you can improve without a developer, using free tools to audit and redirect at the CMS or hosting level). Once the redirect is in place, GA4 will start reporting one consistent URL going forward. It won’t retroactively merge your historical data, so don’t be surprised if the split still shows in last month’s report.
“(not set)” landing pages: what’s happening
When you see “(not set)” filling a chunk of your Landing page report, it means GA4 received a session with no readable page_location value attached. The most common causes I find, in order of frequency:
- Consent Mode is blocking the page_location parameter because a user declined analytics cookies but the tag still fired a stripped event.
- A single page app or a page built with heavy client-side routing fires the GA4 config tag before the URL has fully resolved.
- Server-side tagging is stripping or renaming the parameter somewhere in the pipeline between the browser and Google’s servers.
- Cross-domain measurement isn’t configured, so a user moving from a checkout subdomain back to the main site loses referrer and landing page context and gets logged as a new, blank session.
The uncomfortable bit that most guides skip over: a small amount of “(not set)” data, usually somewhere under 3 to 5 percent, is completely normal and not worth chasing. GA4 uses modelling and probabilistic matching for privacy reasons, and some sessions will always arrive incomplete. If you’re seeing 20 percent or more, that’s a real configuration problem. If you’re seeing 2 percent, stop looking, you’re wasting billable hours on noise.
Session scoped versus first user landing page: they will not match
This is the one that causes the most confused Slack messages between marketing teams and whoever manages the GA4 property. GA4 has both “Landing page” (session scoped, meaning the page that started this particular session) and “First user landing page” (the page that started this user’s very first ever session on the property). If someone visits your homepage in January, then comes back three months later through a Google ad landing on a different page, the session scoped landing page for that second visit is the ad’s page. The first user landing page is still the homepage from January.
If two people on your team pull “landing page” numbers from different report templates without checking which version they used, the totals will not agree, and neither of you is wrong. I’ve sat in meetings watching this exact disagreement eat 20 minutes because nobody checked which dimension the other person’s chart was built on.
The redirect problem almost nobody mentions
Here’s the part that most articles on this topic quietly avoid, because it makes GA4 look worse than it is: if your marketing team runs ads or emails pointing to a URL that then 301 redirects to a different final URL, GA4 usually logs the landing page as the destination the browser ends up on, not the URL that was clicked. That means your beautifully built campaign landing page, the one you set up for a webinar registration push or a seasonal promotion, might show almost no direct traffic in GA4 if it silently redirects into your main site structure, even though hundreds of people clicked the link in your email.
This isn’t a GA4 bug. It’s a redirect doing exactly what redirects do, and it’s a genuine architecture decision, not something to fix inside the analytics tool. If you need to see the entry point people clicked, that data belongs in your ad platform or email platform’s own click reporting, not in GA4’s landing page dimension, because GA4 is reporting what the browser settled on, not what the user typed or tapped.
Step by step: how I audit a broken landing page report
When a client tells me their landing page data “looks wrong”, this is the actual sequence I run through, usually in under an hour:
- 1. Open GA4 Explore, build a fresh table with the “Landing page” dimension (not page path + query string), no filters, last 30 days.
- 2. Add “Session source / medium” as a secondary dimension to see if the fragmented rows share a source, which usually points straight at query string pollution from ads.
- 3. Search the table for both a trailing slash and non slash version of your top 5 known pages, and add the two numbers together to see the real total.
- 4. Check the percentage of traffic under “(not set)”. Anything under 5 percent, move on. Anything higher, check Consent Mode settings and cross-domain configuration in Admin, under Data Streams.
- 5. Cross-check one campaign’s click numbers in the ad platform against GA4’s session count for that campaign’s intended landing page. A gap wider than 15 to 20 percent usually means a redirect is eating the real landing page.
- 6. If everything above checks out and the number still looks wrong, check the actual page in an incognito window with GTM’s preview mode running, because sometimes the page itself is misfiring the tag, and this is where a real bug, rather than a data structure issue, lives.
Most of the time, step 3 and step 2 solve it. I’d say in roughly 8 out of 10 cases I’ve worked on, the “landing page not showing correctly” complaint is fixed by cleaning query strings and merging slash variants, not by touching a single tag.
When it isn’t a GA4 issue at all
Sometimes the real problem sits outside analytics entirely and someone’s been blaming GA4 for weeks. I’ve seen a landing page built for a local campaign that simply wasn’t indexed correctly, similar to issues that come up when clients ask about local SEO costs and real numbers without realising their tracking looked fine because the page itself had almost no organic visits to track. I’ve also seen a rebuilt homepage where new messaging changed user behaviour so much (people bouncing straight off a confusing new headline) that the landing page report looked “wrong” when it was accurately reporting a real conversion problem, the kind you’d catch by reviewing your homepage messaging for lead generation rather than your tracking setup.
Before you spend a day debugging tags, ask the boring question first: is the data wrong, or is it showing you something true that you don’t want to be true? Both feel the same in a dashboard. Only one of them needs a technical fix.
Frequently asked questions
Why does my GA4 landing page report show multiple rows for the same URL?
This almost always comes from query strings, most commonly utm parameters or click IDs like fbclid and gclid, being included in the page_location value. Each unique combination creates a separate row. Strip the query string at the tag level in Google Tag Manager, or use the “Landing page” dimension instead of “Page path + query string” in Explore reports.
Why is my GA4 landing page data showing “(not set)”?
“(not set)” usually means a session arrived without a readable page_location, most often because of Consent Mode blocking data, cross-domain measurement not being configured, or a single page app firing the tag before the URL resolves. Under 5 percent is normal privacy-related modelling noise and not worth chasing.
Why don’t my landing page numbers match between two GA4 reports?
You’re likely comparing “Landing page” (session scoped, tied to that specific visit) with “First user landing page” (tied to the very first session a user ever had on your property). They measure different things and will not match, and that’s expected behaviour, not an error.
Why does GA4 show a different landing page than the URL I advertised?
If your advertised URL includes a 301 redirect, GA4 typically records the final destination URL as the landing page, not the original link someone clicked. This is a redirect behaviour, not a GA4 fault, and you’ll need to check click data in your ad or email platform if you need the original entry URL.
