Google Search Console's Performance report is a live window of about 16 months. When a day ages out, the UI and the Search Analytics API stop serving it. Nobody — not BigQuery, not a hosted product, not a support ticket — recovers days Google already deleted.
So the real choice is how you copy days while Google still holds them. Two serious paths show up in every architecture review:
- BigQuery bulk export — Google's first-party forward warehouse. You own the tables. Exports typically start from enable day. No automatic backfill of the ~16 months already in Search Console.
- A hosted Search Console archive (SiteLine and peers) — product OAuth connect, backfill of what Google still holds on connect day, retention while you subscribe, UI, and (on SiteLine) read-only MCP for agents.
This page is the deeper BigQuery vs hosted decision. For the wider option set (Looker Studio, CSV, DIY API), start with Best Google Search Console history tools. Retention maths: 16-month limit and year-over-year when the prior year is gone. Row caps: 1,000-row UI limit and export more than 1,000 rows.
Decision framing in one sentence
BigQuery wins when you already live in GCP, need maximum forward row completeness, and will staff SQL + ops. Hosted wins when you need today's Google window copied now, a product UI (and optional agents), and do not want to run Cloud for this job. Both wins when you want warehouse-scale forward data and the backfill BigQuery will not give you.
Comparison at a glance
| Dimension | BigQuery bulk export | Hosted archive (e.g. SiteLine) |
|---|---|---|
| Backfill of Google's live ~16 months? | No — typically forward-only from enable day | Yes — copies what Google still holds on connect (capped by property verification age) |
| Retention past month 16? | Yes, for days that landed in your dataset | Yes, for imported days while you subscribe |
| Row completeness | Full daily export path (no Search Analytics rowLimit on the bulk path) |
Product caps apply — SiteLine: 25k rows/day/report (one API page; not rows 25,001–50,000) |
| Setup / ops | GCP project, billing, IAM, dataset location, SQL, storage/query cost | OAuth connect (webmasters.readonly); product runs imports |
| Cost shape | Cloud storage + query + engineering time | SaaS subscription (SiteLine from $4.99/mo; 7-day trial, no card) |
| Agent / MCP access | Build your own (or point BI at BQ); not a product MCP out of the box | SiteLine: read-only MCP on the same warehouse — /mcp |
| Best when | Data teams already in GCP; long-tail SQL; joins to other warehouse tables | SEO/product teams that need backfill + UI/MCP without staffing Cloud |
Looker Studio's native Search Console connector is not in this table as an archive — it re-reads Google's live window on refresh. Details in the history tools overview. Point Looker at BigQuery (or another stored copy) if you need charts of retained days.
What BigQuery bulk export actually does
Google's Search Console bulk data export writes daily performance data into a BigQuery dataset you control. For teams that already operate Cloud, it is the serious first-party answer going forward.
What it gets right
- Once a day lands in BigQuery, retention is yours — month 17 does not empty because Google aged the UI.
- The bulk path is built for scale. It is not the same daily
rowLimitceiling that caps interactive Search Analytics API pulls. - Fits SQL, dbt, Looker on BigQuery, and joins to ads, CRM, or product tables you already warehouse.
- Anonymised rare queries stay anonymised — BigQuery does not invent withheld strings. That honesty matches the API.
What it does not do
- No automatic backfill of the ~16 months already sitting in Search Console on enable day. Turn it on in October and last spring is still only in Google's live window until that window rolls off.
- Needs a billing-enabled Google Cloud project, the right APIs, IAM so Search Console's export service account can write, a dataset location choice, and someone who can query the tables.
- First useful export is not instant after a correct config — plan for setup lag (often within about 48 hours).
- It is SQL and ops, not a Search Console product UI for movers, striking distance, or agent tool calls.
Practical pattern many careful teams use: enable BigQuery for the future and run an API or hosted backfill for the overlap Google still has today. BigQuery alone leaves a permanent hole for everything before enable day. Pairing is how you avoid learning that in month 17 — the same advice as the history tools guide, expanded here because this is the decision people actually fight about in design docs.
What a hosted archive (SiteLine) actually does
A hosted Search Console archive takes Google's read-only scope, copies the window Google still serves, then keeps importing new days under a product retention policy. SiteLine is one such product — built for teams who hit the 1,000-row and ~16-month walls and want a product path instead of a Cloud project.
| Piece | SiteLine behaviour |
|---|---|
| Connect | Read-only OAuth (webmasters.readonly) — connect guide |
| Backfill | Copies the overlap Google still holds (~16 months minus publish lag), if the property was verified that long |
| Ongoing | Re-imports recent days so Google's revisions land |
| Breakdowns | Up to 25,000 rows per day per report (one API page) |
| Site totals | Stored separately so headlines are not sums of query rows |
| Retention | Keeps imported days while you subscribe; cancel and reconnect later → only what Google still holds on the new connect day |
| Agents | Same warehouse over MCP (read-only; webmasters.readonly — no indexing, no sitemap submit) — MCP for Search Console data |
| Pricing | From $4.99/mo; 7-day trial, no card |
What SiteLine does not claim
- It does not recover days Google already deleted before you connected.
- It does not offer BigQuery-class full export without row caps — the import is Search Analytics API–shaped at 25k rows/day/report, not a second page to ~50k and not the bulk export path.
- It does not replace a company-wide warehouse when your job is unsampled SQL across every marketing and product table.
- It does not turn Search Console into GA4. Cookieless analytics is a separate install on the same property when you want pageviews beside clicks.
- MCP tools are read-only. Agents query; they do not submit sitemaps or request indexing through SiteLine.
When to choose BigQuery
Choose BigQuery bulk export when most of these are true:
- Someone on the team already owns GCP billing, IAM, and dataset hygiene.
- You need maximum forward completeness and will query with SQL (or put BI on BigQuery).
- You will join Search Console tables to other warehouse facts (campaigns, revenue, product events).
- You accept that history before enable day is a separate project (API job or hosted backfill) — or you truly only care about the future.
- Engineering time to babysit exports, schema changes, and access control is cheaper than a SaaS subscription for this job.
Skip BigQuery as the only plan if you still need last year's quarter that Google holds today and have not started any backfill. Enabling BQ next sprint does not rewind the clock.
When to choose a hosted archive
Choose hosted (SiteLine) when most of these are true:
- You need the ~16 months Google still has copied this week — before month 17 YoY goes empty.
- You want a product UI for overview, movers, striking distance, and honest site totals — not a SQL notebook as the only interface.
- You want agents on the same warehouse (Cursor, Claude Code, ChatGPT, etc.) without building an MCP server on top of BigQuery.
- Nobody will staff Cloud ops for Search Console alone.
- A predictable SaaS bill from $4.99/mo beats an unbounded engineering queue.
Connect when a prior-year quarter is about to leave Google's window, when clients expect Search Console YoY past month 16, or when agents should refuse empty prior periods as missing instead of inventing zeros. Step-by-step: Connect Google Search Console to SiteLine. Prefer agent access on signup? Register with MCP intent.
When both is the right answer
Running BigQuery + hosted (or DIY API) backfill is coherent, not wasteful:
| Layer | Job |
|---|---|
| BigQuery bulk export | Forward warehouse you own; SQL; joins; maximum row completeness from enable day |
| Hosted / API backfill | Capture Google's current live window so pre-enable months are not permanently lost |
| Product UI / MCP (hosted) | Day-to-day SEO and agent workflows without every question becoming a SQL ticket |
| Looker (optional) | Charts pointed at stored tables — never the native GSC connector as your only backup |
Teams that pick Looker-only or CSV-only are not in this "both" pattern. Those paths visualise or snapshot the live window; they do not archive it. See history tools.
Cost and ops without the brochure
BigQuery. Storage and query pricing sit on your Cloud bill. The quiet costs are IAM reviews, dataset location mistakes, someone on-call when exports stall, and the time to define "site total" vs breakdown tables so agents and dashboards do not sum query rows. Free tiers help early; they do not remove ownership.
Hosted. You pay the subscription. Imports, retries, and a UI are the product's problem. You still own cancel/reconnect behaviour: leave and come back later and you only get what Google still holds on the new connect day — SiteLine does not keep paying to store your history after you cancel.
Neither path is "free Search Console forever." Google's live UI is free and temporary. Archives cost money or engineering because they are copies.
Honest CTAs
Want the backfill Google still holds today, retention while you subscribe, and optional MCP — without standing up BigQuery for this job?
- Create a SiteLine account — 7-day trial, no card
- Sign up with MCP intent if agents are the first use case
- Pricing from $4.99/mo
- Product surface for agents: /mcp
Still deciding among all history options? Read Best Google Search Console history tools first, then come back here for the BigQuery vs hosted cut.
FAQ
Does BigQuery backfill Search Console history?
Typically no. Bulk export is a forward path from enable day (plus setup lag). The ~16 months already in Search Console stay in Google's live window until you copy them another way — Search Analytics API, Sheets with a raised rowLimit, or a hosted archive.
Can SiteLine replace BigQuery for my whole company?
No. SiteLine is a hosted Search Console (and cookieless analytics) product with API-shaped row caps (25k rows/day/report). If your job is company-wide unsampled SQL and joins across every marketing table, keep BigQuery. Use SiteLine when you want backfill, UI, and MCP without running that warehouse for this job — or run both.
Is Looker Studio a middle ground between BigQuery and hosted?
Not for retention. The native Search Console connector is a live chart. Days that leave Google leave the dashboard. Looker becomes useful for history when it reads BigQuery or another archive you already filled — covered in the history tools comparison.
Will either path recover deleted GSC days?
No. Archives only protect what existed on the day you started copying. Waiting a quarter permanently shortens what you can save. Same rule as YoY.
How do row limits differ?
BigQuery bulk export is the full daily export path (aside from anonymised queries Google withholds). SiteLine imports via the Search Analytics API up to 25,000 rows per day per report and does not request the second page (~25,001–50,000). Site totals are stored separately. Never sum named query rows and call that the property — export guide.
Can agents query BigQuery the same way they query SiteLine MCP?
Not out of the box. SiteLine exposes read-only MCP servers on the imported warehouse (MCP overview). BigQuery needs you to build access (SQL tools, a custom MCP, or BI). That is fine for data teams; it is extra work if you only wanted an agent to ask for movers on a URL.
What if my property is only four months old?
Every backfill — hosted or API — is capped by what Google stored since verification. BigQuery still starts at enable day. Neither path invents a prior year Google never held.