How to Find Not Provided Keywords in Google Analytics

Did you know? 46.77% of the search queries that land on your site are anonymized before they reach Google Search Console. That number comes from Ahrefs’ April 2025 analysis of 22 billion clicks across 887,534 GSC properties, published by Patrick Stox in February 2026. The same restriction is why Google Analytics shows “(not provided)” instead of the organic query that brought the visitor to your site.

Most guides tell you to connect Search Console to GA4 and stop there. This guide shows what that connection actually recovers, what it cannot recover, and which five other methods help close the keyword-visibility gap.

This isn’t a GA4 setup-from-scratch guide. See our Google Analytics for B2B traffic guide for the tracking setup, reports, and traffic analysis foundation. This is the (not provided) recovery guide, and it assumes your GA4 property is already configured and reporting.

What “(not provided)” actually means in 2026

“(Not provided)” is the placeholder Google Analytics shows when the originating organic search query is encrypted before it reaches your property. Google started masking organic keywords in October 2011 to protect signed-in user privacy, and by 2013 had moved every organic search to HTTPS, at which point the query stopped appearing in the referrer string for every organic Google click.

The masking was a deliberate Google decision, not a bug or a configuration error. It applies at the network layer, which means no Google Analytics setting, plugin, or property type recovers the original query from inside the analytics property itself. The query data still exists. It sits in Google’s index and in Search Console. The link between an individual session and the query that produced it is severed before the session ever reaches your tag.

Search Console reports queries aggregated by page, country, and device, with a 16-month retention window. Google then anonymizes a substantial fraction of those queries to protect users. The Ahrefs February 2026 study put the anonymization rate at 46.77% of all queries across 22 billion clicks and 887,534 properties, up from 46.08% in 2022 and 45.02% in April 2024. Google’s own definition, quoted in the same study: “Anonymized queries are those that aren’t issued by more than a few dozen users over a two-to-three month period.”

Why GA4 didn’t restore organic keyword visibility

GA4 inherited the (not provided) restriction without modification, and migrating a property to GA4 does not recover any organic keyword data. The masking happens upstream of the analytics product itself, so the receiving system (GA4, Universal Analytics, Matomo, raw server log) makes no difference. Google removes the query before it reaches any of them.

GA4 also adds two new layers of opacity that worsen the visibility problem against the Universal Analytics baseline. Suganthan’s May 2026 attribution analysis reports that consent mode blocks GA4’s JavaScript on 20–40% of visits, and that GA4 consistently underreports organic traffic by 15–30% versus the same property’s UA history. The net effect: if your only data source is the GA4 interface, you are working from a smaller and more partial picture of organic search than you had in 2019.

None of the six recovery methods below changes the encryption itself. What they do is pull query and intent data from sources Google has not encrypted: Search Console’s visible portion, raw GA4 events, on-site search logs, Google Ads attribution, manual UTM tags, and landing-page-to-query inference. Each method has a different recovery surface, and only two speak directly to the organic query pool that (not provided) hides.

The 6 keyword visibility methods, ranked by what each one actually unlocks

Six keyword visibility methods help with the (not provided) data gap, but only two directly address the organic query pool. The other four expand visibility into adjacent data streams: paid clicks, on-site searches, tagged manual campaigns, and raw event exports. Treating them as equivalent leads to overclaim. Treating them as complementary gives you a more complete search-intent picture.

The table below is the scoping picture. Read the “Touches organic?” column carefully before you read the recovery rate. A 100% recovery rate on a method that doesn’t touch the organic pool means the method captures 100% of its own data source, not 100% of the original (not provided) traffic.

The first three steps are sequential because each one informs whether the next is worth the setup time. The HowTo block below covers the foundational workflow most operators should run regardless of stack.

Method 1: Link Search Console to GA4 (recovers ~53% of organic queries)

Linking Search Console to GA4 surfaces approximately 53% of your organic query data: the portion that isn’t anonymized. Ahrefs’ April 2025 analysis of 22 billion clicks across 887,534 GSC properties (Patrick Stox, February 2026) found that 46.77% of search queries are anonymized to protect user privacy and never appear in any report, regardless of which Google product is consuming the GSC data. The visible 53% is the upper bound on what any GSC-based recovery method can return.

The link itself takes under five minutes if you already have a verified Search Console property. In the GA4 Admin pane, open Property Settings, then Search Console Links, then Link. Pick your verified property, select the web data stream, and confirm. Query data starts populating GA4’s Search Console reports within 24 hours, and historical query data backfills as far as Search Console retains it (16 months).

What the linked reports give you is page-level query attribution: which queries drove clicks to which landing pages, with impressions, click-through rate, and average position. After the link is active, open GA4 and go to Reports → Acquisition → Search Console → Queries to see the search terms Google still reports. What the reports do not give you is a session-level join between a specific GA4 session and a specific query. Search Console aggregates; GA4 aggregates on a different cut. The two products share dimensions but never the same individual session.

