Google Search Console keeps Performance data for about 16 months. After that, the day is gone from the UI and from the Search Analytics API. No connector, dashboard, or support ticket brings it back.
So “best Search Console history tool” is not a feature checklist. It is a decision about how you copy days while Google still holds them, and whether you need the past 16 months on day one or only a clean forward archive. This guide compares the options people actually evaluate — Looker Studio, CSV panic exports, a DIY API warehouse, BigQuery bulk export, and hosted archives — and says plainly what each can and cannot keep.
Retention math and YoY cliffs: 16-month limit and year-over-year when the prior year is gone. Row caps are a separate trap: 1,000-row limit.
What “history” means in Search Console
People mix four different jobs under one word.
- Live window — whatever Google still serves today (~16 months minus a 2–3 day publish lag). The UI, API, and Looker Studio connector all read this.
- Forward archive — days you store from enable day onward so month 17 never empties again. BigQuery bulk export is the first-party version.
- Backfill archive — a copy of the overlap Google still holds on connect day, then ongoing imports. Hosted tools and careful API jobs do this.
- Recovered past — days already aged out before anyone copied them. Nobody offers this. If Google deleted the day, it is gone.
If your property was verified four months ago, every path above starts with about four months. No tool invents a prior year Google never stored.
Comparison at a glance
| Path | Keeps days past month 16? | Backfills the ~16 months Google still has? | Row completeness | Setup burden | Best when |
|---|---|---|---|---|---|
| Search Console UI / API alone | No | N/A (live window only) | UI ~1k rows/table; API ~25k/page (paginated higher) | None | Quick checks inside the window |
| Looker Studio (GSC connector) | No | No — live API on refresh | Same as Google’s live data | Low | Charts of the current window |
| One-off UI CSV / Sheets | Only what you saved, incomplete | Manual, capped | ~1,000 representative rows | Low | A slide this week |
| DIY Search Analytics API warehouse | Yes, for days you pulled in time | Yes, if you schedule it | Up to what you paginate and store | High (OAuth, jobs, storage) | Engineering-owned pipelines |
| BigQuery bulk export | Yes, from enable day forward | No | Full daily export (no per-pull row cap) | Medium–high (Cloud + SQL) | Long-term warehouse you own |
| Hosted archive (e.g. SiteLine) | Yes, while subscribed | Yes, of what Google still holds on connect | Product row caps apply (SiteLine: 25k rows/day/report) | Low (OAuth connect) | Teams that want backfill + product UI / agents without running Cloud |
Empty cells in a Looker chart after month 16 are retention, not a traffic crash. Zero-filling them lies to the deck — same rule as YoY.
Looker Studio: great chart, not an archive
Looker Studio’s Search Console connector is free and familiar. It is also the most common false archive.
- Every refresh asks Google for the live Performance window.
- When a day ages out of Search Console, it ages out of the dashboard.
- Saving a Looker report does not snapshot row-level history into a warehouse you control.
- Filters, blended data, and pretty YoY date controls cannot extend Google’s retention.
Use Looker Studio to visualise an archive you already own (BigQuery tables, Sheets you maintain carefully, or a product that exposes history). Do not treat the connector as backup. If your only “history tool” is Looker on the native connector, you have visualisation of the same 16 months everyone else sees.
CSV and Sheets: a working list, not retention
Exporting the Performance table before a quarter ages out feels responsible. It usually is not enough.
- The download is about 1,000 representative rows, not every named query.
- Chart totals in that file can include data the table never lists.
- The file does not update when Google revises a recent day.
- Sixteen months later Google will not re-serve the day so you can export again.
A spreadsheet is fine for a client slide inside the window. It is a weak strategy for month-17 YoY or multi-year query decay. Details: export more than 1,000 rows.
DIY Search Analytics API warehouse
You (or a script) call the Search Analytics API on a schedule, store site totals and breakdowns, and keep the database as long as you want.
Strengths
- True backfill of whatever Google still holds when the job runs.
- You choose dimensions, search types, and how hard you paginate past the first ~25k rows.
- Full ownership of schema and retention policy.
Costs
- OAuth, quotas, retries, and a place to store revised recent days (Google keeps rewriting the newest points).
- You must refuse empty ranges as missing, not zero — especially for agents and auto-charts.
- Engineering time is the real price; the API calls are free.
Choose this when Search Console history is a first-class data product for your org and someone will own the pipeline. Skip it when you wanted a weekend dashboard and ended up on-call for import gaps.
BigQuery bulk export: best first-party forward archive
Google’s bulk data export writes daily Search Console performance into BigQuery. For teams that already live in Cloud, it is the serious first-party answer going forward.
What it gets right
- Retention is yours once the day lands in BigQuery.
- No Search Analytics API
rowLimiton the export path — built for scale and long-tail analysis. - Fits SQL, Looker on BigQuery, and joins to other warehouse tables.
What it does not do
- No backfill of the ~16 months already sitting in Search Console on enable day.
- Needs a Google Cloud project, billing, IAM for Search Console’s service account, and someone who can query the tables.
- First useful export is not instant; plan for setup lag (often within about 48 hours after a correct config).
- Anonymised rare queries stay anonymised — BigQuery does not invent the withheld string.
Practical pattern: turn BigQuery on 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 careful teams avoid learning that in month 17.
Hosted archives: backfill without running Cloud
Hosted Search Console archives (SiteLine and peers) take webmasters.readonly, copy the window Google still serves, then keep importing new days. The product difference is retention policy, row caps, UI, pricing, and whether agents can query the warehouse.
Where SiteLine fits
SiteLine is built for teams who hit Google’s 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; not the second page to ~50k) |
| 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) — MCP setup |
| Pricing | From $4.99/mo; 7-day trial, no card |
SiteLine does not invent days Google already dropped, does not replace BigQuery when you need unsampled warehouse-scale SQL across your whole company, and does not turn Search Console into GA4. Cookieless analytics is a separate install on the same property when you want pageviews beside clicks.
How to choose (decision tree)
Stay in Google alone if you only need the last few months, seasonal YoY still fits inside ~16 months, and a 1,000-row export is enough for the slide.
Use Looker Studio on the native connector only for live exploration — never as your backup plan.
Export CSV for a one-off list. Do not call it an archive.
Choose BigQuery bulk export if you own Google Cloud, want maximum forward completeness, and will query SQL (or put Looker on BigQuery). Add an API/hosted backfill if you still care about the months Google holds today.
Choose a DIY API warehouse if engineering will staff imports, revisions, and access control as an internal system.
Choose a hosted archive (SiteLine) if you want backfill on connect, retention while subscribed, a UI for movers/striking distance/YoY-style work, and optional MCP for agents — without operating BigQuery for this job.
Many teams run BigQuery + hosted/API backfill. That is coherent. Looker-only or CSV-only is not.
A checklist before you pick a vendor (or build)
- Name the job: live charts, forward warehouse, backfill of today’s Google window, or impossible recovery of deleted days.
- Confirm property age and verification date — that caps every backfill.
- Ask explicitly: Does it backfill? Does Looker/Sheets store rows or only query live?
- Separate site totals from breakdown row caps; never sum query rows to rebuild the property.
- Plan for Google’s revision of recent days (re-import or accept drift).
- Keep search types apart (Web ≠ Discover; Discover/News position is null).
- For agents: require
data_from/data_throughand refuse empty prior periods as missing, not zero. - Write down cancel/reconnect behaviour — most hosted archives do not keep paying for your history after you leave.
When to connect SiteLine this week
Connect now if a prior-year quarter is about to leave Google’s window, if clients expect Search Console YoY in month 17, or if you want agents to query a stored copy with the same honesty rules.
Do not expect miracles if the property is new, if the year you need already aged out, or if you only needed top queries for one deck (the UI export is enough).
Want the backfill Google still holds today, plus retention while you subscribe? Create a SiteLine account — trial starts without a card. Prefer agents on the same warehouse? Sign up with MCP intent. Step-by-step connect: Connect Google Search Console to SiteLine.
FAQ
Does Looker Studio keep Search Console history past 16 months?
No. The native connector reads Google’s live window on refresh. Days that leave Search Console leave the dashboard. Point Looker at BigQuery or another stored archive if you need longer history.
Is BigQuery enough by itself?
For the future, yes if you enable it in time and operate the warehouse. For the past ~16 months already in Search Console, bulk export does not backfill. Pair it with an API or hosted backfill if you still need that overlap.
Can any tool recover days Google already deleted?
No. Archives only protect what existed on the day you started copying. Waiting a quarter permanently shortens what you can save.
How is a hosted archive different from the Search Analytics API?
It is still the API under the hood (plus product storage). You trade engineering ops for a connect flow, retention policy, UI, and — in SiteLine’s case — MCP. Row caps and cancel behaviour still matter; read them before you trust month-17 YoY.
Will SiteLine show more than 16 months immediately after connect?
Only if you already imported days earlier under an active subscription, or if “more than 16 months” means calendar maths that still sit inside Google’s current window. A brand-new connect copies what Google still holds that day — about 16 months minus publish lag, capped by verification age — then grows forward while you subscribe.