Search Console BigQuery Export: 2026 Guide

Administrator in Search Engine Optimization Sep 25 / 3 weeks ago

Imagine a US online store with 40,000 product pages. Its SEO lead opens the Performance report in Google Search Console, and the long tail runs out long before the catalog does. The Search Analytics API goes further, but Google's API guide says it "exposes a maximum of 50K rows of data per day per search type."

Google built the bulk data export for this problem. It sends a daily copy of your performance data to BigQuery with no row cap. It also brings a Google Cloud bill, a SQL learning curve, and one trap that can cost you months of history. New to the reports? Start with our practitioner guide to Search Console reports, indexing, and URL Inspection.

What does the Search Console BigQuery export do?

The bulk data export sends your Search Console performance data to Google BigQuery once a day. It covers clicks, impressions, and position by query, page, country, device, and search type. Google says it includes all your performance data except anonymized queries, and it is not affected by the daily data row limit.

Google announced it in a February 21, 2023 post on the Search Central Blog, written by Daniel Waisberg, Gaal Yahas, and Haim Daniel of the Search Console team. The post says the data "includes all your performance data, apart from anonymized queries, which are filtered out for privacy reasons." In the tables, those rows still arrive with a blank query, so they count in your totals. Think of the reports as the menu and the export as the kitchen.

Who actually needs the bulk data export?

You need it if your site has tens of thousands of pages or gets traffic from tens of thousands of queries a day, which are Google's own thresholds. Smaller sites can already see their data through the reports, the Looker Studio connector, and the Search Analytics API. For them, the export mostly adds cost and complexity.

The 2023 announcement says the export "could be particularly helpful for large websites with tens of thousands of pages, or those receiving traffic from tens of thousands of queries a day." I think that bar is right, and if you keep hitting the row cap, or need to join search data with sales data, set it up. In my view, a 500 page B2B site rarely needs it.

How does the export compare with the reports and the API?

The reports are free and need no skill, but they limit rows. The Search Analytics API goes deeper, up to 50,000 rows per day per search type, and it can reach older data. The export removes the row cap and lets you use SQL, but it holds no data from before you set it up.

I compiled this table from the 2023 announcement, Google's API guide, and the Help Center setup page.

How do you set up the bulk data export step by step?

Enable the BigQuery API in your Cloud project, grant Google's export service account two roles, then open Search Console settings and enter your project ID, dataset name, and location. Search Console runs a test export first, and if it passes, all owners get an email and the daily exports start within 48 hours.

Only property owners can set up a bulk data export, and you need a Google Cloud project with billing. These steps follow Google's Help Center guide to starting a new export.

In Google Cloud Console

1. Open Google Cloud Console and switch to the project that will hold the data.
2. In APIs and Services, enable the BigQuery API and the BigQuery Storage API if they are off.
3. In IAM and Admin, click Grant Access.
4. Under New principals, paste search-console-data-export@system.gserviceaccount.com.
5. Give it two roles, BigQuery Job User and BigQuery Data Editor, then click Save.

In Search Console

1. Open Settings, then Bulk data export, for your property.
2. Paste the project ID, not the project number.
3. Pick a dataset name. It always starts with searchconsole, and each property that shares a project needs its own name.
4. Choose the dataset location with care, because you can't easily change it later.
5. Click Continue. After a test export, the first real export lands up to 48 hours later.

My advice is to book one short call with the SEO lead and the Cloud admin, and finish it live. Our guide to getting SEO tickets through engineering and approval chains helps in larger companies.

Which setup mistakes break the export?

Three mistakes can stop your data. One is pasting the project number instead of the project ID. Another is granting only one of the two BigQuery roles. The third is changing the table schema, such as adding a column, which makes the export fail. An access problem should surface soon after setup, but a schema change comes later.

The schema rule bites later, when someone adds a page type column. My advice is to check the ExportLog table weekly. Google's table reference says each day typically has two rows, one per data table, so a missing row deserves a look that same day.

