Ask a treatment center how its organic search traffic for “detox near me” compares with three years ago, and the honest answer is usually that nobody knows. Not because nobody looked, but because Google Search Console no longer has the data. The Performance report holds a rolling 16 months of history, and everything older falls off the end, one day at a time. If no one exported it, it is gone.
This is one of the least glamorous problems in search marketing, and a gap we regularly find when we take over an account. It costs nothing to fix going forward. It cannot be fixed backward.
The 16-month limit, in one paragraph
Google Search Console’s Performance report keeps 16 months of click, impression, CTR and position data for a website, a window Google introduced in its January 2018 Search Console launch announcement to make year-over-year comparison possible. Data older than 16 months is not archived anywhere you can reach; it is simply no longer available in the report or the API. The only way a site keeps a longer history is to copy the data out before it ages past the window, and Google’s own tool for doing that, the bulk data export to BigQuery, only collects data from the day it is switched on.
That last clause is the part most people miss. Turning on the export today does not recover last year.
Why behavioral health sites feel this more than most
Admissions demand in addiction and mental health treatment is seasonal and event-driven. Inquiries move with holidays, with insurance plan years, with local news. A 16-month window gives you exactly one comparison against the same month last year, and nothing to tell you whether last year was normal.
Three situations come up repeatedly in our audits:
- Agency transitions: a new agency inherits the property and can only see 16 months back, so any claim about what the previous agency “achieved” cannot be checked against a baseline from before they started. (If you are planning a switch, the access audit we recommend before changing agencies matters first; archiving data is pointless if you do not own the property.)
- Domain moves and rebrands: a move to a new domain starts a fresh property with no history. The old property keeps reporting for a while, then its data ages out too, and with it the only record of how the old site performed.
- Algorithm questions: when a core update lands and traffic shifts, the first question is “has this happened before?” Without archived data, that question cannot be answered.
What the Search Console interface actually lets you keep
Most teams assume the Export button is the archive. It is not a complete one, and Google’s documentation says why.
- Table row limit: the Performance report table displays a maximum of 1,000 rows, so long-tail queries and pages are left out of the table and therefore out of a standard export, even though they are counted in the chart totals.
- Anonymized queries: rare queries are omitted from the query table to protect user privacy, but are still included in chart totals unless a query filter is applied, which is why filtered totals rarely add up.
- Data truncation: Search Console stores and shows only the most important data rows; Google states that the most complete list of queries is available through bulk data export.
- API row cap: the Search Analytics API exposes a maximum of 50,000 rows of data per day per search type, returned in pages of up to 25,000 rows, and data is typically available after 2 to 3 days.
For a small treatment center, 1,000 rows of queries per export can look like plenty. In practice, the queries that matter most in this field are often the rare ones: a specific medication plus a city, a payer name plus “rehab,” a program type plus a neighborhood. Those are exactly the rows that drop out first.
The three ways to archive, ranked by what they preserve
1. Bulk data export to BigQuery. This is the only Google-supported method that captures everything Search Console has for the property, with the exception of anonymized queries. It writes two daily tables, searchdata_site_impression (aggregated by property) and searchdata_url_impression (aggregated by URL), with dates recorded in Pacific Time. According to Google’s setup instructions, the first export happens up to 48 hours after configuration, and the export includes only data from that day forward. For anything earlier, Google points you back to the API or the reports.
2. Scheduled API pulls. Google’s own guidance is to query one day of data at a time, every day, which stays within quota and captures up to the 50,000-row daily cap. This is what most reporting connectors do behind the scenes. It is also the only way to rescue the history you still have: an API backfill can reach back across the full 16 months today, and nothing older.
3. Monthly manual exports. Better than nothing, and the floor every site should meet. Export the Queries and Pages tabs by month, save them somewhere the organization owns, and name the files by date. You will lose the long tail, but you will keep the head terms and the trend lines.
What to do this week
If you have admin access to your Search Console property and a Google Cloud project with billing enabled, the setup is short. The steps, condensed from Google’s documentation:
- In Google Cloud Console, enable the BigQuery API and BigQuery Storage API for your project.
- Under IAM and Admin, grant the service account
search-console-data-export@system.gserviceaccount.comtwo roles: BigQuery Job User and BigQuery Data Editor. - In Search Console, open Settings, then Bulk data export, and enter the Cloud project ID (not the project number).
- Choose the dataset location carefully. Google notes it cannot easily be changed once exports have started.
- Once tables exist, set a partition expiration if you want to control storage costs, and keep it at 14 days or longer. Do not add columns to the tables; Google warns that schema changes cause the export to fail.
Then, the same day, run a one-time API backfill of the full 16 months still available, because the BigQuery export will not do it for you. After the first export lands, this query will confirm the archive is working and show you clicks by month:
SELECT
FORMAT_DATE('%Y-%m', data_date) AS month,
SUM(clicks) AS clicks,
SUM(impressions) AS impressions
FROM `your_project_id.searchconsole.searchdata_site_impression`
GROUP BY month
ORDER BY month;If the query returns rows, your history now outlives the 16-month window. If it returns nothing after 48 hours, check the export status in Search Console settings before assuming the data is missing.
A note on cost, ownership, and what not to send
BigQuery charges for storage and queries above a free usage level, and Google is explicit that exported data accumulates indefinitely unless you set an expiration. For most single-location and small multi-location treatment centers, Search Console data is modest in volume, but someone should own the billing account. Put the Cloud project under the organization’s own Google account, not an agency’s. An archive the agency owns is an archive you lose when the contract ends.
Search Console reports aggregated search data about your pages and queries, not individual visitors, so it does not raise the same questions as on-site analytics tags. That distinction does not carry over to everything else in your reporting stack. Google Analytics, for example, applies its own data retention settings: standard properties retain user-level data for explorations for either 2 months or 14 months, and the setting does not affect standard aggregated reports. If your exploration reports seem to stop short, check that setting before assuming tracking broke. Anything involving visitor-level health information belongs in a compliance conversation, not an SEO one.
The operational truth
Search history is an asset that decays on a fixed schedule. Every day without an archive, one more day of the oldest data disappears, and no vendor, tool, or support ticket can bring it back. The fix is a configuration change, not a strategy, which is exactly why it gets skipped.
When we take on SEO work for a treatment provider, setting up the archive is one of the first things we do, because every later question about what worked depends on it. If you want a second opinion on whether your property is archiving at all, that is a quick check to make before your next reporting cycle, and well before the next core update makes you wish you had the history.
