How to Keep Google Search Console Data Past the 16-Month Limit

Somewhere in Search Console, a day of your site's history expired this morning. Not archived, not hidden behind a setting. Gone, from the UI, the API, and every dashboard that reads them.

Search Console keeps performance data for a rolling 16 months, and as of August 2026 there is no way to extend it. If you want a longer memory, you capture the data yourself, and the only real decision is which pipeline does it. This guide sets one up, in order: back up what you still have, pick the capture route, verify it, and make the history worth keeping.

What Search Console keeps, and for how long

The 16-month figure gets quoted as if it covered everything. It covers the Performance report. The rest of Search Console forgets faster:

• Performance data: 16 months, rolling. Queries, pages, countries, devices, clicks, impressions, CTR and position. The window slides daily.
• Crawl stats: 90 days. A quarter of crawl behaviour, then nothing.
• Links: a snapshot. The report shows current state with no history at all.
• Index coverage and URL inspection: live state. A status rather than a series, so there is nothing to retain.

What the rolling window quietly costs you

Sixteen months sounds generous until you try to use it. It allows exactly one year-over-year comparison, with four months of slack, and nothing more:

• No second year. "Is this December dip seasonal or a decline?" needs two prior Decembers. You have one.
• No update forensics. When a core update lands, the question is how your site weathered the previous ones. Their data has usually rolled off.
• No migration baseline. A redesign's true cost shows over years. The before-state expires while the after-state is still settling.

The trap is that none of this hurts today. It hurts in two years, when the question finally comes up and the answer left the building on a rolling schedule.

Step 1: Back up the 16 months you still have

Whatever pipeline you choose, do this first, because it is the only backfill that will ever exist. Today's window is the oldest data you will ever be able to save.

1. Skip the UI export for this job. It caps at 1,000 rows per table, which truncates any site with real query volume.
2. Pull over the Search Analytics API instead. It serves the same 16 months at up to 25,000 rows per request, paged beyond that. A short script, a Sheets add-on, or any connected tool can make the pull.
3. Take date, query, page, country and device as dimensions. Storage is cheap; the question you will have in 2028 is not.
4. Date the file and store it somewhere boring. A warehouse table, a Drive folder, anywhere that outlives your laptop.

Step 2: Pick the pipeline that keeps it growing

The backfill is a snapshot. Ongoing capture is a pipeline, and there are four real ones. None of them reaches backwards, which is why step 1 came first:

• BigQuery bulk export, the route Google built for this. One setting in GSC streams daily tables into your Cloud project, with more of the query long tail than the API surfaces. The costs are a Google Cloud bill that stays small at small-site volumes, and needing SQL to read your own data.
• A scheduled API pull, for control without Cloud setup. A script or Sheets add-on that runs monthly and appends. The catch: you own the script, including the month it silently stops.
• The manual ritual, a calendar reminder and an export. Free, immediate, and dependent on a human remembering. Honest verdict: better than nothing, worse than everything else here.
• A tool that stores it, where a vendor syncs your property and keeps history beyond the window. Zero setup beyond OAuth; the trade is that your archive lives inside someone else's product, at their granularity.

Setting up the BigQuery bulk export

The best route deserves its five steps; the tables, starter SQL and gotchas have their own full guide. You need Owner permission on the GSC property:

1. Create or pick a Google Cloud project with billing enabled, and note its project ID.
2. In that project, grant the Search Console service account the BigQuery roles Google's setup screen names.
3. In Search Console, open Settings → Bulk data export, paste the project ID, choose a dataset location, and confirm.
4. Wait up to 48 hours for the first daily tables to appear. The export writes forward from this point only.
5. Run one test query against the new dataset, then save it. That query is your monthly verification, which is step 3.

Step 3: Verify the pipeline before you trust it

A retention pipeline has one failure mode that matters: silently stopping, discovered years later at the exact moment you needed it. Guard against it on a schedule:

