Search Console deletes your data after 16 months

How long Google Search Console keeps data, and what disappears exactly

The short answer to how long Google Search Console keeps data is 16 months. The useful answer is how those 16 months behave, because almost everyone pictures them wrong. It is not an archive that grows until it hits a ceiling. It is a rolling window: as one day enters at one end, the oldest one drops off the other. The Search Console 16-month limit never arrives as an event — there is no email, no notice in the panel, no red banner. One day you open the report calendar and the date you needed simply cannot be selected anymore.

Put numbers on it. If you are reading this in August 2026, the furthest day the Performance report will let you query sits somewhere around April 2025. By March 2027, everything before November 2025 will be gone. And if at that point you want to compare the launch of a project that started in January 2025 against where it stands now, you will not be able to: that data no longer exists for you. The only version left will be the one you saved yourself.

There is a wrinkle that makes it slightly worse than it sounds. The window is not the same across every report in the tool, and plenty of people assume the rest of the sections hold the same amount of history. They do not.

One more detail that reframes everything above: Search Console is not retroactive at the start either. The day you verify a new property, the tool begins recording from that moment; it does not hand you the preceding months even if the site had existed for years. In other words, Google’s history has two hard borders, one at the beginning and one at the end, and neither of them moves.

On top of that sits the omission of low-volume queries for privacy reasons, which already affects what you see inside the window. That is a separate limitation from retention, but keep it in mind when you export: what you save is what Search Console shows you, not everything that happened. If you want the full map of what the tool tells you and what it does not, start with the guide to connecting Search Console to a rank tracker, and if you want to see what can be measured continuously without depending on that window, it is summarized in the Rankiamos feature breakdown.

Why the 16-month limit exists: a usefulness window and a privacy one

It is worth understanding the logic, if only to stop waiting for Google to change it. And it helps to remember where we came from: until 2018, the tool kept 90 days. Ninety. It would not even let you compare two consecutive quarters. The jump to 16 months was a large improvement at the time, and it reads as a shortfall today only because expectations about what we should be able to measure have risen.

Why 16 and not 12 or 24? The explanation Google itself has given is analytical usefulness: with 16 months you can compare the current month against the same month a year earlier and still have four months of context around it to judge whether that comparison means anything. A flat twelve months would not do it — last year’s equivalent month would sit exactly on the edge of the window, with nothing before or after it — and 24 would multiply the stored volume for a small share of users who actually query that far back.

The second reason is cost and privacy, and it gets mentioned far less. Search Console processes search query data for millions of properties. That detail is sensitive: these are terms typed by people, aggregated and filtered, but sensitive nonetheless. Keeping them indefinitely for everyone carries an infrastructure cost and a risk surface that both grow without a ceiling. Limited GSC data retention is, in part, a risk-reduction policy. The same logic explains why very low-volume queries are dropped from the report entirely: protecting the identifiability of whoever searched.

The practical conclusion is unwelcome but clear. There will be no paid tier that extends the period, because Search Console has no tiers. There is no hidden “keep longer” toggle in settings. The only lever that exists is yours, and it consists of getting the data out before it expires or building your own parallel series.

There is a business reading that helps you decide, too. Sixteen months is enough to operate: to know whether last month beat the one before, whether a change worked, whether a query collapsed. It is not enough to argue: to show a client or a manager that two years of work moved the needle, or to explain why a project that started in 2024 sits where it does today. Operating and arguing need different windows, and Google only covers the first.

Exporting Search Console data by hand: the row cap and the remembering problem

The most obvious way to preserve your Search Console historical data is the one already sitting in the interface: the export button in the Performance report. It works, it is free and it needs no special permissions. It has two problems, one technical and one human, and the human one is worse.

The technical one is the row cap. When you export Search Console data from the panel you get up to 1,000 rows of whatever table is on screen. For a blog with 300 queries a month that is the entire dataset; for a store with tens of thousands, it is the tip of the iceberg. The way to stretch it is not to ask for more rows, because you cannot: it is to slice the export. The cap applies to each request, so if you segment by country and export six times, you walk away with up to six thousand rows instead of one thousand. The same trick works with device, with search type, and with URL folders using the page filter.

Here is the monthly routine I recommend to anyone who does not want to build anything technical. It takes twenty to thirty minutes a month and, executed with discipline, solves ninety percent of the problem.

