What GA4 and Search Console Will Never Tell You (And How to Get It Anyway)

TL;DR: GA4 and Search Console each hold half of your organic search picture, and Google has no plans to join them. Search Console knows the query, the impression, and the click, then stops. GA4 picks up at the session and is never told what was searched for. On top of that split, both interfaces cap, sample, and bucket what they show you. The questions worth asking - which queries earn money, which pages are quietly decaying, whether a 3% CTR is good at position 4 - all live in the gap. Both products export raw data to BigQuery for free. Joining those two exports takes a modelling layer, and once you have one, you get reports neither dashboard can produce.

Every organic search team runs the same weekly ritual. Open Search Console, look at the click trend. Open GA4, look at organic sessions. Squint at both, notice they disagree, decide it does not matter this week, and move on.

The ritual persists because the two products are genuinely useful and genuinely incomplete, in a way that is easy to feel and hard to name. This post tries to name it.

The seam runs through the click

Search Console measures what happens in the search results. It knows the query someone typed, how many times you appeared, where you ranked, and whether they clicked. The moment the click lands on your site, its knowledge ends.

GA4 measures what happens on your site. It knows the landing page, the session, the scroll depth, the form submission, the purchase. It has no idea what was searched for, because Google stopped passing the query to analytics in 2011 and has never resumed.

Every interesting question sits across that seam:

• Which searches produce revenue?
• Is this page ranking well and converting badly, or the other way around?
• Does the comparison content we published last quarter actually generate pipeline?
• Which of these thousand keywords deserves an hour of someone's week?

Neither product can answer any of them, and no amount of clicking around will change that. The answer requires putting a Search Console row next to a GA4 row, and only you can do that, because only you know that https://example.com/pricing/ and /pricing are the same page.

Six things the interfaces will not show you

The seam is the structural problem. Sitting on top of it are a set of narrower limitations that are individually annoying and collectively decisive.

1. Whether a CTR is good for where you rank

Search Console shows CTR and average position side by side. It never tells you whether that CTR is good at that position.

This sounds like a small thing. It is the difference between two completely different work items. A 2% CTR at position 3 means your title and description are failing - a thirty-minute fix with an immediate payoff. A 2% CTR at position 15 means nothing at all, because almost nobody scrolls that far. In the interface, those two rows look identical.

The usual workaround is to compare against a published CTR curve from an industry study. That is worse than useless, because CTR at a given position varies enormously by brand recognition, by query intent, and by how many search features sit above the organic results. A well-known brand might earn 30% at position 1. A site nobody has heard of, ranking for the same query, might earn 8%. Judged against the published curve, that site has a catastrophic problem. Judged against its own behaviour, it is doing fine.

The curve you need is the one your own property earns. It is a two-line aggregation over data you already have, and neither product computes it.

2. Which queries produce outcomes

This is the big one, and Google's position on it is deliberate rather than accidental. The search query is not passed to analytics, so no report in GA4 can break anything down by keyword, and no report in Search Console knows what happened after the click.

The practical result is that most teams prioritize keywords by click volume, which is a proxy for nothing. A glossary page ranking for a definition and a pricing page ranking for "acme pricing" are indistinguishable in a click report. They are not remotely equivalent in what they contribute.

You cannot measure query-level outcomes even with the exports. What you can do is allocate them: split each page's outcomes across the queries that sent clicks to it, in proportion to those clicks. It is an estimate, and it is wrong in a predictable direction - a high-intent query really does convert better than its page's average, so this understates it. But an estimate that ranks queries roughly right beats a click count that ranks them by nothing at all.

Being explicit about what is modelled versus measured matters here. A number that is honest about its own assumptions can be argued with. A number that arrives with no provenance gets either believed or ignored, and both are bad.

3. Which pages are quietly decaying

Search Console can compare two date ranges. It does this one view at a time, within an interface that caps at 1,000 rows.

Content decay does not announce itself. A page loses 8% of its clicks one month and 11% the next, and never produces a drop visible on the overview chart. Multiply that across a few hundred pages in the long tail and you have a real, compounding traffic loss that no dashboard view will surface, because the long tail is exactly what falls off the bottom of a 1,000-row export.

