Google Search Console BigQuery export: what it actually costs

Search Console’s Performance report throws away anything older than 16 months, and the bulk data export is Google’s official fix: a daily dump of every raw, unaggregated row into a BigQuery project you control. It genuinely solves the retention problem. What it does not do is stay free once your tables grow past a modest size — the moment you turn it on, you’re running your own small BigQuery storage-and-query bill instead of paying a vendor for the same job. If the 16-month wall isn’t actually what’s blocking you yet, the Search Console API usually hits its own row ceiling first, and if it’s audit signals you’re after rather than raw export rows, the Search Console SEO audit is the more direct read.

This page prices the do-it-yourself route honestly, with dated numbers pulled straight from Google’s own pricing page: what BigQuery actually charges for storage and for the queries you run against it, four queries that work against the real exported table schema, and the point where paying for a dashboard that already does this stops being the worse deal.

What the bulk export actually gives you

A bulk data export is a Search Console setting, configured per property, that writes a daily snapshot of your performance data into BigQuery. Once it’s running, Google creates a dataset (named searchconsole by default) in a Cloud project you own, containing two data tables and one log table: searchdata_site_impression (your data aggregated by property — query, country, search type, device) and searchdata_url_impression (the same data aggregated by URL, with rich-result flags added), plus ExportLog, a record of what got saved each day.

The practical difference from the UI or the Search Console API is that nothing here is capped. The Performance report’s own table shows 1,000 rows at a time; the API returns up to 25,000 rows per request. The bulk export has no per-request limit at all, because you’re not requesting anything — Search Console just writes every row it has, once a day, into tables you query directly. Google’s own table reference documents both tables field by field, and it’s worth reading once before you write your first query rather than guessing at column names. Even rare queries survive in a form the UI simply drops: the site-level table flags them with is_anonymized_query, blanking the query text itself to protect privacy while keeping the impression and click counts intact, so your totals still add up even where individual search terms don’t.

A third table, ExportLog, is easy to overlook and worth knowing about upfront: it records which table was saved on which day, plus an epoch_version counter that increments on the rare occasion Google has to correct previously saved data. Failed export attempts never show up there — only successful ones do — which is exactly what makes it useful as a completeness check, covered again in the practical tips below.

Here is the sentence worth reading twice before you set this up: the export only starts accumulating data from the day you turn it on. It does not backfill. If you’ve already lost performance history past Search Console’s 16-month window, this feature does not get it back — Google’s own setup guide says as much, pointing you back to the Search Console API or the canned reports for anything that precedes your configuration date, neither of which reaches further back than 16 months either. The bulk export is a way to stop losing data from today forward, not a way to recover what’s already gone.

One more default worth knowing before setup: exported tables are retained forever unless you tell BigQuery otherwise. That’s a storage decision with a real cost attached, which the buying guide below covers in the numbers you actually need.

Setting it up

Configuring the export happens in two places, and you need access to both.

In the Google Cloud console, you create or select a project with billing enabled — required to turn on the BigQuery API at all, even if you never cross a single free-tier threshold — then enable the BigQuery API and BigQuery Storage API. From there, grant Search Console’s own service account, search-console-data-export@system.gserviceaccount.com, two IAM roles on that project: BigQuery Job User and BigQuery Data Editor. Without both roles, the export can’t run.

Back in Search Console, under Settings, the bulk data export screen asks for your Cloud project ID (not the project number — a common first mistake), a dataset name that must start with searchconsole, and a storage location you cannot change later once exports have begun. Only property owners can configure this, not every verified user.

Google simulates the export before committing to anything: a configuration problem surfaces immediately, and a successful simulation triggers an email to every property owner. The real, ongoing daily export begins within 48 hours and only ever covers data starting from the day of that first export — not before. After that, exports land once a day, not in real time. A transient error retries silently; a persistent one, such as a broken permissions grant, keeps retrying for about a week before Search Console gives up on that day’s data entirely, which means a quietly broken IAM role can cost you real history without ever sending an alert. One more setup detail worth flagging early: changing the table schema later, even by adding a column, breaks the export outright.

