GSC BigQuery Export

TL;DR — The GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. BigQuery export (Google calls it the bulk data export) automatically copies your Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. data into a Google Cloud database called BigQuery, once a day, with no row limit. It’s how you get far more of your click and impression data than the trimmed-down view the Search Console UI shows — though anonymized (hidden) queries stay hidden here too. Two catches to know up front: it doesn’t pull in your old data (only data from the day you switch it on, going forward), and it needs a Google Cloud billing account even though there’s a free usage tier.

What it is

Search Console bulk data export can send daily performance data to BigQuery. Evidence for this claim Search Console bulk data export sends daily performance data to BigQuery in a configured Google Cloud project. Scope: Search Console bulk export; setup, permissions, quotas, and supported properties follow Google's current documentation. Confidence: high · Verified: 2026-07-14 Google: Bulk data export Google documents separate site-impression, URL-impression, and export-log tables, with schema and aggregation limits that matter during analysis. Evidence for this claim Bulk export uses site-impression, URL-impression, and export-log tables with documented schemas. Scope: Google's published Search Console export schema; aggregation and privacy handling still affect analysis. Confidence: high · Verified: 2026-07-14 Google: Bulk export tables

Open the Performance reportThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data. in Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. and try to export it. You’ll hit a wall fast: the UI caps most exports at around 1,000 rows, and it only shows you roughly the last 16 months of history. For a small site that’s fine. For a big site with tens of thousands of pages and a huge variety of search queries, you’re seeing a tiny slice of your real data.

The bulk data export fixes that. It’s a switch inside Search Console that says: “from now on, send my Performance data to BigQuery every day.” BigQuery is Google’s data warehouse — a place to store big tables and run queries on them. Once the export is running, you get unsampled daily data with no 1,000-row cap, kept for as long as you want — with one standing exception: anonymized queries (the ones Search Console hides for privacy) still show up as blank, same as in the UI. “No row limit” isn’t the same as “every query revealed.”

Why anyone bothers

You’d set this up if you want to:

• Analyze far more queries and pages than the UI or the export button will give you.
• Keep your Search Console history longer than 16 months (Search Console throws the old data away; BigQuery keeps whatever you keep).
• Join your Search Console data with other data — your Google Analytics data, a crawl, your product database — all in one place.

The two things to know before you start

1. It does not backfill. This is the single most common surprise. Turning the export on does not go grab your historical data. It starts collecting from that day forward. If you want history, you have to turn it on and then wait for it to accumulate.
2. It’s “free” with an asterisk. BigQuery has a free tier, and most small-to-mid sites stay inside it. But you still have to attach a Google Cloud billing account, and if you query the data carelessly — especially by pointing a live dashboard at the raw tables — you can run up a real bill.

Is it worth it for you?

Honestly, most sites don’t need this. If the Search Console UI and Looker Studio’s built-in Search Console connector show you enough, you’re done — skip the setup. You reach for the BigQuery export when you’re consistently hitting that 1,000-row wall, when you need more than 16 months of history, or when you want your Search Console data sitting next to your other data in a warehouse. If that’s you, switch to the Advanced tab for the full setup, the cost mechanics, and the first queries to run.

TL;DR — The bulk data export is a scheduled daily, unsampled dump of your Search Console PerformanceThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data. data into a BigQuery dataset — no ~1,000-row export cap, no ~16-month retention wall. It lands three tables (searchdata_site_impression, searchdata_url_impression, ExportLog). Setup: a Google Cloud project with billing enabled, the BigQuery + BigQuery Storage APIs on, two IAM roles granted to Google’s export service account, then Settings → Bulk data export in GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.. It does not backfill, still reports anonymized queries as empty strings, and the first export lands within ~48 hours. Cost is a real free tier plus per-TB query charges — the classic bill comes from dashboards querying raw tables live. Think of it as the third rung: UI → API → bulk export.

What it actually is

Bulk export is a scheduled Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. data pipeline into a Google Cloud project, not an independent ranking-data source. Evidence for this claim Search Console bulk data export sends daily performance data to BigQuery in a configured Google Cloud project. Scope: Search Console bulk export; setup, permissions, quotas, and supported properties follow Google's current documentation. Confidence: high · Verified: 2026-07-14 Google: Bulk data export Queries must respect the documented tables, keys, and privacy/aggregation behavior. Evidence for this claim Bulk export uses site-impression, URL-impression, and export-log tables with documented schemas. Scope: Google's published Search Console export schema; aggregation and privacy handling still affect analysis. Confidence: high · Verified: 2026-07-14 Google: Bulk export tables

Daniel Waisberg, a Search Advocate at Google, describes it plainly: “A bulk data export is a scheduled daily export of your Search Console performance data. It includes all the data used by Search Console to generate performance reports. Data is exported to Google BigQuery, where you can run SQL queries for advanced data analysis or even export it to another system.” (quoted in Search Engine Journal).