The version you want is every page, current window versus prior window, classified into growing, declining, stable, new, and lost, sorted by absolute clicks lost. That is one query over the export and it does not exist anywhere in the product.

Reporting position change next to click change is what makes the output actionable. Clicks down with position flat usually means seasonality or a search feature taking the click - nothing you can do. Clicks down with position worse means the page lost ground, and that is a work item.

4. Which queries your own pages are fighting over

The Search Console interface can filter by query. It can group by page. It cannot pivot one against the other.

So when three of your blog posts and one product page all rank for "data pipeline tools", you find out by accident - if you find out at all. Splitting a query across several of your own pages divides the signals Google uses to rank any one of them, and generally leaves all of them ranking worse than a single consolidated page would.

Finding these means exporting both dimensions and reconciling them by hand, which is why almost nobody does it. It is a group-by away from free once the URL-and-query grain is in a table.

The nuance worth building in: not every match is a problem. A query legitimately served by a category page and a product page will show up too. What separates the real cases is how evenly the clicks are split, not how many pages appear.

5. What you started and stopped ranking for

Comparing two periods in Search Console shows you how the queries present in both moved. It does not show you which queries appeared and which vanished, because a query with zero impressions in one window is simply not a row.

Both halves of that diff are useful. New queries tell you what Google now thinks your site is about, which is the fastest feedback loop you have on published content. Lost queries are the earlier warning - a query typically disappears from the export a few weeks before the page it belonged to shows a click loss anyone notices.

6. Whether your brand is growing or your SEO is working

Search Console has no concept of a brand. Its headline click trend mixes people who already knew you with people discovering you for the first time.

Those two numbers move for completely different reasons. A podcast sponsorship moves branded search. A ranking improvement moves non-branded search. A headline chart that sums them tells you neither, and it is the chart that ends up in the monthly report.

Splitting them requires one thing the product cannot supply: a definition of your brand, including the misspellings. That is a regex you write once, and it changes what every other number means.

The interfaces have their own ceilings

Underneath all six of these sit limits in the reporting UIs themselves.

Search Console caps its interface at 1,000 rows per view. For a site with a hundred URLs, that is invisible. For a site with ten thousand, the interface is showing you the top of a distribution and hiding the part where the compounding problems live.

GA4 collapses high-cardinality dimensions into (other). When a report has more unique values than its cardinality limit allows, the excess is bucketed. On a large content site, landing page and query-parameter dimensions blow past that limit routinely, and (other) quietly becomes one of your biggest rows.

GA4 explorations get sampled above a threshold. Standard reports are not sampled, but they are also not where anyone does real analysis. The moment you build an exploration on a large property, you are looking at an estimate, and the estimate is fine for direction and useless for a number in a board deck.

GA4 thresholds low-count rows. With Google signals enabled, rows below a minimum user count are withheld entirely to protect anonymity. You are not told which rows.

Search Console retains 16 months. Year-over-year comparison works. Two-year trend does not.

None of these is a scandal. They are reasonable engineering decisions for free products serving millions of properties. They are also the reason that the analysis you want has to happen somewhere else.

The exports already solve half of it

Here is the part that surprises people: Google gives you the raw data, for free, in both cases.

The GA4 BigQuery export streams every event to BigQuery. No sampling, no (other) bucket, no thresholding, no cardinality limit. One row per event, with every parameter.

The Search Console bulk data export writes daily query-and-URL level data to BigQuery. No 1,000-row cap. Every query Google is willing to disclose, at both property and URL grain, forever - it does not expire at 16 months once it is in your warehouse.

Both take about ten minutes to enable. Most teams that have them enabled them a year ago, ignored them, and pay a few dollars a month in BigQuery storage for data nobody queries.

The exports remove the ceilings. They do not remove the seam. Raw GA4 events and raw Search Console rows still have no common key: Search Console reports a canonical absolute URL, GA4 reports whatever page_location your tag collected including query strings and fragments, and the two only line up after you normalize both sides with identical rules.

They also do not remove the definitions. Nothing in either export knows what your brand is called, which URLs are documentation, which queries are commercial, or what a demo request is worth. Those are business facts, and they are the ones that turn a row count into a decision.