The honest framing: if you have not yet linked Search Console to GA4, do it before reading further. It is the single highest-impact step and it is free. After that, the marginal value of additional methods depends on whether the 47% anonymized share matters to you and whether your other traffic sources (paid, manual, internal search) are themselves under-instrumented. The recovered query list is also raw material for the keyword research that should follow Search Console linking; the newly visible terms become a content plan against the topical gaps the data exposes.

Method 2: Build a BigQuery export pipeline (100% of events, attribution-ready)

The GA4 BigQuery export ships every event (page_view, session_start, view_search_results, custom events) to BigQuery, unsampled, on a daily or streaming cadence. The export doesn’t unmask (not provided) queries on its own. What it does is enable SQL joins between GA4 events, Search Console queries, and landing-page data: joins that no in-platform GA4 report can produce. For most B2B operators, this is the difference between “we know which page got the traffic” and “we know which query likely drove the conversion.”

Google’s BigQuery Export schema documentation details the event tables, the traffic_source RECORD, the session_traffic_source_last_click attribution data, and the event_params repeated field that holds custom dimensions. The export is available on every GA4 property (the Universal Analytics 360-only restriction is gone). Cost on BigQuery follows standard pricing: storage at $0.02/GB/month and queries at $6.25/TB scanned (as of Q2 2026), with the first 10 GB of storage and first 1 TB of queries free each month per project.

The attribution workflow most operators run on top of this looks like a three-table join: GA4 events keyed on landing page, Search Console queries keyed on the same page, and a normalization step that strips URL parameters and trailing slashes so the join keys match. The output is a query-level attribution table where each query gets its share of the page’s GA4 metrics distributed proportionally by clicks.

What the join cannot do is invent query-to-session attribution for the anonymized 47%. Those queries were never written to Search Console in the first place, so no SQL pulls them back. What the join can do is distribute the visible 53% across your landing pages with confidence, surface high-traffic pages whose attribution is concentrated in a small set of queries, and isolate the pages where (not provided) sessions disproportionately drive conversions: the pages where the inference methods (Method 5) earn their setup cost.

BigQuery is the most powerful method on this list. It is also the most operator-dependent. SQL fluency is required. A site that doesn’t have an engineer or analyst comfortable writing queries against a 100-million-row event table will not extract the value, and the storage cost still accrues. The decision matrix at the end of this article weights this trade-off. BigQuery also sits inside the broader technical SEO checks that pair with this; crawl health, indexing, and Core Web Vitals all affect what the recovered query data is worth.

Method 3: Track internal site search (100% of on-site search terms)

Internal site search captures the exact terms users type into your on-site search bar after they arrive from organic. GA4’s view_search_results event records these queries at 100% capture rate when the site_search dimension is configured against your search URL’s query parameter. The terms are an adjacent intent signal, not the original organic query. Users landed on your site from a search, then performed a second, on-site search that GA4 records verbatim.

The setup is two steps. In Admin → Data Streams → Web Stream → Enhanced measurement, toggle Site search on. Click the gear icon to specify the query parameter your search URL uses (typically q, s, or search). GA4 then writes the search term into the search_term event parameter on every internal search, accessible in standard reports and in BigQuery.

The data is most useful as a triangulation signal against your organic landing pages. A high-traffic page that drives many internal searches for the same term is a page whose original organic query likely matched that term. A page that drives internal searches for unrelated terms is a page where the original query and the user’s actual need diverged, which is useful for content gap analysis and for inferring what (not provided) queries probably said.

The honest scope: internal site search captures 100% of on-site searches, which is a small slice of overall organic traffic. Most users arrive from organic and leave without searching on-site. The method is high-signal where it applies and silent everywhere else.

Method 4: Pull Google Ads keyword data (100% of paid clicks)

Linking Google Ads to GA4 populates the Session Google Ads keyword text dimension for every paid click, at 100% recovery for Ads-driven sessions. The 100% applies only to paid Google Ads traffic, not to the organic (not provided) pool; organic Google queries stay hidden regardless. The link is found at Admin → Product Links → Google Ads Links and requires editor-level access in both products. Once linked, paid clicks no longer collapse into (not set) under organic; they appear under paid search with full keyword, ad group, and campaign attribution.

The scope is paid Google Ads only. Organic Google queries remain hidden, and the link does nothing for them. After the link is active, use Reports → Acquisition → Google Ads campaigns and add the Google Ads keyword text dimension to inspect paid keyword data. The value of this method for the (not provided) problem is indirect: for accounts running both organic and paid against the same keyword set, paid keyword data becomes a cleaner proxy for organic intent than landing-page inference, because the paid match-type, query, and conversion data are all complete.

For accounts that don’t run Google Ads, this method is a no-op. For accounts that do, it is the second-highest-impact step after the Search Console link, because the data is exact (not inferred) and the setup is a single click.

