Google deletes Search Console Performance data once a day is about 16 months old. Google documents that Search Console keeps data for the last 16 months. When a day ages out of that rolling window, it is gone from the UI and from the Search Analytics API, and Google support cannot restore it. Year-over-year in month 17 is a comparison against empty on Google's side. A CSV exported in a panic does not reconstruct days you never saved, and a reconnect later does not either.
SiteLine's job on connect is to copy whatever Google still holds that day, then keep every imported day for as long as the subscription continues. The copy is shorter than a tidy "16 months" slogan. Google's API guide says performance data is typically available after 2–3 days, and the Analytics help article that states the 16-month retention also says Search Console data is available 48 hours after Google collects it. The backfill is the overlap: about 16 months, minus that publish lag, and only if the property has been verified that long. Days Google has already dropped are not in the copy. Days Google has not published yet show up on a later refresh, not in the first snapshot.
That is the retention pitch. It is also the part most Search Console dashboards quietly fail. They chart whatever Google returns this week and call it history.
If you have not connected the property yet, the steps are in Connect Google Search Console to SiteLine. How Looker Studio, a CSV export, a DIY API warehouse, BigQuery bulk export, and a hosted archive differ is in best Search Console history tools.
When exactly does Google delete Search Console data?
Google does not publish a per-day countdown or send a warning. Take a closed calendar day D that already appears in Performance. It stays available until about D plus 16 calendar months, then every live reader returns empty for that date. Treat the boundary as a cliff, not a soft fade, and treat empty as missing data, not zero traffic. The free GSC data expiry calculator does this arithmetic for any day and lists which months of your current window fall out next.
| Fact | Detail |
|---|---|
| Window | Rolling, about 16 months of Performance data |
| What ages out | Clicks, impressions, CTR, position and the query, page, country and device breakdowns for that day |
| Where it disappears | The Search Console UI and the Search Analytics API, and anything that only reads them live, including Looker Studio's native connector |
| Publish lag | New days usually appear 2–3 days late, and recent days keep being revised |
| Recovery | None once Google drops the day |
| Young properties | A property verified four months ago never had sixteen months |
Illustration: if today is 6 October 2026, a Performance day from early June 2025 is near the edge of the window and a day from May 2025 is probably gone. Do not build a board deck that assumes May 2025 still loads from Google. The publish lag matters at the newest end of the window, not the oldest.
"Delete" here means Google stops serving the day. Your rankings that day were not affected; you lost the ledger. A few things are not on this clock: the Pages and indexing reports show current state rather than 16 months of history, the sitemaps list is configuration, and BigQuery bulk export tables belong to your own dataset once a day lands there (retention is then your Cloud policy, though it cannot resurrect days that never exported).
People say "history" and mean four different things: the live window Google still serves, a forward archive stored from the day you enable it, a backfill archive copied on connect day, and a recovered past. Nobody honestly sells the last one. A vendor that promises to restore deleted Search Console days is wrong. One that copies what Google still holds under a retention policy is a real product.
What the Performance window actually contains
The Performance report is the report people mean when they say "Search Console history." The chart is property-level totals for the range you picked: clicks, impressions, CTR (clicks divided by impressions), and average position of the topmost result from the property. The table under it groups the same period by one dimension. Chart and table are allowed to disagree. Google cites aggregation (property versus page) as one reason. Truncation and anonymised queries are others, covered in the 1,000-row limit.
The date filter in that report is not an open calendar. Google's Analytics integration article states the constraint in one sentence: "Search Console keeps data for the last 16 months." The same article says the data shows up in Search Console and in Analytics 48 hours after collection. The Search Analytics how-to allows a third day: data is typically available after 2–3 days, and the way to see the newest published day is to group a short range by date. Both describe that publish delay. The newest hours can also be preliminary, drawn as a dotted line on the Performance chart, and those points still move after they first appear.
A young property does not get 16 months of invented history. If verification happened four months ago, the API has about four months. SiteLine copies that. There is nothing behind it to fetch.
Search types stay separate inside the window. Web is the combined results tab. Image, video, and the News tab are their own series. Discover and Google News are feeds: no query, and position comes back null, not zero. A 16-month line that adds those types together will kink on the anniversary for reasons that have nothing to do with rankings. Read the types apart, the same way you would read clicks against analytics sessions apart.
A worked calendar, as a window illustration
This is calendar arithmetic for a 16-month window. It is not a log from a connected property, and Google does not publish the cutoff as a timestamp you can pin to the minute. Use it to see which side of a year-over-year comparison goes empty.
Take a connect date of 26 September 2026.
| Question | Date | Where it sits |
|---|---|---|
| Connect date | 26 September 2026 | The day you ask Google what it still holds |
| 16 calendar months earlier | 26 May 2025 | The far edge of "the last 16 months" |
| One day older than that edge | 25 May 2025 | Outside the window. A comparison that needs this day is empty on Google's side |
| Prior-year week for a May anniversary | 18–24 May 2025 | Also outside on 26 September 2026. This is month 17 |
| The matching week a year later | 18–24 May 2026 | Still inside. The current side of the comparison exists |
| Newest day if the lag is 3 days | 23 September 2026 | Inside the 16 months, and about as new as a backfill can be |
| Newest day if the lag is 2 days | 24 September 2026 | Same idea, one day newer |
| The connect date itself | 26 September 2026 | Inside the 16 months, and not published yet |
Count the empty side explicitly. From 24 May 2025 to 24 September 2026 is 16 calendar months. 26 September 2026 is two days past that. The week of 18–24 May 2025 is older than 16 months on the connect date, so Google no longer serves it. The week of 18–24 May 2026 is four months old, so Google still serves it. Year-over-year for that week is a real current week beside an empty prior week. The hole is on Google's side. Averaging the two, or treating the missing prior week as zero clicks, reports a fabricated collapse. How to compare that week without treating the hole as zero is in year-over-year in Search Console.
The unpublished tail is a different hole, and it closes. If you connect on 26 September 2026 and the lag is three days, 24–26 September are not in the snapshot because Google has not published them, not because they aged out. The next refreshes pick them up, then pick them up again, because Google revises recent days after first publish. The days before 26 May 2025 do not come back on those refreshes.
Now move the connect date earlier, which is the only way May 2025 survives. On 1 May 2026, 16 calendar months earlier is 1 January 2025. The week of 18–24 May 2025 is about eleven months old, still inside the window, so a backfill that day can copy it. SiteLine keeps that imported week while the subscription continues, including after Google later drops it. Cancel, let the paid period end, and reconnect on 26 September 2026: Google is asked again for whatever it still holds on 26 September 2026. May 2025 is not in that set. Reconnect does not restore it. The earlier copy is not re-fetched from Google, and it is not kept after the subscription ends.
That is the whole failure mode. The backfill is a photograph of the rolling window on connect day, shortened by the 2–3 day publish lag. Retention is the decision to keep the photograph, and every later day, while you subscribe. It is not a private channel back into Google's deleted days.
What connect copies, and what a later refresh adds
On connect, SiteLine requests the history Google will still return, up to that 16-month window, using the read-only scope webmasters.readonly. The scope cannot submit sitemaps, request indexing, or change users. It also cannot extend Google's retention. Read access copies rows. It does not negotiate a longer window.
Two request shapes matter, and mixing them up is how a "full history" import silently keeps one day.
Site totals are grouped by date. One row per day is small, so a 16-month totals request fits in a single call. Those totals are the headline series: clicks, impressions, and the position and CTR Google already computed for the property and search type. They are what you chart.
Breakdowns are not. A query, page, query-plus-page, country, device, or search-appearance report is imported one day at a time. Google's API applies its row cap to the response you asked for. If you ask for date and query across many days in one call, the cap cuts the whole response, which in practice keeps the first day and drops the rest without an error. SiteLine sets the start date equal to the end date on those jobs so the cap means "this report, this day," not "the entire backfill." The cap itself is 25,000 rows stored per day per report: one API page. The second page, which is how a caller would reach Google's 50,000-row ceiling, is not requested. The arithmetic, and why a 1,000-row UI export is a third and smaller cut, is in the 1,000-row limit. Daniel Waisberg's performance-data deep dive is the source for those row caps. This page is about the calendar.
After the backfill, each refresh re-imports the last 7 days. Google publishes late and then revises. A Monday that looks complete on Wednesday often gains clicks and impressions through the week. Finalized rows are what the Search Console website tends to show, about two days back. Fresh rows are the ones Google has published but not finished. SiteLine asks for fresh rows (dataState all) and upserts them on a composite key, every 4 hours. An importer that writes a day once will undercount that day forever. The 7-day window is the revision horizon, not a second copy of the 16 months.
If a site misses refreshes, the next run reaches back to the day after the stored history ends, still capped at the 16-month window. That fills a gap inside the window. It does not reach through the window into a month Google has dropped.
What you keep, and what reconnect will not put back
| System | What you can see on a given day | What is still there a year later |
|---|---|---|
| Search Console UI and API | About 16 months, minus the 2–3 day publish lag. The UI table export is 1,000 representative rows | The days that are still inside the rolling window. Older days are gone |
| A spreadsheet or warehouse you fill yourself | Whatever you remembered to pull, at whatever row cap you set | Whatever you remembered to pull |
| SiteLine | The backfill Google still held at connect, then each later day | Every imported day while the subscription continues |
Cancelling stops that retention at the end of the paid period. "While you subscribe" is the boundary. It is not "forever after you leave," and it is not "Google will still have it when you come back."
The practical consequence for reporting: a seasonal business that connects in March gets the 16 months still available in March, minus lag. It does not get the March it wishes it had from two years ago. If last March was already outside the window on connect day, no SiteLine chart, MCP call, or CSV will invent it. If last March was inside the window and the subscription stayed active, the imported March is still queryable after Google's own March has rolled off. That second case is the only year-over-year in month 17 that has a Search Console number on both sides, and the prior-year side is SiteLine's copy, not a live Google response.
Agents need the coverage dates for the same reason. MCP responses include data_from and data_through. A model that charts through today will read the publish lag as a collapse. MCP is the read path; the notes on each response are part of the data.
Why on-site analytics does not fill month 17
People notice the hole when they try to explain a seasonal business. Analytics may still have last year's visits. Those visits are not Search Console. They have no impressions, no position, and no query list. You can say the site was quieter in a given January if the tracker was installed then. You cannot say which queries lost position if nobody copied Search Console before Google deleted that January.
The two ledgers stay separate even when both exist. A click is a SERP click Google counted. A SiteLine visitor is a daily hash of a truncated IP (/24 for IPv4, /48 for IPv6), the user agent, and a daily salt. They measure different events, and the gap between them is not a Search Console day you can recover. Clicks versus sessions walks the causes. Organic traffic versus Search Console walks the channel-name version of the same mistake: an analytics "organic" bucket is not the Performance report.
Cookieless analytics also cannot be backfilled. The tracker only has days it was on the site. Connecting Search Console today does not reconstruct on-site history, and installing the script today does not reconstruct queries Google has dropped. Connect both when the property matters. Waiting until the month you want to compare has already aged out leaves you with one ledger and a speech about the other.
Anonymised queries make a further, smaller hole inside days you do have. Google omits queries that were not issued by more than a few dozen users over two to three months. Those clicks remain in the chart totals unless you filter by query. They will never appear as rows, in month 2 or in month 16. Summing a query table across a year and calling it "organic" drifts for that reason, and it also drifts if a huge property hits the 25,000-row page. Site totals do not have either problem. Headline a year from site totals. Use the query table to name the queries you can see.
Reporting rules that survive the window
Headlines from site totals. Dimension tables do not sum to the property. Say "of the queries we can see" when you are in the table. A year-over-year query report that sums visible rows will move as anonymisation and the row cap move, even when the property's demand did not.
Re-weight position. Divide clicks by impressions for CTR. Position on each row is already impression-weighted for that slice. An average of daily positions across 16 months treats a quiet Tuesday like a peak Monday. CTR is a ratio, stored by the API from 0 to 1 (0.04 is 4%), not a column to average. The Performance report's chart position is the property's, computed by Google. Use that, or recompute sum(position × impressions) / sum(impressions) on a set of rows you have named. Do not AVG the export.
Keep search types in their own series. Web versus Discover is not a ranking event. Discover and Google News have no query dimension. Their position is null. A spreadsheet export can turn a not-available mark into a numeric zero; that zero is not a rank. Leave it null.
Stop the range at published days. On a Wednesday, a complete comparison usually ends on Monday, sometimes Sunday, depending on the 2–3 day lag. Including today because the date picker allows it compares a full prior year with a stub.
Do not average a missing prior year into zero. If data_from starts after the comparison date, the prior period is empty. Report that the window does not contain it. A zero would mean Google counted no clicks, which is a different fact.
What you should do this week
If the property is already connected, leave it connected. The backfill you have is the one Google was willing to serve on the day you connected, plus every day imported since. Disconnecting to "clean up" and reconnecting later replaces that archive with a newer, shorter window.
If the property is only in Google's UI, an export is not a strategy. The UI download is truncated to 1,000 representative rows, and the totals in that file still include data the table does not show. The 16-month cap then deletes the file's source. Import through the API into something that keeps days. SiteLine is that copy, plus cookieless analytics on the same property, with MCP so an agent can read both and still see data_through.
Search Console import rows are not the analytics event quota. Plans start at $4.99, $19.99, and $99.99 a month. The tracker is a separate install: /docs/script. The connect flow starts at /register.
The 16-month limit is how Search Console is built. Plan the comparison around the days you actually copied, or lose the year.
FAQ
If I reconnect later, do I get the days I missed while cancelled?
You get whatever Google still holds at reconnect: about 16 months, minus the 2–3 day publish lag. Days older than that are not re-fetched. Days SiteLine imported for you and then dropped at the end of the paid period are not restored from Google either. Retention lasts while the subscription continues.
Why is my backfill shorter than 16 months?
Three ordinary reasons. The property was verified more recently than 16 months ago, so Google never stored the earlier days. The newest 2–3 days are not published yet, so the snapshot ends before today. Or you are looking at a breakdown that stopped at 25,000 rows for a heavy day, while the site-total series for that day is still complete. The first two shorten the calendar. The third shortens a table, not the headline.
Why re-import seven days if the data is already two days old?
Google publishes late and revises. A Monday imported on Wednesday is not the final Monday. Re-fetching the rolling week, every 4 hours, picks up clicks and impressions Google adds after first publish, including fresh rows that are not finalized yet. The Performance chart's dotted preliminary segment is the same phenomenon.
What if my property is only six months old?
You have about six months to copy. No tool invents the prior year Google never stored for that property.
Is Looker Studio enough to survive deletion?
No. Its native connector reads the same live window, so deleted days vanish from the charts too. See Looker Studio Search Console limits. Point Looker at a store you control if you want charts of retained days.
Does analytics history follow the same 16-month rule?
No. The 16-month window is Search Console's. SiteLine's cookieless analytics is stored on SiteLine for the days the tracker ran. Search Console days that were imported are also stored on SiteLine and kept while you subscribe, which is how month 17 can still have a Search Console number after Google has dropped the day. Analytics still cannot tell you the queries.
Can a CSV export stand in for the archive?
No. The download is capped at 1,000 representative rows, the file does not grow when Google revises the day, and sixteen months later Google will not give you the day again so you can re-export it. Export a working list if you need one. Keep the API copy if you need the month.
What does year-over-year look like in month 17 if I only use Google?
One side empty. In the calendar illustration above, on 26 September 2026 the week of 18–24 May 2026 still returns, and the week of 18–24 May 2025 does not. Plotting the missing week as zero reports a demand crash Google did not measure. State that the prior year is outside the documented window.
Will SiteLine invent queries for a day Google has dropped?
No. If the day was never imported, it is absent. If it was imported, you get the rows that were stored, up to 25,000 per report for that day, plus the site totals. Anonymised queries were never rows. Position for Discover and Google News stays null.