Most people open a report looking for GA4 search terms expecting to see the words visitors typed into Google before landing on their site. That data isn’t there, and it never will be. Google stripped organic query keywords out of analytics back in 2011 — the infamous “(not provided)” — and GA4 inherited the same wall. What GA4 does show is the phrases people type into your own site’s search box. Two completely different datasets, one confusingly similar name. Get the distinction wrong and you’ll spend an afternoon hunting for a report that doesn’t exist.
The two things “GA4 search terms” can mean
When someone asks about GA4 search terms, they mean one of two things, and the right answer depends entirely on which. The first is on-site search: what a user typed into the search field on your website — “returns policy,” “size 10 running shoe,” “cancel subscription.” GA4 captures this natively and it’s genuinely useful. The second is organic search queries: what someone typed into Google, Bing, or an AI answer engine that led them to click through to you. GA4 does not and cannot show that. Only Google Search Console holds it, and only for Google. Everything below is organized around that fork, because conflating the two is the single most common mistake in this topic.
How GA4 actually captures on-site search
GA4’s on-site search tracking rides on a feature called enhanced measurement. When it’s on, GA4 watches every page URL for a set of query parameters that typically carry search input. By default it looks for five: q, s, search, query, and keyword. If a page loads at example.com/results?q=running+shoes, GA4 sees the q=running+shoes, fires a view_search_results event, and files “running shoes” under the search_term dimension. No tagging, no code — it’s parameter pattern-matching on the URL.
To switch it on, go to Admin → Data streams → your web stream → Enhanced measurement, click the gear icon, and confirm “Site search” is enabled. It usually is by default, but the parameter list is worth checking. If your search engine uses a parameter that isn’t in the standard five — plenty of platforms use term, text, or keywords — add it in the same panel. You can list up to ten, comma-separated. Miss this and GA4 silently records nothing while everything looks configured correctly.
When the default quietly fails
Parameter matching only works when the search term lands in the URL as a query string. Three common setups break that assumption, and each needs a manual view_search_results event pushed through Google Tag Manager or gtag:
- Single-page apps (React, Vue, headless builds) that update results without a full page reload — the URL may never change, so there’s no parameter for GA4 to read.
- Path-based search like
/search/running-shoes, where the term sits in the URL path, not a?q=parameter. - POST-based forms that submit the query in the request body and return results without ever exposing the term in a URL at all.
The tell-tale symptom is a search box you know people use, paired with a search_term report that’s empty or near-empty. If that’s you, the fix is a manual event carrying the search_term parameter — not more tinkering with the enhanced-measurement panel, which can’t see what isn’t in the URL.
Where the on-site data actually lives
Once events are flowing, the data shows up in a few places, and the flexible ones are worth learning. Reports → Engagement → Events lists view_search_results with a count, but that only tells you how often people searched, not what for. To see the actual phrases, build an Exploration: Explore → blank, drag Search term in as a row dimension, add Event count, Total users, and a conversion or engagement metric as values. Now you’ve got a ranked list of what people hunt for on your site, sorted by demand. You can also pin a custom report to Reports → Library so non-analysts can read it without touching Explorations.
A worked example: turning a search box into a content brief
Say you run a mid-sized ecommerce store and the Exploration surfaces “gift card” as the third most-searched term — 400 searches last month — but the page it lands on has a 15% engagement rate and near-zero conversions. That single row tells you three things at once: there’s real demand (people are actively looking), your current answer is failing them (they search, land, bounce), and you have a concrete revenue lever (a clear gift-card landing page, or a fixed nav link). Compare that against a term like “does your product contain nuts” appearing 60 times with no matching page at all — that’s not a UX fix, that’s a missing FAQ or product-detail field. On-site search is the only report where users tell you, in their own words, exactly what they came for and couldn’t find. Read it as a backlog, not a vanity metric.
Two traps that quietly corrupt the data
On-site search data has two failure modes that don’t announce themselves. The first is the “(other)” row. Standard GA4 reports cap unique dimension values — high-cardinality dimensions like search_term can overflow, and everything past the limit gets bucketed into a single “(other)” row. On a busy site with thousands of distinct queries, your long tail vanishes into that bucket. The fix is to query the data in a way that respects the raw grain: Explorations pull from a larger set than the aggregated standard reports, and the BigQuery export removes the cap entirely if you need every term.
The second trap is PII. Site search boxes are where users paste order numbers, email addresses, and occasionally credit-card digits. Google’s terms prohibit sending personally identifiable information to GA4, and a search term like “john.smith@email.com order #4471” is exactly that. Set up redaction — GA4 has built-in data redaction for emails and configurable patterns on the web stream — before this becomes a compliance problem rather than after.
Google organic queries: Search Console is the only source
Now the other fork. If what you actually want is the Google queries that drove traffic to your pages, GA4 will not give it to you at any level of configuration. That data is (not provided) by design and lives exclusively in Google Search Console. Search Console shows the queries, impressions, average position, and click-through rate for the terms your pages rank on — the closest thing to a keyword-level view of your organic performance. Its own limits matter: it samples and thresholds low-volume queries for privacy, the standard UI caps at 1,000 rows per report, and it only covers Google, not Bing or the growing share of clicks now coming from AI answer engines. But for “what did people search on Google to find me,” it’s the only honest answer.
Linking Search Console into GA4 (and what you gain)
You can surface a slice of Search Console data inside GA4 by linking the two: Admin → Product links → Search Console links → Link, then choose the property and publish the associated reports. Once linked, GA4 gains a “Search Console” report collection showing organic queries alongside landing-page engagement — a partial bridge between “what they searched” and “what they did after arriving.” Be clear about the ceiling, though: the linked view is thinner than Search Console’s own interface, still doesn’t merge query data into your event stream, and won’t backfill history from before the link date. For serious query analysis, work in Search Console directly and treat the GA4 link as a convenience, not a replacement.
From search terms to a content plan
Both datasets are diagnostic — they tell you what’s already happening on your own property. The strategic move is to pair them with external demand. On-site search reveals unmet intent from people already on your site; Search Console reveals the Google queries you already rank on (and, by their absence, the ones you don’t). But neither shows the searches happening across your entire market that you have no visibility into yet. That’s the gap external keyword data fills. This is exactly the workflow SEO Rocket is built around — its AI keyword research runs on real Ahrefs index data, so a “gift card” or “nut allergy” term you spotted in GA4 becomes a full picture: real monthly volume, keyword difficulty, and the competitors already ranking for it. The site’s competitor gap analysis then shows which of those queries rivals capture that you don’t, turning a raw GA4 search-term row into a prioritized content brief.
From there, SEO Rocket’s validation-gated AI writer drafts the page to a real editorial standard rather than a word-count minimum, and its rank tracking plus AI-visibility tracking tell you whether the new page actually earned the position — closing the loop from “user searched and found nothing” to “page published and ranking.” It’s the same playbook proven across 1,000,000+ ranking pages: let your own search data name the demand, then validate it against the wider market before you commit the work. At roughly $50/month with a free tier, it’s built to run that cycle continuously instead of as a one-off audit.
Frequently asked questions
Can GA4 show me the Google keywords people used to find my site?
No. Organic query keywords are “(not provided)” in GA4 and always have been. The only source for the Google searches that led to your site is Google Search Console, which you can link into GA4 for a partial in-tool view but not merge into your event data.
Why is my GA4 search_term report empty even though people use my search box?
Almost always because the search term isn’t in the page URL as a query parameter GA4 recognizes. Check that “Site search” is enabled under enhanced measurement and that your search parameter is in the list. If your site is a single-page app, uses path-based search, or POST forms, you’ll need to send a manual view_search_results event instead.
What is the “(other)” row in my GA4 search terms report?
It’s an overflow bucket. Standard GA4 reports cap the number of unique values for high-cardinality dimensions like search term; everything beyond the cap collapses into “(other).” Use an Exploration or the BigQuery export to see the full long tail of terms.
Do on-site searchers convert better than other visitors?
Often, but not always — treat it as a hypothesis to verify in your own data, not a rule. People who search usually have clearer intent, so segmenting by the view_search_results event and comparing conversion rates against non-searchers is a quick, worthwhile check before you invest in improving the search experience.
The bottom line
The whole confusion around GA4 search terms dissolves the moment you separate the two datasets. On-site search — what people type into your search box — is captured natively, sits in Explorations, and is one of the most direct signals of unmet demand you’ll ever get, provided you check your parameters, respect the “(other)” cap, and redact PII. Google organic queries — what people typed to find you — live only in Search Console, “(not provided)” everywhere else. Read each in the right place, connect them to real external keyword data, and your own analytics stops being a mystery and starts being a content roadmap.