• Check arrival monthly. Last month's dates exist in the dataset, the sheet, or the tool. Thirty seconds, on the same reminder that used to run the manual export.
• Compare a spot value against the UI. Same property, same date range, same dimension. Expect close, not identical: rare queries are anonymized out of the query dimension, and the freshest days are still provisional when pulled.
• Watch for property changes. Moving from a URL-prefix to a domain property, or re-verifying under a new owner, starts a new data lineage. Update the pipeline the same day, not the next time someone looks.
• Export before you retire a property. Removing a property from Search Console is reversible, but the rolling window keeps moving while it sits outside your account. Pull the final 16 months first.

Step 4: Annotate while you still remember

Here is the part the export tutorials skip: raw history answers "what happened", never "why". Three years from now, the chart will show a step change in March 2026, and nobody will remember whether that was the migration, the core update, or the month you fixed the titles.

• Record every change worth a chart annotation: site migrations, template changes, major content pushes, fixes shipped, and each Google update as it lands.
• Keep the notes next to the data. A dated sheet tab beside the archive, or SEO annotations pinned to your traffic timeline, which is exactly what CrawlRaven's annotations are for.
• Write them the week they happen. Annotation is the one step that cannot be backfilled either. Memory has a shorter retention window than Search Console.

Step 5: Put the history to work

The archive earns its keep the first time a question needs more than 16 months:

• True seasonality. Two or three Decembers deep, you can finally separate the seasonal dip from the decay. Your KPI reporting stops hedging.
• Update resilience. How this site responded to the last three core updates is the context every new update lacks.
• Long decay curves. Pages that erode 3% a month never trip a monthly alarm. Over two years the archive makes the slope undeniable, and the rescue is the striking distance loop with better evidence behind it.

Tips that save a future you

• Do step 1 today even if the pipeline decision waits. The backfill pull is independent of every route and is the only part with a deadline that moves daily.
• Export crawl stats quarterly if you care about them. The 90-day window means an annual look is already three quarters too late.
• Capture per property, not per site. Subdomains and country properties each have their own data and their own rolling window.
• Keep the raw dimensions, aggregate later. A monthly rollup you built in 2026 cannot answer a per-page question asked in 2028. Storage is cheaper than foresight.
• Filter brand out at analysis time, not capture time. Your brand-versus-non-brand split will change definitions; the archive should not have opinions baked in. Build the split with our GSC regex generator when you query, not when you store.

Why your pipeline looks wrong, and what to check

• BigQuery dataset still empty after setup? The first tables can take up to 48 hours. Empty after three days means the export failed: recheck the project ID and the service account roles in the setup screen, then confirm the property's owner permission.
• Numbers close to the UI but never equal? That is the design, not a bug. Anonymized rare queries are excluded from query-level rows, totals are computed at a different level, and recent days firm up over time. Alarm at big gaps, not small ones.
• A hole in the archive? Find the month the script died or the reminder was skipped, and check whether that window is still inside the current 16 months. If it is, pull it now over the API. If not, document the gap and move on; nothing recovers it.
• History split across two properties? A domain-property migration starts a new lineage. Keep both archives, note the switch date in your annotations, and compare across it with care rather than stitching the numbers silently. Tracking a migration in GSC covers reading the two properties as one line.

Tools that make this easier

The honest tooling picture, including where we fit and where we do not:

• Free, on this site: the GSC regex generator builds the brand and topic filters for analysis time, and our monthly Search Console routine is the working schedule the verification step slots into.
• CrawlRaven: daily GSC and GA4 sync over OAuth, dated annotations pinned to your traffic timeline, and the join that turns a historical drop into a diagnosis with crawl and engagement evidence attached. Honest limit: our reporting reads the same 16-month API window as everyone else's, so for a multi-year raw archive you still want the BigQuery export alongside.
• Dedicated GSC-storage tools: SEO Gets and similar GSC-layer tools store your performance history from the day you connect, which solves retention with zero setup. The trade-offs are the vendor's granularity and the subscription outliving your need for the archive.

Whichever combination you pick, the sequencing is fixed: backfill first, pipeline second, verification on a calendar. The window rolls tonight either way.