google search consolegsc 16 month limithistorical seo datagsc data retentionsearch console apisearch console tools

Google Search Console 16 Month Data Limit: How to Keep Historical SEO Data Forever (2026)

Google Search Console only keeps 16 months of Performance data. After that it is gone for good. Here is how to back up GSC data, why the cap exists, and the six ways to keep a permanent archive.

Search Console Tools Team16 min read
Table of Contents

The 1,000 row cap is the GSC limit everyone complains about. The 16 month data retention limit is the one that actually costs people money. Rows you cannot see in the UI today are usually still queryable through other means. Data that aged out 17 months ago is gone, with no way to ever pull it back.

If you have ever wanted to compare this quarter's queries to the same quarter two years ago, prove a year-over-year recovery to a client, or trace when exactly a page started bleeding traffic, you have run into the 16 month limit. And by the time you notice you needed the data, it is already too late.

This guide explains exactly what the 16 month limit covers, what it does not, and the six durable ways to keep a permanent archive of your Search Console data so you never lose visibility again.


What Is the Google Search Console 16 Month Data Limit?

The 16 month limit is a rolling retention window on Performance data in Google Search Console. Any clicks, impressions, CTR, or average position metric older than approximately 16 months from today's date is permanently removed from the GSC UI and the GSC API.

The window slides forward every day. Whatever the date is when you read this, GSC will let you query data starting roughly 16 months back from today and ending three days ago. Everything older drops off the back of the window and is unrecoverable from Google's side.

A few important specifics most SEOs miss:

  1. It is 16 months, not 18 or 24. Some older guides still quote 18 months or 24 months because the cap was raised from 90 days to 16 months back in 2018 and a lot of stale content never updated. Today it is 16 months, full stop.
  2. The window is rolling, not anchored to a calendar. You will never wake up on January 1 and find that all of last year's data has reset. Instead, the oldest day in your queryable range drops off every 24 hours.
  3. Three-day reporting delay applies. The newest end of the window is typically three days behind today's date, so the effective queryable range is roughly today minus 16 months to today minus 3 days.
  4. Aggregate metrics survive briefly past the cap. The very oldest summary tiles in the Performance dashboard sometimes show one or two extra weeks of total clicks and impressions before the 16 month wall hits, but the breakdown tables (queries, pages, countries, devices) cut off cleanly at 16 months.

If you want a quick gut check: open the GSC Performance report, set the date filter to a custom range, and try to pick a start date 17 months ago. The picker will refuse. That is the wall.


Why Does Google Cap Data at 16 Months?

Google has never published a formal justification, but three reasons are widely understood.

Storage cost at scale. GSC processes signals from every public URL Google has ever crawled, multiplied by every unique query, multiplied by every property owner. Holding that lattice indefinitely would cost an enormous amount and most owners would never read data older than a year.

Search query mix changes too fast. A keyword that mattered three years ago often does not exist as a query today, or has been replaced by a Knowledge Panel, an AI Overview, or a featured snippet. Google's product position is that historical Performance data older than 16 months is often misleading because the SERP it describes is gone.

API steering, again. Just like the 1,000 row cap, the 16 month cap pushes serious users to durable storage solutions they own themselves: BigQuery, third-party tools, or a custom warehouse. Google's stated guidance is that if you want history, export it through the API and store it yourself.

Whatever the reason, the cap is durable. Plan for it the same way you plan for backups: assume that if you do not control the archive, you do not have the data.


What You Lose When Data Falls Off the 16 Month Cliff

Most SEOs underestimate how much value disappears with the data. The most painful losses:

Year-over-year comparisons at 18 to 24 months out. You can do trailing twelve month vs prior trailing twelve month inside GSC if you are quick, but only inside the 16 month window. The moment you need to compare Q1 2025 to Q1 2023, GSC is useless.

Algorithm update post-mortems. A core update that ran in early 2025 will be out of GSC by the second half of 2026. You can no longer pull the exact queries you lost or the pages that took the worst hit.

Pre and post launch comparisons on long sales cycles. A B2B site that ran a major content refresh 14 months ago has only two months left before the baseline disappears.

Client reporting at 18 month or annual review marks. If you take on a client and want to show the last full year of progress at the 18 month anniversary, you can no longer pull the first six months from GSC. Without an archive, you have to ask the client for screenshots or accept the data gap.

Seasonality tracking past two cycles. You cannot see three consecutive Black Fridays, three consecutive Easters, or three back-to-school seasons in GSC. The cap kills the third cycle every time.


The 6 Ways to Keep Permanent GSC Data

Here are the six durable approaches that actually work in 2026, ranked roughly from easiest to most powerful.

1. Manual CSV Exports Every 30 Days (Free, Tedious)

The crudest possible archive. Once a month, open every property, set the date filter to the last 16 months, and click Export. Keep the CSVs in a folder named by export date.

This works only if your sites are small enough that the 1,000 row cap is not biting you. Once you have more than 1,000 meaningful queries, monthly CSV exports drop the long tail, and the gap compounds over time.