Buying guide: what the do-it-yourself route actually costs

Google’s own bulk-export setup guide is upfront that this data is “subject to Google Cloud storage and query costs, but there is a free usage level” — vague enough to be technically true and useless for planning a budget. The four numbers below, checked against BigQuery’s pricing page on August 12, 2026, in the US region Search Console typically defaults to, are the ones that actually matter. Google announced the bulk export as a feature aimed squarely at sites too large for the UI or the API to comfortably serve, which is worth keeping in mind if your own site is nowhere near that scale — the free tiers below may simply be the entire bill you ever see.

Storage

The first 10 GiB of data is free every month, for both storage tiers. Past that, active logical storage — any table or partition modified in the last 90 days — runs about $0.023 per GiB per month (roughly $23.55 per tebibyte per month). Because the export writes new rows daily, the table as a whole never technically stops being “modified.” But these tables are date-partitioned by data_date, and BigQuery prices each day’s partition separately: the moment a given day’s partition goes 90 days without being touched again, that slice alone drops to the long-term rate, about $0.016 per GiB per month. In practice, that means almost your entire accumulated history — everything except roughly the last quarter — bills at the cheaper rate automatically, with nothing for you to configure.

Queries

BigQuery’s on-demand pricing charges for bytes scanned, not for query runtime or rows returned. The first 1 tebibyte scanned each month is free per Cloud billing account; beyond that, it’s $6.25 per tebibyte in the same US region. What you select matters more than how complex the query looks: a SELECT * across two years of history scans, and bills, far more than pulling only the four or five columns a dashboard actually needs. Filtering on data_date — the partitioned column — lets BigQuery skip entire days it doesn’t need to open, which is the single cheapest thing you can do to any query against these tables. The BigQuery console shows an estimated bytes-processed figure before you run anything; check it before you run the query, not after.

A worked example

Google frames this feature as built for large sites — “tens of thousands of pages, or those receiving traffic from tens of thousands of queries a day” — with smaller sites already well served by the free UI, API, and Looker Studio connector. At that scale, a full year of unaggregated daily rows across both tables commonly lands somewhere in the low tens of gigabytes. Take 30 GiB as a round, illustrative number for that kind of site: the first 10 GiB is free, leaving 20 GiB billed at the active rate, about $0.46 a month, dropping further as older partitions age into the long-term tier. A dashboard job that refreshes once a day, re-scanning the full 30 GiB, uses about 0.03 tebibyte per run — run daily for a month, that’s roughly 0.9 tebibyte total, still inside the free 1 tebibyte monthly query allowance. The realistic total for a site at exactly the scale Google says this feature is for: under a dollar a month, before you’ve even trimmed a single column to cut the scanned bytes further.

Your own numbers will differ, so check them rather than trusting anyone’s example — including this one. The last of the four queries below reads your actual table sizes straight out of BigQuery and estimates a monthly storage cost from them, so you can price your own data before committing to anything.

Hidden costs to plan for

The Cloud bill is rarely the real cost here. BigQuery gives you SQL and two raw tables, not a chart — building anything a client or manager can read means building a dashboard on top yourself, whether that’s a Looker Studio view or something custom. A schema change, even adding one column, breaks the export and forces a reconfiguration. Left on its defaults, storage accumulates forever with no automatic cleanup, and setting a table-level expiration instead of a partition-level one deletes everything, not just the old rows. And the IAM grant behind all of this is a permission nobody at a small agency or solo operation is necessarily watching — when it silently breaks, Search Console keeps retrying for about a week and then simply stops, with no alert beyond that.

Queries worth having

These four work against the real table schema Search Console exports — adjust your-project to your own Cloud project ID before running any of them, and check the estimated bytes-processed figure BigQuery shows first.

Property-wide trend, well past the 16-month wall the Performance report enforces:

SELECT
  data_date,
  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 `your-project.searchconsole.searchdata_site_impression`
