Google Search Console data retention: the 16-month wall

Google Search Console keeps the last 16 months of performance data and no more. Every day you gain a new day at the front and lose one off the back, so the window slides forward but never grows. Once a day passes the 16-month line, Google deletes it, and no setting, export, or API brings it back.

That makes the data you rely on most, your page-level clicks, impressions, and position, the most perishable thing in your account. It expires from the back as the wall moves, and at the front it is not even final yet for a day or two. Reading Search Console honestly means treating its numbers as a moving record you have to capture, not a permanent archive you can query whenever.

TL;DR:

• Search Console keeps 16 months of data, then deletes the oldest day each day. The window rolls forward; it never expands.
• The newest day or two is preliminary. Google says it "might change in the next few hours," so recent numbers read low until they settle.
• You cannot recover data older than 16 months. The BigQuery Bulk Data Export only collects from the day you set it up, with no historical backfill.
• The only fix is to store your own snapshots now. What you do not capture, you lose.

How long does Google Search Console keep data?

Sixteen months, on a rolling basis. Google states it plainly: "Search Console keeps data for the last 16 months." The default Performance view shows only the last three months, but you can widen the date range to the full window. Past that line there is nothing.

The mechanic is a sliding window, not a growing archive. Each day adds one fresh day at the front and drops the oldest day off the back, so you always have roughly 16 months and never more. That is enough to compare this June against last June, but the June before that is already gone. Year-over-year is the deepest comparison the tool will ever hand you, and only by a margin of a few months.

Why does Search Console delete data after 16 months?

Google has never published an official reason, so treat the 16-month wall as a fixed property of the tool, not a setting you can change or a quota you can raise. It is the same for every property, with no paid tier that extends it. The practical point outweighs the rationale: the limit is real, permanent, and yours to work around.

Speculating about storage costs or privacy regulation is a waste of time, because none of it changes what you can do. The window is what it is. The only variable you control is whether you start keeping your own copy before the data you care about slides off the back.

How fresh is Search Console data?

Not as fresh as it looks. The newest numbers are preliminary. In Google's own wording, the most recent data "might change in the next few hours" because it is still being collected. In practice the last day or two of any report reads low and climbs as the data finalizes.

This is why a sudden "drop" at the right edge of your chart is usually not a drop at all. It is incomplete data that has not caught up yet. Search Console does offer a near-real-time 24-hour view for spotting fresh movement, but it runs on a separate, faster pipeline and even it is flagged as preliminary with a dotted line. Whichever view you read, the most recent slice is the least trustworthy.

Why the 16-month wall and the freshness lag are one problem

Because both make your most trusted number perishable. The freshness lag means today's total is not final yet. The 16-month wall means last year's total will not survive. The page-level figures you trust for volume and trends are the exact figures with an expiry date stamped on both ends of the timeline.

Most write-ups file retention and freshness as two unrelated footnotes. They are the same property seen from opposite ends: your data is provisional at the front and deleted at the back. And because the query view already under-counts by the hidden, anonymized portion, the page-level total is the one number worth preserving in the first place. So the discipline is not just "read the right view." It is "read the right view, then keep it," because the view you trust is the one Google is quietly erasing one day at a time. A report like 30 days of Search Console on a real SaaS is a snapshot of exactly that kind: numbers accurate the day they were read, and gone from Google's window in 16 months unless they are stored forward.

Can you recover Search Console data older than 16 months?

No. Once a day passes the 16-month line it is deleted and unrecoverable. There is no historical export, no premium tier, and no API call that reaches back. The closest thing to a long-term archive is the BigQuery Bulk Data Export, and it only starts collecting from the day you switch it on, with no backfill of the past.

That creates a hard asymmetry. Set the export up today and in three years you will have three years of history. Set it up today and it does nothing for the months that already aged out. The cost of starting late is not a delay you make up later; it is data that never exists. Whatever you have not been recording is already unrecoverable, which is the uncomfortable part of the 16-month wall that nobody mentions until they need a number from 17 months ago.

What should you do about the 16-month wall?

Start saving your own history today, because every day you wait is a day you can never get back. The fix is mechanical: snapshot the page-level numbers on a schedule and keep them somewhere you control, so your record outlives Google's window. A few habits follow:

• Capture page-level totals daily. The page view is the complete one for volume, so it is the right thing to archive.
• Set up the BigQuery Bulk Data Export, or a tool that snapshots for you, so the archive grows from now forward.
• Don't waste time hunting for data past 16 months. It does not exist anymore.
• Read the right edge of the chart as provisional, not as a drop. Wait a few days before reacting to the newest numbers.
• Decide now, not at month 15. The wall is already moving while you read this.

Reading Search Console without losing your history

Holding this line by hand is the tedious part: remembering to export, storing it somewhere durable, and reading page-level for volume while the window keeps sliding. It is easy to mean to set it up and never quite get to it, right up until the day you need the history you didn't keep.

That is the gap QueryScope is built to close. It stores a daily snapshot of your real Search Console data the moment you connect, precisely because the 16-month wall and the missing delta export mean the history is yours to lose. It reads volume from the page level, keeps the numbers past Google's window, and surfaces them in your IDE, not a browser tab. If you want the short definitions behind any of this, the Search Console glossary covers retention and data freshness, each with the caveat that matters.

Sources

• Google Analytics Help, Connect Search Console to Google Analytics ("Search Console keeps data for the last 16 months").
• Google Search Console Help, Performance report (Search results): Overview and basic setup (the newest data is preliminary and "might change in the next few hours"; default three-month view; near-real-time 24-hour view shown as preliminary).
• Google Search Console Help, About bulk data export of Search Console data to BigQuery (the export collects from the day you set it up, with no historical backfill).