What is inside the two data tables?

The export creates searchdata_site_impression, which aggregates data by property, and searchdata_url_impression, which aggregates by URL. Both hold date, query, country, search type, device, clicks, impressions, and a position sum. The URL table adds the landing URL and true or false flags for search appearances such as rich results. A third table, ExportLog, records each successful export.

• data_date is the day of the data, in Pacific Time, not your local time.
• country is a three letter ISO 3166 code, such as usa, deu, fra, gbr, or kor.
• search_type is web, image, video, news, discover, or googleNews. That last value covers news.google.com and the Google News app, which helps if you track Google News and Top Stories visibility.
• query is an empty string when is_anonymized_query is true.
• Position fields are zero based. Average position is the position sum divided by impressions, plus one.

Rows also repeat, so Google's table reference is blunt: "you should almost always aggregate all your metrics." Wrap every metric in SUM.

The two tables also count differently. The property table counts one impression per result for your site, while the URL table counts each URL that appeared. For example, if a French recipe publisher has two pages on one results page, the property table logs one impression and the URL table logs two. Use the URL table for finding pages that compete for the same query or deciding which decaying posts to refresh, merge, or prune.

Publishers should also know that Discover rows under a privacy threshold lose fields like URL and country. That matters if you chase traffic from the Google Discover feed.

Which queries should you run first?

Start with three. A daily web total from the property table, to check the data looks sane. A top query list for your key countries, with anonymized rows removed. And a week over week click change by URL. Filter every query by data_date, because the tables are partitioned by date and that keeps costs down.

Query 1: daily web totals

SELECT
  data_date,
  SUM(clicks) AS clicks,
  SUM(impressions) AS impressions,
  SUM(sum_top_position) / SUM(impressions) + 1 AS avg_position
FROM searchconsole.searchdata_site_impression
WHERE search_type = 'WEB'
  AND data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 28 DAY) AND CURRENT_DATE()
GROUP BY data_date
ORDER BY data_date DESC

This is adapted from Google's own sample. The plus one fixes the zero based position, and 'WEB' in capitals follows Google's samples. Swap in your own dataset name if it is not plain searchconsole, and look for the three tables inside that dataset, under your project, in BigQuery.

Query 2: top queries in the US, Europe, and Korea

SELECT
  query,
  country,
  SUM(clicks) AS clicks,
  SUM(impressions) AS impressions
FROM searchconsole.searchdata_site_impression
WHERE search_type = 'WEB'
  AND query != ''
  AND country IN ('usa', 'deu', 'fra', 'gbr', 'kor')
  AND data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY) AND CURRENT_DATE()
GROUP BY query, country
ORDER BY clicks DESC LIMIT 100

The list covers the United States, Germany, France, the United Kingdom, and South Korea. The empty string filter drops anonymized rows. Our guide to why rank trackers disagree on position explains why these numbers rarely match a tracker.

If you track EEA countries, our breakdown of how the 2026 DMA changes cut some EU search traffic shows why that split matters now. If kor shows real volume, our guide to ranking in Naver search covers the other big engine in Korea.

Query 3: pages losing clicks week over week

WITH weekly AS (
  SELECT url,
    SUM(IF(data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 8 DAY) AND DATE_SUB(CURRENT_DATE(), INTERVAL 2 DAY), clicks, 0)) AS this_week,
    SUM(IF(data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 15 DAY) AND DATE_SUB(CURRENT_DATE(), INTERVAL 9 DAY), clicks, 0)) AS last_week
  FROM searchconsole.searchdata_url_impression
  WHERE search_type = 'WEB'
    AND data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 15 DAY) AND DATE_SUB(CURRENT_DATE(), INTERVAL 2 DAY)
  GROUP BY url
)
SELECT url, this_week, last_week, this_week - last_week AS click_change
FROM weekly
ORDER BY click_change LIMIT 50

