Search Console 16-month limit: turn on BigQuery export early or pull CSVs?

Search Console only keeps 16 months of performance data, and the UI quietly drops anything older. For a small site that's usually fine, since you rarely need year-over-year comparisons beyond that. Still, I'd turn on the BigQuery bulk export on day one. It costs nothing to enable, but it only records from the day you switch it on, so you can't backfill it later.

The tradeoff is setup effort and storage. For a site with a few thousand queries a month, a daily CSV pull is honestly enough. What really matters is how often you need history, like checking whether a seasonal dip is new or just last year repeating. How do you handle that on sites under 10k clicks a month?

A daily CSV pull only works if someone actually runs it every day, and that's the first habit to slip. Say a small site skips three weeks in March. Once those days age past 16 months, they're gone for good, and no amount of catching up brings them back. The UI export also caps rows, so a site with a long tail of queries can lose data even when the pull runs on time.

BigQuery has the same no-backfill limit, but it runs without anyone having to remember anything, and storage cost on a small site is usually tiny.

The row cap is a real problem, but BigQuery won't fix everything. Both the UI export and the bulk export leave out anonymized queries, the ones Google hides for privacy reasons. A local service site with lots of small suburb-specific searches will look thinner in any export than it really was. What the bulk export does give you is per-query rows without the UI row limit, so it helps most on sites with a long tail.

For a small local business, I'd turn on the bulk export now and also save a monthly CSV in your own folder as a second copy. If the export ever stops or a setting breaks, you still have a record, and one skipped month won't wipe out your history.

Agreed on the monthly copy, Marco, it's cheap insurance. The bulk export also includes the anonymized rows, not just the per-query ones. They show up with a null query and an is_anonymized_query flag, so you can sum them and see how much of your impressions and clicks sit behind the privacy filter.

That matters for a local service site. If the hidden share is 5% you can mostly ignore it. If it's 30% in suburb-level searches, your query-level analysis is missing a lot, and you're better off judging trends on page-level and site-level totals. Since the flag is in the table, you can track that share month by month without guessing, which the UI can't do at all.

Summing on is_anonymized_query is the safer habit over checking query IS NULL. A null check can get dropped by accident when you join to other tables or add a text filter, and then your hidden share comes out too low with no warning.

Also, don't stop at the site total. Take a dental clinic where one location page pulls most of the local searches. The hidden share on that page could be far above the site average, and the total would smooth it away. Track the share for your top ten URLs each month. If a page's share jumps, its query-level data just got thinner, and you can stop reading small query changes on it as real movement.

This works, but the share gets noisy on low-volume pages. If a URL gets 40 impressions and 12 are anonymized, that reads as 30%, and one more month of data could easily swing it to 5%. I'd log the absolute anonymized impressions next to the percentage, so you can tell a real shift from a small number divided by another small number. On a dental clinic's location page, the share that matters is probably the one for the high-volume local queries, not the whole page. What floor would you set before a page's hidden share counts as a signal?