Google Search Console deletes your performance data after 16 months, and nothing you do in the GSC interface can stop it. Every month, the oldest month of clicks, impressions and queries quietly drops off the end of the window, and with it goes your ability to do a real year-over-year comparison or to see what a site looked like before a core update two years ago.
The Search Console Data Warehouse from GEO Search Console fixes this with a small, free, self-hosted PHP app. You upload about 20 plain PHP, CSS and JS files to any PHP 8 host with cron support, point it at the Search Console API, and it pulls your data every day into a database on your own server. The first runs backfill the full 16 months Google still has; after that, nothing falls off ever again.
This post walks through what the tool does, how it compares to the usual ways of getting data out of GSC, and how to set it up in about 15 minutes.
How to Export Translated Results GSC
“Translated results” is one of the search appearance types Google reports in the Performance report. To export it from the GSC interface, open Performance, click Search appearance, select Translated results, then use the Export button in the top right to download a CSV, Excel file or Google Sheet. That works, but it carries the same limits as every other UI export: at most 1,000 rows per table, and only the last 16 months.
If translated traffic matters to your site, the more important question is whether you will still be able to see that history in two years. The Search Console Data Warehouse stores daily totals, query and page pairs, pages alone, and country and device pairs for every property you connect, and keeps them permanently. It does not break the data out by search appearance, so for the appearance-specific view you still use the GSC interface. For everything else, the warehouse gives you the full picture, with no row cap and no expiry date, and every view exports as CSV or JSON.
GSC Export
The standard GSC export is a snapshot. You pick a date range, click Export, and get what the interface was showing at that moment. It is fine for a quick look, but it has three problems if you are trying to build a lasting record of your search performance.
- Row caps. Tables and exports in the UI stop at roughly 1,000 rows, so a site with 30,000 ranking queries only ever sees the top slice.
- The 16-month wall. You can only export what Google still holds. Anything older is gone, and a manual monthly export routine is one forgotten reminder away from a permanent gap.
- Revised numbers. Google adjusts the last few days of data after the fact, so an export taken too soon locks in figures that later change.
The warehouse replaces the manual export with a daily cron job that calls the Search Console API. It stores every new day, re-fetches recent days until Google has finished revising them, and pulls query and page pairs up to the API’s 50,000-row limit rather than the UI’s 1,000. The result is a complete, continuously updated export that lives on your server rather than in a folder of dated spreadsheets.
GSC Bulk Export
Google’s own answer to the retention problem is the BigQuery bulk data export. It streams your daily Search Console data into a BigQuery dataset in your Google Cloud project, with no row limits. It is a solid option for teams already working in Google Cloud, but it has one gap the warehouse was built to fill: it has no backfill. BigQuery starts collecting on the day you switch it on, so the 16 months you already have in Search Console never make it in.
| Aspect | Search Console Data Warehouse | BigQuery bulk export |
|---|---|---|
| Historical backfill | Full 16 months on the first runs | None, starts the day you enable it |
| Data location | Your own hosting | Your Google Cloud project |
| Cost | Free on hosting you already pay for | Storage and query charges past the free tier |
| Interface | Built-in viewer plus CSV and JSON export | SQL or an external dashboard |
| Skills needed | None beyond uploading files and setting a cron job | SQL and Google Cloud setup |
The two are not mutually exclusive. A sensible sequence is to install the warehouse today so the existing 16 months are captured before any more of it expires, then enable the BigQuery export if your analysts already live there.
What Is GSC Data?
GSC data is Google’s own record of how your site performed in search: every query that showed one of your pages, how often it was shown, how often it was clicked, and where on the page it ranked. The four core metrics are clicks, impressions, click-through rate and average position. Google breaks these down by query, page, country, device, date and search appearance, and reports them separately for web search, Discover and Google News.
It is the only first-party view of organic search you will ever get. Third-party rank trackers estimate; GSC measures. That is also why losing it after 16 months hurts. A ranking tool can tell you where you sit today, but only GSC can tell you what your actual traffic looked like before and after a specific Google update, and only if you still have the data.
GSC Data
The warehouse stores four tables per property, chosen to cover the questions people actually ask of GSC data.
| Table | What it holds | Why it matters |
|---|---|---|
| Daily totals | Clicks, impressions, CTR and average position per day | The trend line, and the baseline for every comparison |
| Query + page pairs | Each query matched to the page it ranked, up to 50,000 rows | Cannibalization, striking-distance and winners/losers analysis |
| Pages alone | Per-page totals independent of query | Captures traffic from anonymized queries the query table never sees |
| Country + device pairs | Performance split by country and device type | Market and mobile versus desktop analysis |
Discover and Google News are stored at the page and country level only, because that is all Google’s API returns for them.
Two honest limits apply. Google withholds fully anonymized queries from the query table, so they appear in totals and page data but never as rows you can read. And the API returns country and device as separate dimensions, so you cannot ask for a single query’s performance in Germany on mobile. The warehouse can only keep what Google hands over, but it keeps all of it, and it keeps it forever.
GSC Data to Excel
Most SEO analysis still ends up in a spreadsheet, and the warehouse is built with that in mind. Any view in the password-protected viewer can be exported in full as CSV, which opens directly in Excel. “In full” is the key phrase: you get every row the view contains, not the first 1,000.
The views you can export include:
- Any custom date range, including ranges older than 16 months
- Regex include and exclude filters on queries and pages, so you can pull just the product queries or just the blog section
- Period comparisons against the previous period or the same period last year, with the change calculated on every row
- Winners and losers sorted by change in clicks, impressions or position, including queries that disappeared entirely
- Striking-distance queries in any position band you choose, such as positions 8 to 20
- Cannibalization, where several of your pages compete for the same query
- Brand versus non-brand, once you define your brand patterns
Because the filtering, comparison and sorting happen in the viewer before you export, you spend less time building pivot tables in Excel and more time reading the result.
Access More Hidden GSC Data
There is a lot of GSC data you never see in the interface. Some of it is hidden by the 1,000-row cap, some by the 16-month window, and some by the way the UI aggregates. The warehouse surfaces all three kinds.
Beyond 1,000 rows. The Search Console API allows up to 50,000 rows per request, and the warehouse uses that limit for query and page pairs. On a mid-sized site, that is the difference between seeing 3% of your queries and seeing nearly all of them.
Beyond 16 months. Once the backfill has run, the viewer lets you pick any stored date range. Year-over-year becomes a real comparison rather than a guess, and you can line up traffic before and after any update. The chart overlays mark core updates, spam updates, the AI Overviews launches and the September 2025 impressions change, and you can add your own markers for site migrations or redesigns.
Beyond the query table. Google strips anonymized queries from the query report but still counts them in page totals. By storing pages alone as a separate table, the warehouse captures that traffic rather than letting it vanish into the gap between tables.
For anyone who prefers asking questions to building filters, the optional MCP server exposes the stored data as read-only tools, so you can connect Claude (Code, web, desktop or any other MCP client) and ask in plain English which pages lost the most clicks since the last core update.
GSC Data to Google Sheets
Getting warehouse data into Google Sheets is the same CSV export, imported with File → Import or dragged onto a sheet. For a recurring report, the JSON export is often the better route: a small Apps Script or a scheduled fetch can pull a saved view’s JSON and write it to a tab, so the sheet refreshes itself without anyone logging in to GSC.
The practical advantage over the native GSC to Sheets export is the same throughout this post. The native export gives you a capped snapshot of a rolling window. The warehouse gives you a complete, filtered, pre-compared dataset from a history that never shrinks, and because it supports several properties in one install, an agency can feed one client dashboard per tab from a single source.
Setting It Up
Setup takes roughly 15 minutes on ordinary shared hosting with PHP 8 and cron jobs, which covers most cPanel plans.
- Upload the ZIP (about 20 files) to your host.
- Set a password for the web viewer.
- Create a free Google Cloud service account and enable the Search Console API.
- Add the service account as a Restricted user on each property you want to store.
- Add the suggested cron job and let the first runs backfill the 16 months.
Data is stored in SQLite by default, with MySQL available for very large sites. The code is open, so you can read exactly what it does, and nothing leaves your server: there is no account with the tool’s makers and no third-party service in the loop. The one thing it cannot do is recover data Google has already deleted, which is the strongest argument for installing it this week rather than next quarter. The makers also offer a monthly email or calendar reminder telling you which month is about to fall off Google’s window, in case you want a nudge.
If you have ever wished you could see what your site looked like in search two years ago, this is the cheapest and simplest way to make sure you can answer that question two years from now.