WHERE data_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 24 MONTH)
GROUP BY data_date
ORDER BY data_date DESC
LIMIT 800

Top queries by clicks over the last 90 days, excluding the anonymized rows that would otherwise show up as blank:

SELECT
  query,
  SUM(clicks) AS clicks,
  SUM(impressions) AS impressions,
  (SUM(sum_top_position) / SUM(impressions)) + 1 AS avg_position
FROM `your-project.searchconsole.searchdata_site_impression`
WHERE is_anonymized_query = FALSE
  AND data_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
GROUP BY query
ORDER BY clicks DESC
LIMIT 200

Page-level, year-over-year — the query that’s the entire reason most people set this up, comparing a URL’s performance across calendar years the Performance report would already have quietly dropped:

SELECT
  url,
  EXTRACT(YEAR FROM data_date) AS year,
  SUM(clicks) AS clicks,
  SUM(impressions) AS impressions
FROM `your-project.searchconsole.searchdata_url_impression`
WHERE data_date >= '2023-01-01'
GROUP BY url, year
ORDER BY year DESC, clicks DESC
LIMIT 300

Price your own tables before deciding anything else — this reads your actual accumulated size out of BigQuery’s own metadata and estimates a monthly storage cost at the active rate from the section above:

SELECT
  table_name,
  ROUND(SUM(total_logical_bytes) / POW(1024, 3), 2) AS logical_gib,
  ROUND(SUM(total_logical_bytes) / POW(1024, 4) * 23.55, 2) AS est_monthly_storage_usd
FROM `your-project.searchconsole.INFORMATION_SCHEMA.TABLE_STORAGE`
GROUP BY table_name
ORDER BY logical_gib DESC

Once you’ve got numbers coming back, a Looker Studio dashboard is the free way to turn any of these into something you can actually look at without rerunning SQL every time — it just won’t build itself.

The alternative, and when it is cheaper

In raw Cloud-dollar terms, the bulk export is genuinely inexpensive for most sites — the worked example above is not a best case, it’s roughly what a large site should expect. The Cloud bill is rarely the honest reason to pay a vendor instead. What isn’t free is your own time: writing and maintaining the SQL, deciding on a partition-expiration policy, keeping an IAM grant from silently breaking, and building a dashboard on top of two raw tables rather than opening a finished one. That maintenance job is what a packaged tool actually replaces.

SEO Gets Core — Search Console and GA4 in one view

Core is the first paid tier, listed at $39 per month, and the thing it changes is that search data and behaviour data stop living in two separate tabs. It connects Google Analytics 4 alongside Search Console, then layers on the reports that are tedious to reproduce by hand: striking distance, keyword cannibalization, and content decay. The client-facing half is what most agencies actually buy it for — live portals shared by link, scheduled reports that send themselves, and PNG export carrying your own branding rather than a vendor logo.

What to check

• Vendor: SEO Gets
• Plan level: first paid tier, above the free plan and below Pro
• Check before buying: whether you specifically need GA4 alongside Search Console, whether anyone will actually open the client portals, and whether the opportunity reports tell you something your current process does not

Who it suits

The reader who has outgrown exporting Search Console by hand every month but has not yet hit the retention wall. That is usually a freelancer or a small agency reporting on several client properties, where the saving is measured in hours per client per month rather than in any single feature. Connected properties and team seats are unlimited on every tier including Free, so this plan is not a way to buy more capacity — it is a way to buy the reports and the client-facing output.

Be aware

History stays at 16 months on this tier, matching Search Console’s own limit, so if the problem you are solving is a year-over-year comparison that already aged out, this plan does not solve it. Index reporting for indexed pages is a Pro capability and is not included here either. And the free plan is a genuinely working Search Console dashboard, so the honest question before paying is whether GA4, the client portals or the opportunity reports are worth $39 a month to you specifically — not whether the paid tier is better in the abstract.

See best price

SEO Gets Pro — the tier that removes Search Console’s ceilings