Cost: free. Effort: maybe an hour per month per property. Limit: truncates at 1,000 visible rows; collapses if you ever forget a month.

2. The Looker Studio Connector (Free, Live But Limited)

The official Looker Studio GSC connector pulls live data from Search Console into a dashboard. You can build a report that compares any two periods inside the 16 month window and refreshes automatically.

The catch: Looker Studio does not store the data. It queries GSC live. So while your dashboard always shows the most recent 16 months, the moment you go past that wall the data is gone from Looker Studio too. It is a great visualization layer and a terrible archive.

Cost: free. Effort: one afternoon to build the dashboard. Limit: still bound by the 16 month cap because Looker Studio is a query layer, not a warehouse.

3. The Free GSC API + Google Sheets (Free, Slightly Technical)

Use the GSC Search Analytics API with a Google Apps Script or a Python script to pull the full data every month and append it to a Google Sheet. This bypasses the 1,000 row UI cap (the API returns up to 25,000 rows per query, paginated to 50,000 per day per property), and once the data is in Sheets, it lives there forever.

This is the cheapest legitimate archive solution. It still requires you to remember to run the pull each month, and Google Sheets starts to slow down once you cross a few hundred thousand rows.

Cost: free. Effort: one day of scripting plus a monthly run. Limit: Sheets row count caps near 10M cells; performance degrades much earlier.

4. BigQuery Bulk Data Export (Free Tier, Most Robust)

Since 2023, Google has shipped a native BigQuery export for Search Console data. You flip the switch in GSC settings, point it at a BigQuery dataset, and Google writes a daily table containing the raw, ungrouped query data including the long tail that the UI hides.

This is the gold standard for historical archive. Once you turn it on, every day's data lands in BigQuery and stays there indefinitely. You can query against five years of GSC data in BigQuery long after the GSC UI has dropped it. The BigQuery storage cost for a typical small site is pennies per month.

The downsides: it only starts collecting from the day you turn it on, so it cannot retroactively recover data you have already lost. And BigQuery has a learning curve if you have never used SQL.

Cost: typically under $5 per month for a small to mid site. Effort: one hour to set up, then it runs itself forever. Limit: no historical backfill, so set this up today.

5. Third-Party SEO Tools That Archive GSC (Paid)

Several SaaS tools quietly archive your GSC data once you connect the property, giving you a historical view that survives past 16 months. Most include this as a side benefit of their core ranking or audit product.

The tradeoff is vendor lock-in. If you cancel the subscription, you usually lose access to your archive unless you can export it before churning. Some tools also throttle history at 24 to 36 months even though the underlying GSC API would give them more.

Cost: typically $30 to $200 per month depending on tier. Effort: zero, just connect the property. Limit: archive only lives as long as your subscription.

6. Search Console Tools (Paid, Purpose-Built)

Search Console Tools was built specifically for the historical-data problem. It pulls your full GSC dataset on connect, keeps a permanent multi-year archive in our own database, and gives you cuts that the GSC UI cannot: year-over-year comparisons past the 16 month wall, query-level history beyond 1,000 rows, page-level decay tracking across full algorithm cycles.

Unlike general SEO suites, the entire product is oriented around the gap GSC leaves: long memory, deep cuts, no caps. If you have already lost data to the 16 month wall, you cannot retrieve it from anywhere. But you can stop losing it from today forward.

Cost: $19 to $79 per month depending on property count. Effort: zero, one-click connect. Limit: like every other tool, archive only begins on connect day.


Decision Tree: Which Approach Should You Use?

A short rubric to pick the right approach for your situation.

You manage one small site under 1,000 indexed pages, you only need annual recaps. Go with monthly CSV exports. Set a calendar reminder for the first of every month.

You manage one to five sites, you are technical or have access to a developer. Turn on the BigQuery export today. Set up a Looker Studio dashboard on top of it for visualization. You will spend an hour now and have permanent archive forever.

You manage one to five sites, you are not technical and you do not want SQL. Use Search Console Tools or a comparable third-party. The data archive is the value; the visualization is a bonus.

You are an agency with ten or more client properties. Use BigQuery for everything. The unit cost stays low even at scale, and you maintain a single warehouse you fully own. Layer in a tool like Search Console Tools or Looker Studio on top for the client-facing reports.

You already lost data and you need it back. You cannot get it. Nobody can. Google does not maintain backups you can request, the Internet Archive does not capture per-property GSC data, and third-party tools only have what they collected at the time. The honest answer is that the data is gone, and the only move is to never let it happen again starting today.


What Lives Beyond the 16 Month Wall (Hidden Survivors)

A short list of GSC artifacts that are not affected by the 16 month cap, in case you have been assuming you lost them.

Sitemap submission history. GSC keeps the full history of when each sitemap was submitted, last read, and the status, going back to property creation.

Manual action history. Manual actions levied against your site, and the dates they were resolved, persist indefinitely in the Security & Manual Actions report. This is critical evidence in a penalty post-mortem.

