How long are your Search Console data truly accessible?

Why does this 16-month limit exist?

Google does not publicly justify this 16-month retention window, but it likely stems from a technical trade-off between storage costs and user needs. For a search engine handling billions of queries daily, retaining detailed histories for every registered property represents a colossal volume of data.

This duration, however, allows for analyzing complete annual trends and comparing two identical seasonal periods — a vital minimum for identifying recurring patterns. But it blocks any multi-year analysis without prior exports.

When exactly does the countdown start?

The countdown begins the moment you register your property in Search Console, not when Google discovers the site. In other words, a site launched in 2018 but added to Search Console only now will not have any historical data prior to its registration.

Data accumulates gradually. A site added today will only have a few days of data tomorrow, then a few weeks, until it reaches the ceiling of 16 months. After this period, the data slips: the oldest records disappear as new ones arrive.

What happens to the data after 16 months?

It is permanently deleted. No accessible archiving, no recovery possible. If you haven't exported your reports before this deadline, you lose all trace of these periods.

• Data disappears in a sliding manner: every day, records older than 16 months are erased
• No way to recover deleted data, even by contacting Google support
• The Search Console API adheres to the same time limit as the web interface
• Custom filters and segments do not allow bypassing this window
• Deleting and then re-adding a property does not reset the lost history

Does this limit pose real problems in practice?

Yes, and not just a little. For any site with a marked seasonality or subject to long cycles (real estate, tourism, recruitment), 16 months are often not enough to identify robust trends. Comparing three consecutive years of summer traffic? Impossible without prior exports.

The window becomes quite limiting for sites that have undergone major technical changes (redesign, HTTPS migration, domain change). Analyzing the long-term impact of an algorithm penalty or correction often requires a hindsight of 18-24 months. With Search Console alone, this perspective disappears.

Practically? Professionals managing sites over several years must systematically export their data or use third-party tools (SEMrush, Ahrefs, Sistrix) that store histories. [To be verified]: some tools claim to retain more than 16 months through their own crawl, but their granularity never matches Search Console for actual queries.

Could Google extend this retention period?

Technically, yes. Financially, it’s debatable. But there’s nothing to indicate that Google is considering extending this window. The company has never communicated on this point, and the limit has remained stable for years.

The most likely scenario? Google considers 16 months sufficient for the majority of use cases. If you need more, it’s up to you to implement your own storage solutions. A pragmatic stance from Google, frustrating for users.

How does this rule apply to different types of properties?

The 16-month limit applies uniformly: domain properties, URL prefixes, AMP sites, all treated the same. No preferential treatment for large sites or long-verified accounts.

A classic trap: some believe that by combining several types of properties (domain + subdomain + prefix), they extend their history. False. Each property has its own 16-month countdown, but none retains more than this duration.

What should you implement right now?

The first urgency: automate the regular export of your Search Console data before it disappears. The Search Console API allows you to retrieve performance reports and store them in your own databases or spreadsheets.

For critical sites, set up a monthly script that extracts and archives data on clicks, impressions, CTR, and positions. Google Sheets with Apps Script does the job for modest volumes. For larger sites, a SQL database or BigQuery becomes necessary.

What mistakes should you absolutely avoid?

Don’t rely on sporadic manual exports. You’ll forget; it’s inevitable. And when you realize you need 18-month-old data to analyze the impact of a Google update, it will be too late.

Another trap: believing Google Analytics compensates. GA and Search Console do not measure the same things. Search Console captures pre-click queries, impressions, average positions — metrics not found in Analytics. The two tools are complementary, not interchangeable.

Finally, never delete a Search Console property on a whim to “clean up.” You permanently lose history, and Google allows no recovery.

How can you verify that your exports are working correctly?

Test your export process over a short period before letting it run autonomously. Check that the extracted data matches the numbers displayed in the Search Console interface — minor discrepancies are normal (sampling), but significant divergences indicate a script problem.

Plan alerts if the export fails. A simple automatic email when the script doesn't run can save you from irreversible losses.

• Set up an automated monthly export via the Search Console API or a third-party tool
• Store the data in a secure and sustainable space (cloud, SQL database, BigQuery)
• Document your exports to easily locate historical data
• Test the consistency of exported data with the Search Console interface
• Never delete a property without having saved the complete history
• Prepare an alert system in case of export failures
• Maintain a minimum of 3 years of history for robust analyses