What a modelling layer adds

The work between "two exports in BigQuery" and "reports someone acts on" is not glamorous, and it is mostly the same on every site:

Normalize both sides identically. Lowercase, strip the scheme, drop the query string and fragment, remove the trailing slash. Do it in one shared macro rather than inline in each model, because the join only works if both sides are reduced by exactly the same rules - and if it does not work, the failure looks like a data problem rather than a code problem.

Keep hostname in the grain. A site that spans a marketing domain, a docs subdomain, and a blog subdomain will serve /guide on more than one of them. Joining on path alone sums unrelated pages together and dilutes the value of whichever host actually earns it.

Rebuild sessions from events. GA4's session concept is what you want; GA4's reporting of sessions is what has the cardinality and sampling limits. Rebuilding sessions from the raw event export gives you the concept without the ceilings.

Classify once, in staging. Brand, competitor, commercial intent, page role. Materialize the results so every downstream report agrees, rather than re-deriving them per query and drifting.

Keep the withheld rows. Google anonymizes rare queries. Those rows still carry real impressions and clicks, so dropping them makes daily totals wrong. Label them instead, and exclude them explicitly where the query is the grain.

Write the caveats into the models. Which columns are measured, which are allocated, where the two systems will not tie out and why. Put it in the asset description next to the SQL, not in a wiki page that nobody opens.

None of that is novel analytics engineering. It is just the part that never gets done, because it sits between two teams and no product will do it for you.

The reports you get out of it

Once the layer exists, the reports fall out of it. The ones that repay the effort fastest:

The last one is worth dwelling on, because it is the report that changes budgets. Crossing query intent with page role produces a table shaped roughly like this:

Eighty percent of the clicks produce thirteen percent of the value. That is not automatically an argument against content marketing, because informational content is often how a site earns the authority to rank commercially later. But it is the number that should decide what gets built next quarter, and it exists in neither product, at any price, in any view.

There is a second, unglamorous payoff that shows up on the first run. A full outer join between the two systems produces a column explaining every mismatch, and the search_only rows - pages Search Console reports clicks for that GA4 never recorded - are almost always a tracking bug you did not know you had. A blocked script, a redirect chain, a consent banner firing too late. Most teams find at least one page that Google has been sending real traffic to for months while their analytics saw nothing.

The honest caveats

Anything claiming this join is clean is selling something.

The two systems will never tie out exactly. They are different measurement systems with different definitions and different timezones - Search Console dates are Pacific Time, GA4 uses your property's reporting timezone. A session-per-click ratio near one is healthy. Treat a low one as a tracking lead, not a bug in the report.

Query-level value is allocated, not measured. Say so every time you present it. It ranks queries; it does not measure them.

GA4's streaming export has weaker session attribution than the daily tables, because Google does not populate session-scoped traffic source in intraday tables. You fall back to collected and user-scoped sources and end up with a large unattributed bucket. In practice that bucket lines up closely with what GA4 itself calls Direct, so organic ends up a close floor rather than a total - but it is a floor, and you should measure your own gap before quoting a channel number.

Neither export backfills. They both start the day you enable them. If you have been ignoring them for a year, congratulations, you have a year of history. If you enable them today, your first useful trend report is two months away. Which is the best argument for turning them on before you need them.

Getting there

Everything above is a modelling problem with a known shape, which makes it a good fit for a template rather than a project.

We packaged it as google-web-analytics, a Bruin template that reads both exports where they land and publishes the nine reports in that table. It ingests nothing, because both products already export natively. It ships 19 assets, a documented column schema on every one, 166 quality checks, and three dashboards you serve locally against your own BigQuery.

bruin init google-web-analytics my-search-pipeline

Set two dataset names and your brand pattern, price your key events, and run it. The step-by-step guide walks through the configuration that decides what the reports mean, the two silent failure modes worth checking first, and how to extend it with a coding agent.

It is a starting point rather than a finished product. The classification rules are variables, the URL logic is one macro, and the point of shipping it as code is that you can argue with the definitions - which is more than either Google product will ever let you do.