The point is scale. The Search Console UI caps most exports around 1,000 rows and shows a rolling ~16-month window. The Search Console APIA set of REST APIs that let you programmatically read and manage Google Search Console data for properties you've verified — Performance data, URL index status, sitemaps, and properties — authorized with OAuth 2.0. gives you more but is still capped and rate-limited. The bulk export removes the row ceiling entirely and lets you decide how long to retain. Google’s own line from the announcement, as reproduced by Search Engine Land: “The daily data row limit does not impact this data, so you can extract more data using this method,” and the feature “could be particularly helpful for large websites with tens of thousands of pages.”

What data you get: the three tables

Everything lands in a dataset whose name always starts with searchconsole. Three objects show up (Table guidelines and reference):

1. searchdata_site_impression — “Contains performance data for your property aggregated by property.” Key fields: data_date (“The day on which the data in this row was generated (Pacific Time)”), site_url (domain properties use the sc-domain: prefix), query, is_anonymized_query, country (ISO-3166-1 Alpha-3), search_type (web/image/video/news/discover/googleNews), device, impressions, clicks, and sum_top_position.
2. searchdata_url_impression — “Contains performance data for your property aggregated by URL.” Everything above, plus url (“The fully-qualified URL where the user eventually lands when they click the search result”), is_anonymized_discover, a family of is_[search_appearance_type] boolean flags (e.g. is_amp_top_stories, is_job_listing, is_tpf_faq) so you can slice by rich-result type, and sum_position. This is the granular table most analysis runs on.
3. ExportLog — “A record of what data was saved for that day. Failed exports are not recorded here.” Fields include agenda (currently only SEARCHDATA), namespace (which table was written), data_date, epoch_version (“An integer, where 0 is the first time data was saved to this table” — it increments when Google later revises a day’s data), and publish_time.

The anonymized-query caveat is the important one. Even here, at the raw level, anonymized queries are not revealed. As Google’s field description puts it, when is_anonymized_query is true the query field “will be a zero-length string.” Their metrics are still aggregated into your totals, but they’re never attributable to a specific term — exactly the same limitation the UI and the API have. This is a big deal at scale: in my Ahrefs study of GSC’s hidden terms, across 146,741 websites and roughly 9 billion clicks, 46.08% of all clicks went to queries Google doesn’t disclose — and that study used the Search Console APIA set of REST APIs that let you programmatically read and manage Google Search Console data for properties you've verified — Performance data, URL index status, sitemaps, and properties — authorized with OAuth 2.0., which “allows us to get all of the data—and there’s still a lot missing.” The BigQuery export doesn’t recover any of it. If someone tells you bulk export “finally shows you the hidden queries,” they’re wrong.

How to set it up

The flow (Start a new bulk data export):

1. Create or pick a Google Cloud project with billing enabled. Per Google: “Data is subject to Google Cloud storage and query costs, but there is a free usage level.” You need billing on even to stay inside the free tier.
2. Enable the BigQuery API and the BigQuery Storage API in that project.
3. Grant Google’s export service account access. Add search-console-data-export@system.gserviceaccount.com as a principal with two IAM roles: BigQuery Job User (bigquery.jobUser) and BigQuery Data Editor (bigquery.dataEditor).
4. In Search Console, go to Settings → Bulk data export. Paste the Cloud project ID (the ID, not the project number), choose a dataset name, and choose a dataset location. Note the naming rule: “The dataset name always starts with the string searchconsole, even when you customize it.” If you set a partition-expiration policy on the export’s own dataset, keep it at 14 days or longer — Google documents a 14-day minimum, and going shorter is a documented failure cause. Leave the generated table schema untouched too; altering it is the other documented way to break the export (more in Troubleshooting below).
5. Wait. Google says the export process itself should begin within about a day of activation. “The first export will happen up to 48 hours after your successful configuration in Search Console,” and that first delivery contains only the day-of-export data — nothing from before setup (see the no-backfill section next). After that it runs daily until you stop it.

One practical expectation to set: Search Console data lands with a two-day delay, so the most recent day you’ll ever have is two days ago. Ask for a 30-day range and you effectively get about 28 days of usable data.

The no-backfill gotcha

Say it out loud, because it burns people: activating the export does not pull in your historical data. It starts from activation day and only accumulates forward. This is common enough that Google’s own community forum has multiple threads about it — “How to backfill with historical data when Bulk data export is activated” (thread 300051568), thread 255704574, and thread 429248330. Antoine Eripret puts it bluntly in his practitioner deep-dive: “You can’t get historical data: if you activate it today, you’ll have data from today.” The takeaway is simple — turn it on the day you first hear about it, even if you’re not ready to analyze anything yet, so the clock starts.

What it costs, and how not to get surprised

The Google Cloud Blog post by Daniel Waisberg and Gaal Yahas sells the upside — “If you have a large website, this solution will provide more queries and pages than the other data exporting solutions” and “Search Console stores up to sixteen months of data; using BigQuery you can store as much data as it makes sense to your organization” — but the cost mechanics are on you.