Pro is listed at $49 per month and exists to lift the two limits that eventually stop everyone: Google Search Console retains 16 months of performance data and throttles its API, and no dashboard built on top of it can invent history the source no longer holds. This tier retains up to five years, removes the Search Console API request limit, and adds index reporting so the number of pages Google actually has indexed becomes something you can watch move rather than something you spot-check. It also introduces the Super Site concept, extended storage, and content change tracking.

What to check

• Vendor: SEO Gets
• Plan level: top tier, above Core
• Check before buying: how old the site is, how many properties genuinely need long history, and whether anyone will act on index reporting once they have it

Who it suits

The reader whose reporting question is historical — year-over-year comparisons, the shape of a site before and after a core update, or an argument that has to be made with data older than Search Console keeps. It also suits anyone whose current setup is already hitting Search Console API quota errors rather than row limits, because removing that ceiling is a capability rather than a convenience.

Be aware

The extended history and index reporting apply to one Super Site, so a portfolio of equally important properties is a different calculation than a single flagship site, and it is worth doing that arithmetic before upgrading. Retention also only runs forward: a plan bought today does not retroactively recover months that have already aged out of Search Console, which is the single most common misunderstanding about paying for retention. If the site is younger than 16 months, the headline feature has nothing to retain yet and Core is the honest recommendation.

See best price

Both plans connect directly to your existing Search Console and GA4 properties and turn that data into a dashboard, without a Cloud project, an IAM role, or a line of SQL. Pro’s specific relevance to everything on this page is its retention: history kept for up to five years, which is the packaged, no-SQL answer to the exact 16-month ceiling this whole article has been about. Core doesn’t extend retention past Search Console’s own window — it’s the dashboard and client-reporting layer on top of whatever history you already have, including anything you’re separately capturing through the bulk export.

• Do the DIY BigQuery route if someone on your team already writes SQL and you’re comfortable owning a small Cloud project, an IAM grant, and a partition-expiration decision — at most sites’ scale, the Cloud cost itself won’t be what stops you.
• Do buy SEO Gets Core if you want the same underlying Search Console and GA4 data as a client-ready dashboard without any of the setup above, and retention past 16 months isn’t the problem you’re actually solving.
• Do buy SEO Gets Pro if the 16-month wall specifically is what’s blocking you and you’d rather pay $49 a month than run a Cloud project to get past it — up to five years of history, packaged, with no SQL required.
• Do neither yet if your site is younger than 16 months or you’ve never actually hit the Performance report’s row cap. There’s no ceiling to solve for until one of those changes.

Comparison: who this fits and who it does not

• Agencies with an engineer or analyst on staff → the DIY BigQuery route. At most sites’ scale it’s functionally free, and you get row-level control over data no dashboard tool exposes directly.
• Agencies billing client time without in-house SQL → SEO Gets, Core or Pro depending on whether retention is the actual problem — building and maintaining the same pipeline by hand almost always costs more in billable hours than the subscription.
• Sites younger than 16 months → neither. The free UI already shows your entire history; there’s nothing yet for either route to solve.
• Sites that already lost pre-16-month history → neither route recovers it. Both only start counting from the day you turn them on.
• Large sites hitting the Search Console API’s row ceiling → the bulk export first, since it removes the per-request cap entirely rather than just raising it.
• Anyone whose actual job isn’t Search Console reporting at all → see the tools built for the other jobs people call “SEO monitoring” — neither BigQuery nor SEO Gets does independent rank tracking, crawling, or backlink data.

Practical tips

Set a partition expiration the same day you configure the export. Left on its default, data accumulates forever. Google enforces a 14-day minimum, but a year or two of rolling retention is more realistic for most budgets — and it’s a partition-level setting, not a table-level one; the wrong choice deletes everything at once, not just the old rows.

Keep site-level and URL-level questions apart. searchdata_site_impression has no url column, which makes it far cheaper to scan for trend questions. Reach for searchdata_url_impression only when the question genuinely needs per-page detail — mixing the two out of habit means paying to scan a column you didn’t need.