This compares the last seven days with the seven before, per URL, lists the biggest losers first, and skips the two newest days as a margin, since the newest days may not be exported yet. The ExportLog table shows which dates have landed. Before you act, our decision tree for diagnosing an organic traffic drop helps you rule out seasonality and tracking faults.

Where should European teams store the data?

Pick the location when you set up the export, because Google says you cannot easily change it later. For most European teams, the sensible choice is the EU multi-region or a single EU region such as Frankfurt or Paris. UK teams should know that London is a separate region, and data in the EU multi-region is not stored there.

BigQuery's locations page describes the EU multi-region as "Data centers within member states of the European Union." US teams can pick the US multi-region, and a team in Seoul could pick asia-northeast3 if the Search Console list offers it. My rule: store the export where your other analytics data already lives, because joins across locations get awkward.

For example, imagine a German publisher that keeps GA4 data in the EU multi-region. Putting the export there too is often the simpler answer, though that is a practical choice, not a legal rule. A UK agency whose clients use London (europe-west2) should probably match that region. Our guide to first-party data and SEO measurement under consent rules covers the GA4 side.

How much does the bulk data export cost?

BigQuery gives you the first 10 GiB of storage and the first 1 TiB of query data free each month. After that, the pricing page lists on-demand queries at $6.25 per TiB. Prices vary by region. For many sites, I expect the bill to be small or zero, as long as every query filters by date.

These figures come from the BigQuery pricing page, read on September 25, 2026. For example, that page prices 100 GiB of active logical storage for half a month in us-central1 at $1.15. In my view, queries are the bigger risk, because a query with no date filter scans every partition, every time.

The setup page warns that "Data will be accumulated forever for your project, unless you set an expiration time for your data." Set a partition expiration of 14 days or longer, as the Help Center advises. I would keep at least 16 months, or more if you plan to forecast SEO traffic from your own Search Console history.

Can you get data from before the export started?

No. The bulk data export has no backfill, so it only holds data from the day it begins. For older data, Google's setup guide says to use the Search Console API or the reports. The reports keep 16 months, so every week you wait is a week of history you must pull another way, or lose.

My advice is to set it up today, even if nobody queries it for months. For older days, use the Search Analytics API, one day per request, as Google's API guide suggests. Store those rows in a separate table, because the API caps rows and can drop data when you group by page or query.

A long, clean history also makes SEO split tests with matched control pages far easier to read.

Will the export fix anonymized queries?

No, and I think this is the biggest false hope. Anonymized queries stay hidden. Their rows arrive with an empty query string, so they still count in your totals, but you never see the words. Google's query guide says they often make up the single most common query for a site. BigQuery gives you more rows, not more privacy exceptions.

For most small sites, I think the export adds a billing account and a SQL skill requirement without adding new insight. Who should wait? A local business, a 200 page blog, or a brand new site, since they gain more from better pages than from better plumbing. Who should not wait? Any site near Google's thresholds, and any team that must join search data with revenue.

If your real question is AI visibility, read our guide to the Search Console generative AI report before you reach for SQL.

What should you do this week?

If your site sits near Google's thresholds, set up the bulk data export this week, even before you write a single query. History only starts on setup day. Then check the ExportLog table, run the daily totals query, and set a partition expiration that keeps at least 16 months. Smaller sites can skip it without guilt.

Back to that US store with 40,000 product pages. Its SEO lead needs one call with IT, two roles, and one project ID. My forecast is that more teams will treat the export as standard plumbing, because the free tier covers so much. Once data flows, report it with the SEO KPIs that prove ROI to executives, and pair it with server log analysis for crawl budget. What would you ask your own export first?

Frequently asked questions: what else do teams ask about the bulk data export?

The questions below fill the gaps the sections above leave open. Each answer sticks to what Google documents, so you can paste it straight into a ticket or a note to your IT team. Where a question touches setup or cost, the fuller sections above hold all the detail and source links.

Is the Search Console BigQuery export free?