As of this writing, BigQuery’s free tier is roughly 10 GiB of storage free plus 1 TiB (~1 TB) of on-demand query processing free per month; beyond that it’s about $6.25 per TiB processed and roughly $0.02 per GB stored per month (varies by region and storage class). Pricing changes, so verify the current numbers before you quote them to anyone. Most small-to-mid sites stay free or near-free.

The bills come from how you query, not how much traffic you have. Two things matter:

• Cost scales with query/keyword diversity, not raw traffic. As Trevor Fox puts it in his complete guide: “The volume of data that is more a factor of keyword variety than it is search volume. A site with a low search volume for lots of keywords will generate more data than a site with lots of search volume for a single keyword.”
• Don’t point a live dashboard at the raw tables. This is the classic horror story. Antoine Eripret documented Looker Studio scanning 23 TB in a single day, around €115, when wired directly to the raw billion-row tables. Google’s own BigQuery efficiency tips post says the same in principle: pre-aggregate into summary tables, filter on the date partition in a WHERE clause, avoid SELECT *, set budget alerts, and set partition-expiration to auto-delete old partitions.

The fix is boring but effective: materialize your query results into small permanent summary tables on a schedule, and point your dashboards at those, not at the raw export.

Querying: the rules that keep you sane (and cheap)

From Google’s query guidelines:

• Always aggregate. “Data in the tables is not guaranteed to be consolidated by date, URL, site, or any combination of keys.” Translation: you’ll get multiple rows for the same day/URL/query, so always SUM() your metrics and GROUP BY your dimensions. Never treat a single row as a finished number.
• Filter the date partition. “A good way to minimize query costs is to use a WHERE clause to limit the date range in the date partitioned table.”
• Drop anonymized rows when you want real top queries. “An anonymized query is reported as a zero-length string in the table” — so add WHERE query != ''.
• Position is zero-based. Both tables store position starting at 0, so average position is SUM(sum_top_position) / SUM(impressions) + 1 (add the 1).

Google ships sample queries for daily web-search stats, top mobile queries by country, Discover URLs by clicks, FAQ rich-result performance (is_tpf_faq = true), and brand-query tracking via REGEXP_CONTAINS. Start from those.

Managing and troubleshooting the export

From Manage and monitor bulk data exports:

• Stopping isn’t instant. Settings → Bulk data export → Deactivate export. “Bulk exports will stop in the next 24 hours,” so one more day of data may still land after you flip it off.
• Two failure thresholds, not one. “Search Console retains data from failed exports for about a week.” And then: “Search Console will stop trying to export data for a given date after about a week of failed attempts, and after about a month of failed export attempts, Search Console will stop the bulk export entirely.” So a sustained problem doesn’t just skip days — after ~a month it shuts the whole export off, and you’d have to set it up again.
• The schema-change trap (and the partition-expiration floor). If you alter the schema of an exported table, you break the export. Google also requires at least 14 days of partition expiration on the export dataset — set it shorter and the export can fail. Leave those tables alone; build your own derived tables instead. (Other common causes of failure include exceeding your Cloud project’s quota and revoking the service account’s access.)
• Use the Test report. There’s a “Test report” feature that lets you verify certain correctable issues — project ID/credentials, permissions — without waiting for the next scheduled run. Note it doesn’t force an immediate re-export; check back roughly 24 hours later to confirm the fix took.
• Search Console emails property owners when export errors start and when they resolve, and Settings shows the status of the most recent export attempt.

Where it sits: UI → API → bulk export

Think of three rungs on a ladder, each removing a limit the one below it hit:

• UI export — ~1,000 rows, ~16 months, no anonymized queries. Fine for most.
• Search Console API — more rows, still capped and rate-limited, still no anonymized queries. Good for ad-hoc and programmatic pulls.
• Bulk data export — no row cap, retention you control, daily granular data, built for warehousing and joins. Still no anonymized queries. Doesn’t backfill.

And a nuance older guides get wrong: you’re not limited to one property per Cloud project anymore. Google later allowed multiple properties into a single project using distinct searchconsole_-prefixed dataset names.

What about Bing?

As of this writing, there’s no native equivalent. Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. doesn’t offer a first-party BigQuery/bulk export — which is exactly why a market of third-party ETL connectors (Supermetrics, Improvado, Catchr, and others) exists to move Bing Webmaster Tools data into BigQuery. If Bing had a native pipe, that market wouldn’t. That said, a connector isn’t guaranteed to replicate GSC’s own export schema or daily-partition behavior field-for-field — check any connector’s documented scope before assuming parity. So if you want Bing data in BigQuery alongside your GSC export, budget for a connector and verify what it actually delivers. (Confirm this is still current before citing it — Bing’s own feature set can change.)

For the broader context on where this sits, see the Search Engine Tools hub and its walkthroughs of Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. and Bing Webmaster ToolsThe free, first-party consoles search engines give site owners — Google Search Console and Bing Webmaster Tools — to see how their pages are crawled, indexed, and ranked, and to fix problems. The legacy name is 'webmaster tools.'.

AI summary

A condensed take on the Advanced version:

• What it is: the bulk data export — a scheduled daily, unsampled dump of Search Console PerformanceThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data. data into a Google Cloud BigQuery dataset. It removes the UI’s ~1,000-row export cap and its ~16-month retention window.
• Three tables land in a searchconsole-prefixed dataset: searchdata_site_impression (property-level), searchdata_url_impression (URL-level, with is_* rich-result flags), and ExportLog (a daily export record).
• Setup: Google Cloud project with billing on → enable the BigQuery + BigQuery Storage APIs → grant search-console-data-export@system.gserviceaccount.com the BigQuery Job User and BigQuery Data Editor roles → Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. Settings → Bulk data export → project ID, dataset name, location (keep partition expiration at 14+ days) → the process starts within about a day, first export within ~48 hrs.
• No backfill. It starts from activation day forward — nothing historical is pulled in. This is the #1 point of confusion.
• Still no anonymized queries. They land as empty strings in query; metrics are aggregated but never attributable. In Patrick’s one-month Ahrefs study of 146,741 sites and nearly 9 billion clicks, ~46% of clicks went to undisclosed queries — bulk export doesn’t recover them.
• Cost: a real free tier (roughly 10 GiB storage + 1 TiB query/month) but it needs a billing account, and cost scales with query/keyword diversity, not traffic. The classic bill is a dashboard querying raw tables live (one documented case: 23 TB / ~€115 in a day). Fix: materialize summary tables, filter the date partition, avoid SELECT *.
• Querying: always SUM()/GROUP BY (rows aren’t pre-consolidated), filter query != '' to drop anonymized rows, and position is zero-based (add 1).
• Managing: deactivation takes up to 24 hrs; failed exports retry for ~a week per date, and ~a month of failures shuts the whole export off; altering an exported table’s schema or setting partition expiration under 14 days breaks it.
• Bing has no native equivalent as of this writing — third-party connectors fill the gap, though they don’t necessarily match the GSC export’s schema exactly.
• The ladder: UI → API → bulk export, each removing a limit.

Official documentation

Primary-source documentation, mostly from Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. Help and the Google Cloud Blog.

Google — the feature

• About bulk data export of Search Console data to BigQuery — the overview and what’s included/excluded.
• Start a new bulk data export — the setup flow: project, APIs, service-account roles, dataset settings, 48-hour delay.
• Table guidelines and reference — the full schema for searchdata_site_impression, searchdata_url_impression, and ExportLog.
• Query guidelines and sample queries — how to aggregate, minimize cost, filter anonymized rows, and ready-made sample queries.
• Manage and monitor bulk data exports — deactivation, error handling, retry/retention thresholds, and the Test report.

Google — announcement & framing

• Bulk data export: a new and powerful way to access your Search Console data (Search Central Blog, Feb 2023) — the original announcement.
• Analyze Google Search data with BigQuery (Google Cloud Blog, Daniel Waisberg & Gaal Yahas) — the advanced/ML framing.
• BigQuery efficiency tips for Search Console bulk data exports (Search Central Blog, June 2023) — cost and query-efficiency guidance.

Pricing

• BigQuery pricing — the current free tier and per-TB/per-GB rates (verify before quoting; these change).

Quotes from the source

On-the-record statements from Google. Where a page renders via JavaScript and resists automated verification, the quote is sourced through verbatim secondary coverage and flagged below.

Google — what it is

• “Schedule a daily export of your Search Console performanceThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data. data to BigQuery, where you can run complex queries over your data or export it to an external storage service.” — Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. Help. Jump to quote
• “A bulk data export is a scheduled daily export of your Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. performance data. It includes all the data used by Search Console to generate performance reportsThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data.. Data is exported to Google BigQuery, where you can run SQL queries for advanced data analysis or even export it to another system.” — Daniel Waisberg, Search Advocate, Google. Jump to quote

Google — the schema

• “Contains performance data for your property aggregated by property.” (on searchdata_site_impression) and “Contains performance data for your property aggregated by URL.” (on searchdata_url_impression). Jump to quote
• “The user query. When is_anonymized_query is true, this will be a zero-length string.” Jump to quote

Google — querying

• “Data in the tables is not guaranteed to be consolidated by date, URL, site, or any combination of keys.” Jump to quote
• “A good way to minimize query costs is to use a WHERE clause to limit the date range in the date partitioned table.” Jump to quote

Google — managing the export

• “Search Console retains data from failed exports for about a week.” and “Search Console will stop trying to export data for a given date after about a week of failed attempts, and after about a month of failed export attempts, Search Console will stop the bulk export entirely.” Jump to quote

Google Cloud Blog — Daniel Waisberg & Gaal Yahas

• “Store data as long as you want. Search Console stores up to sixteen months of data; using BigQuery you can store as much data as it makes sense to your organization.” Jump to quote

Bulk export vs. API vs. UI vs. the Looker Studio connector — which should I use?

Start from what limit you’re actually hitting, not from what sounds most powerful. Most people who set up the BigQuery export didn’t need to.

Q1. Are you hitting a real limit in the Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. UI? (The ~1,000-row export cap, or the ~16-month history wall, or you need to join GSC with other data.)