Filter on data_date first, in every query. It’s the partitioned column, and every query above starts there for a reason: it’s the fastest and cheapest thing you can do to a query against these tables, before any other optimization.

Treat the exported schema as fixed. Adding, renaming, or dropping a column breaks the export outright and forces a full reconfiguration from Search Console’s side, not just a query fix on yours.

Check ExportLog before assuming your data is complete. A quietly broken permissions grant produces missing days with no alert beyond a week of silent retries — the log table records only successful exports, so a gap in its dates is the clearest signal something failed upstream, well before a missing day shows up as a dip in a dashboard chart.

Budget for two exports if you run more than one property. Each Search Console property configures its own export separately, and if you’re sending several into the same Cloud project, each one needs its own dataset name — the default searchconsole name only works once. Splitting properties across separate datasets keeps the storage-cost query above accurate per property instead of one blended number.

Don’t rebuild a charting layer you don’t have to. If the end goal is a report someone other than you reads, a client-ready dashboard or a Looker Studio view gets you there faster than a spreadsheet fed by manual query exports.

Frequently asked questions

Does the BigQuery export recover data Search Console already deleted?

No. This is the single most important thing to understand before setting it up: the export only accumulates data from the day you enable it forward. Anything past Search Console’s 16-month retention window that isn’t already captured somewhere else is gone, and neither the bulk export, the Search Console API, nor the canned reports will bring it back.

How much does the bulk export actually cost per month?

For most sites, close to nothing. The first 10 GiB of storage and the first tebibyte of queries are free every month, and a site large enough for Google to specifically recommend this feature — tens of thousands of pages or daily queries — typically lands under a dollar a month once past those free tiers, as the worked example above shows. Cost climbs with query volume and table size, not with how long you’ve been running the export, so check your own numbers with the pricing query in this article rather than assuming a fixed figure.

Do I need to know SQL to use this?

Yes, for the raw export itself — there’s no UI on top of the two BigQuery tables Search Console creates. If SQL isn’t something you or your team wants to maintain, a Looker Studio dashboard covers the standard Performance-report shape without writing queries, and SEO Gets covers the client-reporting and multi-year retention case without a Cloud project at all.

What’s the difference between the bulk export and the Search Console API?

The Search Console API is a request-based way to pull data on demand, capped at 25,000 rows per request and still bound by the same 16-month retention window Search Console applies everywhere else. The bulk export instead pushes a daily, unaggregated dump into BigQuery with no per-request cap, and — critically — it starts its own retention clock the day you configure it rather than inheriting the 16-month one.

Can I control cost by deleting old data myself?

Yes, through a partition expiration set on the exported tables, not by manually deleting rows. Set it the same day you configure the export; the enforced minimum is 14 days, and most budgets land somewhere between one and a few years depending on how far back you actually need to query.

Does the export include every search query, including rare ones?

Rare queries are still represented, just without the query text. Search Console marks them with is_anonymized_query and blanks the query field to protect user privacy, but the impression and click counts for that row are preserved — a meaningful difference from the UI, which drops those queries from view entirely rather than keeping them anonymized.

Is this the same thing as a Search Console SEO audit?

No, and they answer different questions. A Search Console SEO audit works from indexing and coverage signals Google already reports on your property. The bulk export is raw performance data — clicks, impressions, position — with none of that diagnostic framing attached; you’d still need to build or buy the audit logic on top of it.

Whether the bulk export earns a place on your site comes down to one question: is the SQL and the Cloud project actually cheaper than $39 to $49 a month, given what your own time is worth? If the 16-month wall is the entire problem, SEO Gets Pro solves it without a line of SQL. If you’d rather see the fully free path first, start with the Search Console API and Search Console’s own audit signals before deciding whether raw export rows are the tool you actually need, and once you’re querying anything, a Looker Studio dashboard is the free way to chart it without opening BigQuery every time you want to look.