One trap to flag: auto-tagging in Google Ads must be on for the link to work. The Ads-side setting is in Account settings → Auto-tagging. Without it, the gclid parameter is missing from click URLs and the GA4 dimension stays empty. Verify the toggle is on before debugging anything downstream.

Method 5: Map landing pages to GSC queries (60–85% inference on single-topic pages)

Mapping landing pages to GSC queries infers which queries drove which sessions by joining GA4 landing-page traffic with the Search Console queries that page ranks for. Single-topic pages reach 80–85% inference accuracy (a self-reported certainty threshold from Keyword Hero, the SaaS tool that productizes this method). Generic and multi-topic pages return lower confidence, because the inference quality degrades with page intent ambiguity.

The manual version of this method is a spreadsheet join. In GA4, go to Reports → Acquisition → Traffic acquisition, filter for Organic Search traffic, and add Landing page + query string as the secondary dimension. Export that landing-page data, then export the GSC Queries report filtered by the same landing pages, and merge on URL.

Each page gets a query list; each query gets a click count. For example, if the landing page /ga4-consulting/ gets most of its visible GSC clicks from “ga4 consultant,” “ga4 setup agency,” and “ga4 migration help,” then conversions from that page can be grouped under GA4 setup and migration intent with reasonable confidence. If the same page ranks for 50 unrelated queries with no dominant term, confidence is low and the method should not be trusted.

The productized version of this method lives in tools like Keyword Hero, Semrush’s Organic Traffic Insights, and Suganthan’s open-source multi-signal BigQuery skill. Each tool runs a variant of the same logic with different ranking signals layered in (rank position, query similarity, click distribution). Pricing for Keyword Hero starts at $9/month for small properties and scales to $99/month for the Pro tier (as of Q2 2026). Semrush bundles Organic Traffic Insights into their Guru tier ($249.95/month as of Q2 2026), so it’s effectively free if you already pay for Semrush.

The honest scope, again: this is inference, not direct recovery. A page-to-query join distributes the visible Search Console query data across landing-page traffic on the assumption that visitors arriving at page X likely searched for the queries that page X ranks for. It is the best available approximation for the 47% anonymized share when the page has unambiguous intent. It is unreliable when the page doesn’t.

Method 6: Tag manual campaigns with utm_term (100% of tagged campaigns)

The utm_term parameter on manual campaigns populates GA4’s Session manual term dimension at 100% capture for any properly tagged URL. Bing Search, paid social, newsletter links, partner placements, and affiliate URLs all qualify. Organic Google traffic does not, because Google strips referrer keyword data regardless of UTM parameters and the original query never reached your site to be tagged in the first place.

The discipline that matters here isn’t the syntax (utm_term is straightforward); it’s coverage. Every manual URL your team ships needs the parameter, every time, with consistent value formatting. A single missing utm_term is a permanent gap for that campaign, because GA4 cannot retroactively assign a keyword to a session whose URL didn’t carry one. The session lands under (not set) and stays there.

The pre-launch audit is the lowest-effort, highest-coverage habit on this list. Run every campaign URL through a parameter checker before it goes live. Confirm utm_source, utm_medium, utm_campaign, and utm_term are present, lowercase, and consistent with your taxonomy. Reject any URL that fails the audit before it ships. The pre-launch URL audit this depends on catalogs the 14 rules (encoding, casing, naming consistency, channel-group fit) that catch the defects this method needs to stay clean.

Which method to use: a decision matrix by site, stack, and skill

The right recovery method depends on three things: how much of your traffic is paid versus organic, whether your stack can support SQL, and how much of your organic landing-page traffic concentrates on single-topic pages. The decision matrix below maps each profile to the methods most likely to surface usable query data. Skip the methods that don’t apply to your profile; running them anyway burns setup time for marginal recovery.

Two patterns are worth calling out. First: every profile starts with Method 1 (Search Console → GA4 link). It is free, fast, and the upper bound on visible organic query recovery. Skipping it is the single most common error on this topic.

Second: Method 2 (BigQuery) is the only method whose value is bounded by team skill, not by data availability. A team without SQL fluency gets less from BigQuery than a team with SQL fluency, even on identical traffic volume. Hire the skill or skip the method, because running it without skill produces a storage bill and a stalled project.

The methods compound. Running 1, 4, and 6 together gives most B2B teams a cleaner view of visible organic queries, paid keyword data, and manually tagged campaign terms. Adding Method 2 improves attribution by enabling cross-source joins. Adding Method 5 closes part of the remaining gap on single-topic pages. Whether the last layer of visibility is worth the setup cost is the question the matrix is built to answer.

Before you act on any recovered keyword or intent data, clean the source/medium layer underneath it. Misclassified source/medium pairs send clean campaign data into Unassigned rows in GA4 long before any (not provided) recovery method runs, and the misclassification flows downstream into every CRM attribution report.

Frequently asked questions