• No → stop. The UI (and Looker Studio’s native Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. connector for dashboards) is enough. Don’t take on a warehouse you don’t need.
• Yes → continue.

Q2. Do you need a standing, daily warehouse of full data — or just a bigger one-off / programmatic pull?

• One-off or programmatic pull (a script, an integration, an occasional deep export) → use the Search Console APIA set of REST APIs that let you programmatically read and manage Google Search Console data for properties you've verified — Performance data, URL index status, sitemaps, and properties — authorized with OAuth 2.0.. More than the UI, no BigQuery to run, but still capped/rate-limited and still no anonymized queries.
• Standing daily pipe you’ll warehouse and join with other data → continue.

Q3. Are you comfortable with a Google Cloud project, an active billing account, and writing SQL (or having someone who is)?

• No → reconsider. An unmanaged export plus a dashboard on raw tables is how the surprise bills happen. Either get help or stay on the API/Looker Studio connector.
• Yes → set up the bulk data export. Turn it on now (remember: no backfill), and plan to materialize summary tables rather than querying raw ones live.

Q4. Do you specifically need the anonymized/hidden queries broken out?

• Yes → none of these deliver that. Bulk export, API, and UI all suppress anonymized queries at the query level. Adjust the goal; the data doesn’t exist to be had from Google.

The one-line version: not hitting a limit → UI/Looker Studio; ad-hoc or coded pulls → API; standing warehouse at scale → bulk export; hidden queries → nobody can give you those.

Bulk data export setup checklist

Work top to bottom; each step gates the next.

• Turned the export on today even if you’re not ready to analyze yet (no backfill — the clock starts at activation).
• A Google Cloud project with billing enabled exists (billing is required even for the free tier).
• BigQuery API enabled in that project.
• BigQuery Storage API enabled in that project.
• search-console-data-export@system.gserviceaccount.com added as a principal with BigQuery Job User (bigquery.jobUser).
• Same service account granted BigQuery Data Editor (bigquery.dataEditor).
• In Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. → Settings → Bulk data export, pasted the Cloud project ID (the ID, not the number).
• Chose a dataset name (it will start with searchconsole) and a dataset location.
• If setting partition expiration on the export dataset, kept it at 14 days or longer — shorter breaks the export.
• Left the generated table schema unchanged (build derived tables instead).
• Waited up to 48 hours for the first export (the process itself should start within about a day), then confirmed data landed (check ExportLog and the two searchdata_* tables).
• Set a budget alert in Google Cloud so a runaway query can’t surprise you.
• Set partition-expiration on your derived tables if you don’t need unlimited retention.
• Built dashboards on materialized summary tables, not the raw export tables.

Mistakes and myths to avoid

“Turning it on backfills my old data.” No. The export starts from activation day and only accumulates forward — nothing prior is pulled in. It’s Google’s own community forum’s most-asked question about this feature. Turn it on the moment you hear about it so the history starts building.

“BigQuery export finally shows me the hidden/anonymized queries.” No. Anonymized queries land as empty strings in query; their clicks and impressions are folded into totals but never attributed to a term — same as the UI and API. In my Ahrefs study, ~46% of clicks went to queries Google won’t disclose, and even the API — which “allows us to get all of the data” — couldn’t surface them. Bulk export changes nothing here.

“It’s completely free.” Partly true. There’s a genuine free tier, but it requires an active billing account, and inefficient querying can bill you. “Free” only holds if you query efficiently.

“More traffic means a bigger BigQuery bill.” Not really — cost scales more with query/keyword diversity than raw click volume. A modest-traffic site with huge long-tail variety can generate more data than a high-traffic site with a handful of concentrated queries.

Pointing a live dashboard at the raw tables. The single most expensive mistake. One documented case saw Looker Studio scan 23 TB in a day (~€115) wired directly to raw billion-row tables. Fix: materialize summary tables on a schedule and point dashboards at those; filter the date partition in a WHERE clause; never SELECT *.

Editing the schema of an exported table, or setting a too-short partition expiration. Altering searchdata_site_impression, searchdata_url_impression, or ExportLog breaks the export. So does setting the export dataset’s partition expiration below Google’s 14-day minimum. Build your own derived tables instead, leave the originals untouched, and give any expiration policy on the raw dataset 14+ days of headroom.

“This replaces the Search Console APIA set of REST APIs that let you programmatically read and manage Google Search Console data for properties you've verified — Performance data, URL index status, sitemaps, and properties — authorized with OAuth 2.0..” Different tools for different jobs. The API is for ad-hoc and programmatic pulls; the bulk export is a standing daily pipe for warehousing and joins.

Assuming you can only export one property per project. Outdated. Google later allowed multiple properties in one Cloud project via distinct searchconsole_-prefixed dataset names.

A framework for designing the export before it designs your bill

1. Start with the question, not the warehouse. Use the UI for a quick answer, the Search Analytics APIA set of REST APIs that let you programmatically read and manage Google Search Console data for properties you've verified — Performance data, URL index status, sitemaps, and properties — authorized with OAuth 2.0. for bounded programmatic pulls, and bulk export only when you need a standing daily history, joins, or more rows than the other rungs provide.