Security issue history. Same as manual actions, security issues stay visible even after they have been resolved years ago.

Property settings and verification history. Owner adds and removes are timestamped and visible permanently.

URL Inspection cache. The last successful crawl of any URL is visible in the URL Inspection tool regardless of when it was crawled, though the snapshot itself updates as Google recrawls.

The Performance report is the one that bleeds. Almost everything else GSC keeps forever.


How to Set Up BigQuery Export in 30 Minutes (Step by Step)

Since BigQuery is the most durable free option, here is the exact setup. Run this today if you do nothing else from this article.

  1. Open Google Cloud Console. Create a new project or use an existing one. Note the project ID.
  2. Enable BigQuery on the project. Search for BigQuery API in the marketplace and enable it.
  3. Create a BigQuery dataset. Name it something like search_console_archive. Pick a region close to you.
  4. Grant GSC write access. In IAM, add the service account search-console-data-export@system.gserviceaccount.com with the BigQuery Data Editor and BigQuery Job User roles on your project.
  5. Open Google Search Console settings. Property dropdown → Settings → Bulk data export.
  6. Configure the export. Enter the GCP project ID, the dataset name, and the region. Click Continue and confirm.
  7. Wait 48 hours. The first daily table lands within 48 hours. From then on, a new daily table is written every morning automatically.

After 30 days you will have 30 daily tables. After a year, 365 tables. After three years, more than a thousand daily snapshots that you can query however you want, long after the 16 month wall has rolled past them.

If 30 minutes of setup buys you forever, do it.


Frequently Asked Questions

Why does Google Search Console only show 16 months of data?

Google has not published a formal reason. The three widely understood drivers are storage cost at scale, the fact that older SERP behavior is often no longer relevant to current search intent, and a deliberate push to move power users toward durable storage they own themselves via the API and BigQuery export. Whatever the reason, it has been 16 months since 2018 and there is no signal that Google will extend it.

Can I recover Google Search Console data older than 16 months?

No. Once data has rolled past the 16 month window, it is permanently removed from both the GSC UI and the GSC API. There is no way to request it from Google, no backup endpoint, and no third-party that has comprehensive historical data unless they were already archiving your specific property before the data aged out. The only durable fix is to start your own archive today so the same loss does not happen next year.

Is the 16 month limit the same in the GSC API?

Yes. The Search Analytics API enforces the same 16 month retention window as the UI. Asking for a date range older than 16 months returns an empty result, not the older data. The API is more generous than the UI on row count (returning up to 25,000 rows per query versus 1,000 in the UI) but it is identical on date range.

Does the BigQuery bulk export include data from before I turned it on?

No. The BigQuery export only writes data from the day you enable it forward. It cannot backfill any prior history. This is why the most expensive mistake with GSC retention is procrastinating on the export setup. The cost of turning it on today is roughly 30 minutes. The cost of waiting six months is six months of data you will never see again.

What is the difference between the 16 month limit and the 1000 row limit?

The 1,000 row limit is a per-table display cap that hides queries and pages beyond the top 1,000 by clicks. The 16 month limit is a date-range retention cap that removes all data older than 16 months. They are independent. A small site might never hit the 1,000 row cap but will absolutely hit the 16 month cap if it runs for more than 16 months.

Does Google Analytics keep Search Console data longer than 16 months?

No. The integration between GA4 and Search Console only surfaces what GSC has already published, so GA4 inherits the same 16 month wall. You will see the GSC-sourced Search Console reports in GA4 cut off at exactly the same date. If you want history past 16 months, you have to archive from the GSC side, not the GA4 side.

Do other search engines have a similar retention limit?

Bing Webmaster Tools currently retains 16 months as well, mirroring Google. Yandex Webmaster keeps roughly 12 months. Naver, Baidu, and DuckDuckGo do not publish a comparable Performance dashboard at all. If you care about long-tail historical search data, the archive problem is universal and the BigQuery-or-equivalent answer is universal too.


The Two Things to Do This Week

Stop reading and do these two things before the end of the week.

Today: turn on the BigQuery export. Even if you do not know SQL yet. Even if you do not have a use case for the data yet. The cost is 30 minutes. Every day you wait is a day of data you will lose 16 months from now.

This week: pick a long-memory tool. Whether it is Search Console Tools, a competing SaaS, or a Looker Studio dashboard on top of your BigQuery export, get a layer that surfaces multi-year history in a way you will actually look at. The export is the archive; the tool is the eyes.

Sixteen months is shorter than you think. Set the floor today, and a year from now you will have data nobody else on your team has access to.

2026 Standard

Run a Free AI Citation Audit

Are you in the AI Overview? Get a free report showing how often ChatGPT, Claude, and Gemini cite your brand, plus the 3 blockers preventing your discovery in 2026.

No spam. 1-click unsubscribe. Join 1,200+ SEO teams managing the GEO pivot.

Put These Tips Into Action

Connect your Google Search Console and let our AI find your biggest opportunities.

Get Started Free