The feature itself costs nothing in Search Console, but the data lands in BigQuery, which Google Cloud bills. The setup page says there is a free usage level and that usage above it is charged. According to the BigQuery pricing page, read on September 25, 2026, the first 10 GiB of storage and the first 1 TiB of queries each month are free. Large sites with years of stored history should set a budget alert in Google Cloud and filter every query by date.

How long until data shows up in BigQuery?

Google's 2023 announcement says the ongoing exports start within 48 hours of a successful setup. The Help Center adds that the first export happens up to 48 hours after configuration and includes data for the day of the export. Before that, Search Console runs a simulated export. If it fails, you get an alert right away, and if it passes, every property owner gets an email. So plan for a two day wait, and check the ExportLog table before you tell anyone the pipeline works.

Can I export several properties into one Google Cloud project?

Yes. The Help Center says you can export multiple properties to one project, but each property needs its own dataset name. Every dataset name starts with the string searchconsole, so a pattern like searchconsole_shop and searchconsole_blog fits that rule. For example, a UK agency could keep one project per client and one dataset per property inside it. Remember that each dataset gets its own location, which is hard to change later, so decide your location rule before you add the second property.

Why does my average position differ from the Performance report?

The first thing to check is a missing plus one. Position fields in the export are zero based, so Google's table reference says to divide the position sum by impressions and then add one. The second thing is the table choice, because the property table uses your site's top position per result, while the URL table tracks each URL. The third is dates, since the export's data_date uses Pacific Time. Fix all three, and your numbers should sit much closer to the report you know.

What does epoch_version mean in the ExportLog table?

It tracks rewrites. An epoch_version of 0 means Search Console saved that date for the first time. In rare cases, Google fixes a processing error and rewrites a past day, with each rewrite raising the number by one. Google's table reference says these fixes are atomic, so the whole day changes in one commit. They do not trigger an email, but they do show in the log. If a report you sent last month no longer matches, check this field before you blame your SQL.

What happens if the export breaks for a few days?

It depends on the error. For short connection problems, Search Console keeps retrying without any alert. For a lasting error, such as a removed permission, it waits for the next scheduled run and retries the missed day for about a week, and after that the day is gone. Google's own example shows an error on day 1 fixed on day 9, which loses days 1 and 2 for good. The ExportLog table only records successful exports, so a missing date there is your warning sign.

Can I add my own columns to the export tables?

No. The Help Center warns against changing the table schema, such as adding a column, because schema changes make the export fail. If you want extra fields, such as page type, product margin, or author, keep them in a separate table and join them in your queries or in a view. The same care applies to expiration. Put it on partitions, not on the whole table, because Google's table reference says a table expiration will delete all your data. Treat the export tables as read only.

Do European sites have to store the data in the EU?

Search Console lets you choose the location, and I cannot give legal advice. What I can say is practical. If your company already keeps analytics data in the EU, placing the export in the EU multi-region or a single EU region like Frankfurt is often the simpler answer, because it keeps your data map tidy and your joins easy. UK teams should note that BigQuery's EU multi-region does not store data in London. Check with your data protection officer before you pick, because the location is hard to change later.

Does the export replace the Search Analytics API?

Not fully. The export is better for fuller daily data, because it is not affected by the daily data row limit. The API still has two jobs. Google's setup guide names it, with the reports, as the way to reach days before your setup, and it also suits small scripts that need a quick daily pull. Google's API guide caps it at 50,000 rows per day per search type and warns that grouping by page or query can drop some data. I expect many teams to run both.

How do I filter the export by country?

Use the three letter ISO 3166 country code in lowercase, as Google's sample query does with usa. Germany is deu, France is fra, the United Kingdom is gbr, and South Korea is kor. A filter like country IN ('usa', 'kor') keeps just those markets. Country means where the search was made, not where your server sits. Also remember that some Discover rows lack a country because of privacy thresholds, so country totals can fall short of the site total. Always sum clicks and impressions after you filter.