2. Respect the table grain. searchdata_site_impression answers property-level questions; searchdata_url_impression adds the URL dimension. Rows are not promised to be pre-consolidated, so every analysis should deliberately choose dimensions and aggregate clicks, impressions, and position fields.

3. Make partition filters mandatory. Require a data_date range in every query. Cost follows bytes scanned, and an unbounded dashboard against raw tables can scan the same history repeatedly.

4. Separate raw, modeled, and presentation layers. Keep Google’s export tables unchanged, build scheduled summary tables for recurring questions, and point Looker Studio or another dashboard at those summaries. Schema edits to the export tables can break the delivery pipeline.

5. Operate the pipeline like production data. Monitor ExportLog, query bytes, scheduled-job failures, and freshness. The export has no backfill, so missing days are an operational incident, not something activation can repair later.

Common GSC bulk-export problems

The test report fails during setup

Symptom: Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. rejects the project or dataset before activation. Likely cause: billing or the required BigQuery APIs are not enabled, the project ID is wrong, or the Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. export service account lacks BigQuery Job User and BigQuery Data Editor. Fix: correct those prerequisites, rerun the Test report, and activate only after it succeeds.

No tables or new rows appear

Symptom: the dataset exists, but expected export data is absent. Likely cause: the first delivery is still pending, the dataset name/location is wrong, the export was deactivated, or failures are accumulating. Fix: allow the initial delivery window, then inspect ExportLog and Search Console’s bulk-export status. Correct the pipeline rather than recreating the dataset, because activation does not backfill earlier dates.

Query totals look duplicated or inflated

Symptom: clicks or impressions exceed the Search Console total for the same scope. Likely cause: raw export rows were treated as already consolidated, or site- and URL-grain data were mixed. Fix: choose one table grain, filter one search_type, group by the intended dimensions, and SUM() the metric fields before comparing totals.

Average position is off by one

Symptom: a computed position is consistently one lower than the UI expectation. Likely cause: the export’s position values are zero-based. Fix: aggregate the position numerator with the matching impressions, then convert to the familiar one-based display only at the presentation layer.

A dashboard suddenly becomes expensive

Symptom: bytes processed and query charges jump even though traffic did not. Likely cause: the dashboard is scanning raw URL-level tables without a partition filter. Fix: inspect bytes before running, add a bounded data_date predicate, materialize the needed daily summary, and point the dashboard at that smaller table.

Prove the bulk export works after setup or a pipeline change

Confirm Search Console can write to the project

Test to run — Run Settings → Bulk data export → Test report after changing the project, APIs, or IAM roles. Expected result — Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. reports that the destination is valid. Failure interpretation — the project/API configuration or the export service account’s roles are still wrong. Monitoring window — Immediate. Rollback trigger — Do not activate or switch the production export destination while the test fails.

Confirm a complete daily delivery

Test to run — Check ExportLog for the newest expected data_date, then query both impression tables for that same partition. Expected result — the log records the delivery and the site/URL tables contain rows for the date when the property had activity. Failure interpretation — the export is late or failed; an empty result is not historical backfill. Monitoring window — Allow the documented data lag and the initial export window before declaring failure. Rollback trigger — Pause any downstream report release if its newest date is missing or only one required table arrived.

Confirm a modeled query reconciles

Test to run — Run the new summary query for a fixed date and search type, then compare its total clicks and impressions with a direct aggregate of the same raw partition. Expected result — totals match at the same grain and filters. Failure interpretation — the model is dropping rows, double-counting dimensions, or mixing site and URL grain. Monitoring window — Immediate after the query finishes. Rollback trigger — Keep dashboards on the prior summary until the new model reconciles.

Confirm the cost guardrail

Test to run — Preview the bytes processed for the production query with its intended data_date filter. Expected result — the scan is bounded to the requested partitions and is consistent with the team’s established baseline for that report. Failure interpretation — partition pruning is missing or a join expanded the scan. Monitoring window — Before every scheduled-query or dashboard change. Rollback trigger — Do not deploy a version whose estimated scan materially exceeds the approved baseline without an explained data-volume change.

Starter queries

These follow Google’s own rules: aggregate everything (rows aren’t pre-consolidated), filter the date partition to control cost, and remember position is zero-based. Replace yourproject.searchconsole with your dataset.

Top real queries (anonymized rows removed), last 28 days

SELECT
  query,
  SUM(clicks)      AS clicks,
  SUM(impressions) AS impressions,
  SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS ctr,
  SUM(sum_top_position) / SUM(impressions) + 1 AS avg_position
FROM `yourproject.searchconsole.searchdata_site_impression`
WHERE data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
                    AND DATE_SUB(CURRENT_DATE(), INTERVAL 2 DAY)   -- 2-day data lag
  AND query != ''                                                 -- drop anonymized rows
GROUP BY query
ORDER BY clicks DESC
LIMIT 100;

Top landing pages by clicks (URL-level table)

