People searching for GA4 search terms are looking for one of two completely different things, and the confusion between them wastes a lot of time. One is what visitors typed into your site’s own search box. The other is what people typed into Google before clicking through to you.
GA4 handles the first one well and does not handle the second at all. Getting both is straightforward once you know which tool owns which question.
Two different things share the name
On-site search is a behavior you can measure directly, because it happens on your pages. GA4 captures it through the view_search_results event and the search_term parameter, and the data is genuinely yours — no sampling by a third party, no estimates.
Google search queries are a different animal. Google has not passed keyword data to analytics platforms since the “not provided” change over a decade ago, and GA4 changed nothing about that. There is no GA4 report, no exploration, no setting that reveals which query drove an organic session. Anyone telling you otherwise is describing Search Console.
Turning on site search tracking
Enhanced measurement handles this automatically for most sites. In Admin → Data streams, open your web stream, click the gear next to Enhanced measurement, and confirm “Site search” is enabled.
With it on, GA4 watches the URL for common search query parameters and fires view_search_results when it finds one, attaching the typed string as search_term. The default parameters it looks for are q, s, search, query, and keyword. If your site search URL looks like /search?q=running+shoes, you are already collecting data and did not have to do anything.
Two things worth checking immediately. Enhanced measurement fires on page load, so a search results page that renders without a URL change will not be caught. And the parameter list is exact — ?searchterm= is not on it.
Enhanced measurement also fires view_search_results for internal site search only. It has nothing to do with Google. If you enable it and then wonder why no Google queries appeared, that is the confusion this whole article exists to clear up.
Non-standard search URLs
If your search uses a different parameter, add it. In the same Site search settings panel, expand the advanced settings and enter your parameter names — up to ten, comma-separated. Save, then run a test search and confirm in DebugView that view_search_results fires with a populated search_term.
Some setups need a manual event instead:
- Search results loaded without a URL change — common in single-page applications and AJAX search overlays. Push a dataLayer event when results render and fire a GA4 event named
view_search_resultswith asearch_termparameter from Google Tag Manager. - Search terms in the URL path rather than the query string, such as
/search/running-shoes. Extract the segment with a GTM variable and pass it as the parameter. - POST-based search forms — capture the input value on submit and send it explicitly.
Use the reserved event name exactly. A custom name like site_search still collects data, but it will not populate the built-in search reporting.
Where the data appears
The reporting is less obvious than the collection. Three places to look:
- Reports → Engagement → Events. You will see
view_search_resultsin the event list with a count. Useful for volume, useless for the actual terms. - Explorations. This is where the terms live. Open a free-form exploration, import the Search term dimension, add Event count and Key events as metrics, and add a filter for event name equal to
view_search_results. That table is your site search report. - Reports → Library. You can add Search term as a dimension to a customized detail report and publish it so non-analysts can reach it without building an exploration.
A caveat with real consequences: search terms are high-cardinality by nature. On a busy site the long tail will overflow GA4’s row limits and collapse into an “(other)” row, so the interface will show you the head reliably and the tail poorly. If the tail matters — and for content planning it usually does — BigQuery export gives you every term with no collapsing.
Expect data thresholding to hide some low-volume rows too, particularly when Google signals are active. Rare, oddly specific queries are exactly the ones GA4 is most likely to withhold.
Turning site search into content decisions
Site search is the most under-used SEO input most teams have. Visitors typing into your search box are telling you, in their own words, what they expected to find and did not.
Three reads worth doing monthly:
- High-volume terms with no matching page. Direct content gaps, confirmed by people who already trust you enough to be on the site. These are the safest article briefs you will ever write.
- Terms with high search volume but low key-event rate afterwards. The page exists but does not answer the question. A rewrite, not a new page.
- Vocabulary mismatches. When visitors consistently use a word your site never uses, your titles and headings are speaking the wrong language — and that mismatch is usually costing you organic rankings too.
Add search_term-driven analysis to your navigation decisions as well. Repeated searches for something already in the menu means the menu is not working.
Track the outcome, not just the term. In your exploration, add key events as a metric alongside event count, and add a second table showing sessions that included a search versus those that did not. On most content sites searchers convert at a noticeably higher rate, which is a straightforward argument for investing in the search experience — and a number worth having before someone proposes removing the search box in a redesign.
Google queries: Search Console is the only source
For organic search queries, Search Console owns the data. Performance → Search results gives you queries, impressions, clicks, average position, and CTR, filterable by page, country, device, and search appearance.
Know its limits so you read it honestly. Search Console reports up to 1,000 rows per query in the interface, applies its own anonymization to rare queries, and average position is an average across impressions rather than a rank you held. It also does not show what those visitors did after arriving — that half belongs to GA4.
Linking Search Console to GA4
You can link a Search Console property to GA4 in Admin, then publish the Search Console collection from Reports → Library to make it visible. Do it — but set expectations.
The linked reports surface a limited slice: queries and landing-page performance in two fixed reports. You cannot combine query data with arbitrary GA4 dimensions or metrics, you cannot use query as a dimension in an exploration, and you cannot attribute key events to individual queries. The link is a convenience, not an integration.
Two practical consequences. If someone asks “which query produced this month’s revenue”, the honest answer is that no Google product will tell you at query level, and any tool claiming otherwise is modeling it. And if you need query data joined to behavior, you have to export both sides — Search Console via its API or bulk export, GA4 via BigQuery — and join them on landing page, which is the closest usable key.
Reading both sides in one place
The practical workflow is to treat them as two halves of one question. Search Console tells you what earned the click — which queries, which pages, what position. GA4 tells you what happened next — engagement, key events, revenue. Site search tells you what your existing visitors could not find. Together they cover the whole journey; separately each one leads to a partial conclusion.
Keeping them together is the annoying part in practice, especially once third-party rank and volume estimates enter the picture. SEO Rocket connects Search Console and GA4 as ground truth for your own site and shows that measured data beside third-party estimates, clearly labeled so a modeled volume figure is never confused with a recorded click. It does not replace GA4 or implement your site search tracking — the enhanced measurement setup above is still your build. It just puts the measured query and behavior data next to the estimated market data, which is where content decisions should be made anyway.