1. Step 1 · Rescue everything still inside the window

   Before you think about the routine, run a rescue export. Set the range to the full 16 months and download the Queries and Pages tables. This is the only part of the past you can still save; starting tomorrow, it is one day shorter. If you have never exported anything, this step is the single most valuable line in this post.

2. Step 2 · Pick the same day every month and put it in the calendar

   The 5th works well: the previous month has closed and the two-to-three-day reporting lag has cleared. Create the recurring event now, not “when there is time”. A backup system that depends on you remembering is not a system.

3. Step 3 · Export the closed month, table by table

   Custom range from the 1st to the last day of the previous month. Download the Queries table and then the Pages table as separate files. If your traffic comes from several countries, export the Countries table too: that is the cut you will want later to read your evolution market by market.

4. Step 4 · Slice it if you hit 1,000 rows

   Check whether the table landed on exactly 1,000 rows: if it did, you are almost certainly losing long tail. Repeat the export filtered by country, by device or by URL folder. Each filter is a fresh request with its own cap, which is how you recover what fell below the cut.

5. Step 5 · Name files so alphabetical order is chronological

   Use site_2026-07_queries.csv. Leading with the year and a two-digit month makes the folder sort itself. It sounds trivial until you have 40 files and need to find last May in the middle of a client call.

6. Step 6 · Consolidate into one master sheet each quarter

   Loose CSVs are a backup, not a queryable history. Once a quarter, append the months into a single sheet with a period column. That turns a folder of files into something you can chart and filter, which is why you saved the data in the first place.

A note on what to export: if you are not after the full dump but specific families of queries — brand versus non-brand, questions, country variants — the regular expression filter lets you isolate them before downloading, so each export arrives pre-organized. That syntax is covered separately in the Search Console regex guide.

Search Console API and BigQuery: what they solve and what they really cost

If volume or consistency is your bottleneck, there are two automated routes. Both are legitimate, and both carry fine print that rarely gets mentioned by the people recommending them.

The Search Console API

The Search Analytics API returns up to 25,000 rows per request and lets you paginate through the rest, so the practical ceiling stops being an issue. You can request data day by day, crossed with query, page, country and device, and dump it wherever you like: a spreadsheet, a database, a flat file. A fifty-line script running once a day solves the consistency problem better than any calendar reminder ever will.

The fine print: the API respects exactly the same 16-month boundary. It gives you more width, not more past. Ask it for data from two years ago and it returns the same thing the interface does — nothing. And the real cost is not the API, which is free: it is that somebody has to set up OAuth, keep the script alive, fix it when something changes and remember it exists. On a team with technical staff that is half an afternoon; for a freelancer who does not code, it is a genuine barrier.

The bulk export to BigQuery

This is Google’s own answer to the retention problem and the most complete option: you connect Search Console to a Google Cloud project and from then on the tool streams your daily data into BigQuery automatically, with more granularity than the interface ever shows and with no 1,000-row cap. Once it is there, the data is yours — it lives under your retention rules and nobody erases it at 16 months.

The fine print, and this is the most important sentence in the post: the bulk export is not retroactive. It starts copying data the day you enable it and moves forward from there. It does not take a copy of the 16 months already in your account. If you wanted those months, they have to be exported another way first, and anyone who enables BigQuery believing their history is now safe is in for an unpleasant surprise a year from now. It is the same principle that governs every accumulation system: only what you were recording at the time exists.

On price: Google does not charge for the export itself, but the data lands in your own Cloud project, where you pay storage and query rates according to current BigQuery pricing. A small site usually stays inside or near the free tier; a large site with frequent queries will not. Google Cloud pricing changes, so check it before assuming this is free, and note that you need an active billing account even when consumption is minimal.

Look at the right-hand column, because it is what orders the decision. The first two methods rescue the past and the last two do not. That means they are not alternatives to each other: the correct move is to run a rescue export today — via the interface or the API — and switch on at least one forward-accumulating method. Picking only one side always leaves you with half the problem solved.

There is an asymmetry worth accepting early. Everything you can do about the past is decided today and runs out fast: you export what is left inside the window and that is the end of it. Everything you can do about the future has no ceiling but requires starting. Your own SEO ranking history cannot be bought or recovered — it accumulates, and the only possible moment to begin accumulating it is now.