SELECT
  url,
  SUM(clicks)      AS clicks,
  SUM(impressions) AS impressions
FROM `yourproject.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
                    AND DATE_SUB(CURRENT_DATE(), INTERVAL 2 DAY)
GROUP BY url
ORDER BY clicks DESC
LIMIT 100;

FAQ rich-result performance (a rich-result flag on the URL table)

SELECT
  url,
  SUM(clicks)      AS clicks,
  SUM(impressions) AS impressions
FROM `yourproject.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
                    AND DATE_SUB(CURRENT_DATE(), INTERVAL 2 DAY)
  AND is_tpf_faq = TRUE
GROUP BY url
ORDER BY impressions DESC;

Materialize a daily summary so dashboards never touch raw tables

CREATE OR REPLACE TABLE `yourproject.searchconsole_derived.daily_query_summary`
PARTITION BY data_date AS
SELECT
  data_date,
  query,
  SUM(clicks)      AS clicks,
  SUM(impressions) AS impressions
FROM `yourproject.searchconsole.searchdata_site_impression`
WHERE query != ''
GROUP BY data_date, query;

A cost-control habit: verify how many bytes a query will scan before you run it, using the dry-run flag in the bq CLI — a free way to catch an accidental full-table scan.

bq query --use_legacy_sql=false --dry_run \
  'SELECT SUM(clicks) FROM `yourproject.searchconsole.searchdata_url_impression`
   WHERE data_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY)'
# Prints the estimated bytes to be processed without running (or billing for) the query.

GSC BigQuery export — cheat sheet

Setup at a glance

The three tables

Query rules

• Always SUM() + GROUP BY — rows aren’t pre-consolidated.
• WHERE query != '' to drop anonymized rows.
• Filter data_date (the partition) to cut cost.
• avg_position = SUM(sum_top_position)/SUM(impressions) + 1 (zero-based, add 1).
• Never SELECT *.

Fast facts

• No backfill — data starts at activation, forward only.
• Anonymized queries stay hidden (empty query string) — same as UI/API.
• Two-day lag on the most recent data.
• Deactivation takes up to 24 hours (one more day may land).
• Failure thresholds: ~1 week retry per date → ~1 month of failures stops the entire export.
• Partition expiration floor: 14 days minimum on the export dataset; shorter breaks it.
• Dataset name always starts with searchconsole.
• Multiple properties per project: use distinct searchconsole_-prefixed dataset names.
• Free tier (verify current): ~10 GiB storage + ~1 TiB query/month, then ~$6.25/TiB.
• Bing: no native equivalent — third-party connector required.

Prompts for reviewing GSC BigQuery work

Audit a query for correctness and cost

Paste the table schemas, the SQL, its purpose, and the date/search-type scope. Ask the model to return corrected SQL and a short explanation, then verify the output in BigQuery before scheduling it.

You are reviewing a Google Search Console bulk-export query in BigQuery.

Goal: [the question this query should answer]
Table grain and schemas: [paste the relevant site or URL table fields]
SQL: [paste the query]
Required date range and search_type: [paste them]

Check for: a missing data_date partition filter; failure to aggregate raw rows;
site-grain and URL-grain mixing; incorrect handling of zero-based position;
anonymized-query handling; joins that duplicate metrics; and unnecessary bytes
scanned. Return: (1) each issue, (2) corrected Standard SQL, (3) a reconciliation
query, and (4) assumptions that require human verification. Do not invent fields.

Design a safe reporting layer

Paste the questions the dashboard must answer and the real schema. Expect a proposed summary-table grain and validation plan, not a fabricated ready-to-run deployment.

Design a modeled reporting layer for this GSC BigQuery bulk export.

Business questions: [paste the questions]
Available tables and schemas: [paste them]
Refresh cadence: [daily/weekly]
Required dimensions: [page, query, country, device, search type, etc.]

Propose: the smallest useful summary-table grain; partitioning and clustering;
a scheduled-query sequence; freshness and reconciliation checks; and which dashboard
questions should stay in the UI or API instead. Preserve raw export tables unchanged.
Flag any requirement the supplied schema cannot support, especially requests for
disclosed anonymized queries. Do not invent benchmarks, fields, or backfill.

Tools around the export

• Google BigQuery — where the data lands; run SQL, schedule queries, and build BigQuery ML models on it.
• BigQuery cost controls — Google Cloud budget alerts, per-query byte limits, and the bq --dry_run flag to estimate scan size before running.
• Looker Studio — for dashboards, but build them on materialized summary tables, not the raw export. (Looker Studio also has a native Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. connector that needs no BigQuery at all — often enough on its own.)
• Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — the source; the UI export and the Performance reportThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data. are the baseline the bulk export extends.
• Search Console APIA set of REST APIs that let you programmatically read and manage Google Search Console data for properties you've verified — Performance data, URL index status, sitemaps, and properties — authorized with OAuth 2.0. — the middle rung when you need more than the UI but not a standing warehouse.
• Third-party ETL connectors (Supermetrics, Improvado, Catchr, and others) — how you’d get Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. data into BigQuery, since Bing has no native export.