This is where being transparent about the product matters, because the same limitation applies. In Rankiamos, the history of a keyword begins the day you add it: it is not retroactive. If tomorrow you want to know where a keyword stood six months ago and you had not added it, the answer is that you will not know. Exactly the same rule as the BigQuery export. The difference between tools is not whether they can recover the past — none can — but how cheap it is to start recording it.

So the operational advice is to start with what you can actually sustain. These are the four decisions that define your future series, and each is made only once.

One note for anyone running multi-country SEO, because it raises the urgency. If your site competes across several markets at once, the 16-month limit hurts more: what gets erased is not one series but ten, one per market. And since Search Console blends positions from all of those countries into a single average, reconstructing what happened in Colombia versus Mexico later will require the country-level cut you exported yourself. That blending of markets into one metric is unpacked in the post on why average position does not match your real ranking.

A rank tracker does not back up your GSC: it stores a different series (and why that matters)

Here is the distinction almost nobody draws, and the reason this post exists. A rank tracker is not a Search Console backup. It does not copy your clicks, it does not copy your impressions and it does not reconstruct your CTR. It stores a different series, measured differently, answering a different question. Selling it as a backup would be a lie, and the user would find out on their own within six months.

The difference is easiest to see by looking at where each number comes from. Search Console records what happened when real people searched: if nobody searched your keyword on Tuesday, there is no Tuesday. A tracker queries the SERP in a defined context and returns the position at that moment, whether or not any real searches occurred. That is why one series has holes and the other does not, and why the two numbers never fully agree.

Why the distinction matters in practice. If your goal is to preserve historical clicks and impressions — to calculate seasonality, model traffic, or justify an investment with business numbers — the tracker will not help and you need to export from Search Console. If your goal is to answer “where were we ranked and where are we now?” across years, the tracker is the right tool and Search Console is going to fall short by definition.

What a tracker does solve is the problem the rolling window creates: memory loss. Its series does not expire at 16 months because it does not depend on Google’s retention policy, which turns an impossible question into one you can answer. In exchange, it only covers the keywords you added, while Search Console covers all of them, including the ones you never thought of. Those are complementary strengths, not competing ones.

And there is one case where the two series together are worth more than the sum: verifying that a change worked. Search Console confirms that impressions moved; the tracker tells you which exact day the position shifted. That cross-check is the backbone of, for example, confirming a URL merge in the guide to detecting keyword cannibalization with Search Console.

The client question GSC cannot answer: where were we two years ago?

All of the above stays abstract until the meeting happens. The client has been paying you for two years, the brand grew, the team changed, and at some point somebody asks: “where were we when we started?” It is a reasonable question, it is the question that justifies your contract, and Search Console alone has no answer for it.

Twenty-four months is more than sixteen. The month the project launched fell out of the window eight months ago. What you can show is the last year and a half, which is probably the least impressive stretch of the journey: the phase where things already worked. The exact segment where the jump is visible — the messy start, the first keyword that broke into the top 10 — is the one that no longer exists.

The honest ways out of that moment are three, and none is good. The first is admitting you do not have the data, which is correct and uncomfortable. The second is reconstructing it from whatever survived: old screenshots, a PDF report you sent at the time, an email with figures. It half works and does not survive a follow-up question. The third is telling it from memory, which is the worst because it sounds like an excuse even when it is true.

The version of that same meeting with your own series is different. You arrive with the starting point on record, and the conversation stops being about whether the work paid off. That is the entire value of having started to accumulate: not a pretty chart, but never having to defend yourself without evidence. One caveat on how you show it: the history lives in the app, and each keyword’s chart shows its last 180 measurements, so with daily checks month one is no longer on the chart two years later. On Pro you can export a PDF of current positions under your name and color, or a plain CSV — a snapshot, not the history. If you measure daily, export that snapshot in month one and keep the file: it is the baseline you will show.

If you are kicking off a new project this week, the moment to add the keywords is before you touch anything on the site. Three minutes now buys the baseline that, two years from now, carries the whole meeting. And if the project has been running for a while, the play is a double one: export today the 16 months you still have in Search Console, and start your own parallel series the same day. What gets measured continuously, and what each plan costs, is laid out in the product feature detail and on the pricing page.