Resources worth your time

My related writing

• Almost Half of GSC Clicks Go to Anonymous Queries — my Ahrefs study (146,741 sites, ~9B clicks) showing 46.08% of clicks go to queries Google won’t disclose. Directly relevant: the BigQuery export doesn’t recover any of them either.
• The Beginner’s Guide to Technical SEO — where Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. and data-analysis work fit in the bigger picture.

My speaking / posts

• On getting more out of GSC data — a walkthrough of squeezing more from Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.’s data (via Ahrefs’ own GSC features), part of the same “there’s more here than the UI shows” throughline as the BigQuery export.

From around the industry

• Google Search Console adds daily bulk data exports to BigQuery (Search Engine Land, Barry Schwartz) — the announcement coverage, with Google’s original wording quoted verbatim.
• Google Explains How To Use Search Console Bulk Data Export (Search Engine Journal, Matt G. Southern) — Daniel Waisberg’s plain-English description of the feature.
• Get Started With GSC Queries In BigQuery (Search Engine Journal) — a practical query starter.
• Google Search Console to BigQuery: The Complete Guide (Trevor Fox) — the origin of the “keyword variety, not search volume” cost framing.
• See Ya, Sampling! Get More Complete GSC Data With BigQuery (Advanced Web Ranking, Sam Torres) — setup and cost-control basics.
• How to Query Google Search Console Data in BigQuery (Analytics Mania, Julius Fedorovicius) — thorough walkthrough including the two-day data lag.
• How to use your GSC data in BigQuery like a pro (Antoine Eripret) — the technical deep-dive, including the 23 TB / ~€115 cost horror story and the no-backfill reality.

Stats worth citing

• ~46% of GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. clicks go to undisclosed queries. From my Ahrefs study of 146,741 websites and roughly 9 billion clicks: 46.08% of clicks went to queries Google anonymizes — a limitation the BigQuery export shares with the UI and API.
• A live dashboard on raw tables scanned 23 TB in one day (~€115). Antoine Eripret’s documented case for why you materialize summary tables instead of querying the raw export directly. Source
• Two-day data lag. “Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. data is available with a two-day delay, so the most recent data available will always be from two days prior” — so a 30-day range returns ~28 days of usable data. Source
• Free tier (verify — pricing changes): roughly 10 GiB storage + 1 TiB of query processing per month free, then about $6.25/TiB processed. Source

Test yourself: GSC BigQuery Export

Five quick questions on the bulk data export. Pick an answer for each, then check.

GSC BigQuery Export

GSC BigQuery export (bulk data export) is a Google Search Console feature that schedules a daily, unsampled export of a property's Performance data into a Google Cloud BigQuery project — bypassing the UI's ~1,000-row export cap and its rolling ~16-month retention window. It doesn't backfill and still excludes anonymized queries at the query level.

Related: Search Engine Tools, Google Search Console, Bing Webmaster Tools

GSC BigQuery Export

The bulk data export — commonly called the “GSCA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. BigQuery export” — is a Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. setting that pipes your property’s Performance data into a Google Cloud BigQuery dataset every day, unsampled. Google’s own framing: “Schedule a daily export of your Search Console performanceThe Google Search Console report that shows how your site actually performed in Google Search, built from real impressions and clicks. It reports four metrics — clicks, impressions, average CTR, and average position — and keeps the most recent 16 months of data. data to BigQuery, where you can run complex queries over your data or export it to an external storage service.”

It exists to get past the two hard ceilings of the Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. UI: the roughly 1,000-row cap on any single export, and the rolling ~16 months of history the reports show. Once the export is running, BigQuery holds as much data as you want to keep, at daily granularity, with no per-report row limit.

Three things trip people up:

• It doesn’t backfill. The export starts from the day you turn it on and only accumulates forward — nothing before that date is pulled in.
• It still hides anonymized queries. They land as zero-length (empty) strings in the query field; their clicks and impressions are folded into the totals but never attributed to a specific term — the same limitation the UI and the Search Console APIA set of REST APIs that let you programmatically read and manage Google Search Console data for properties you've verified — Performance data, URL index status, sitemaps, and properties — authorized with OAuth 2.0. have.
• “Free” has an asterisk. There’s a genuine BigQuery free tier, but it requires an active Google Cloud billing account, and inefficient querying (especially dashboards hitting the raw billion-row tables live) can run up real charges.

It lands three objects in a searchconsole-prefixed dataset: searchdata_site_impression (property-level), searchdata_url_impression (URL-level, with rich-result flags), and ExportLog (a daily record of what was saved). Bing has no native equivalent — you’d need a third-party connector to move Bing Webmaster ToolsMicrosoft's free portal for monitoring and improving how a site appears in Bing search — the peer to Google Search Console, plus IndexNow instant indexing, richer backlink data, and keyword volumes. Because Bing's index also feeds Microsoft Copilot, it doubles as a window into AI-search visibility. data into BigQuery.

Related: Search Engine Tools, Google Search Console, Bing Webmaster Tools

Changelog