Search Console's 16-month limit: BigQuery export from day one or a quarterly pull?

Search Console only keeps 16 months of performance data, and the UI hides anonymized queries, so once a year passes you can't rebuild that history. Some people say turn on the BigQuery bulk export on day one. It's free for Search Console data, and you get daily rows you can keep as long as you like. Others say that's overkill for a site with a few thousand clicks a month, and a spreadsheet pulled every quarter does the job.

I lean toward the export as cheap insurance, mostly because the 16 months disappear fast and you only notice when someone asks about a year-over-year drop. What I'm less sure about is whether a small site will ever query that data or just let it sit there. Is the quarterly pull enough for most people, or are you using the export?

What tips it for me is that the bulk export doesn't backfill. It only collects from the day you switch it on, so the 16 months you've already lost are gone either way. The real decision is about the next year.

My rule of thumb: if you might ever want a page- or query-level year-over-year comparison, turn the export on at setup. It costs very little to leave running. If you only track the overall trend, a quarterly pull is enough.

Fair doubt on whether small sites ever query the raw tables later, but a dataset that's just sitting there still beats one you never started.

Honestly I'm not sure that last line holds. A dataset only beats nothing if someone eventually queries it, and at a few thousand clicks a month that's exactly where it rarely happens. Setting up the export means a Google Cloud project and a table you'll probably forget about within a year. A quarterly pull saved at page level keeps the year-over-year comparison you'd actually need, and it's one recurring task where you don't lose anything. The export makes more sense once you already work in BigQuery.

Agreed that a few thousand clicks rarely justifies a BigQuery project. Whether the quarterly pull is enough comes down to how many distinct pages and queries you have. The Search Console UI export caps at 1,000 rows per table, so a site with a long tail of product or blog pages can lose most of its URLs in a manual snapshot, and your year-over-year comparison ends up resting on the top sliver. If your page count sits well under that, the spreadsheet works fine. If it doesn't, a scheduled API pull is the middle option, though it takes some setup.

Agreed, and the cap hurts more than it looks because it applies per export, not per date range. A quarterly snapshot sorted by clicks keeps only the top URLs, and the tail that gets cut is exactly where a year-over-year comparison goes wrong. A page with three clicks last year and none this year just vanishes, so the drop seems to come from nowhere. Splitting the export by month, or by folder if your URLs are structured that way, gives you several files that cover more of the tail, and you can sum them back together.

Splitting by month helps, but summing the files back can still undercount. A page that lands just past row 1,000 in every monthly export vanishes from the total, and the total still looks precise. That's fine for spotting a trend. It's a bad number to hand a client as "this folder dropped 30%."

It comes down to how many distinct URLs get at least one click per quarter. If it's a few hundred, a quarterly UI export or a monthly split covers nearly everything, and the missing tail is just noise. If it's several thousand, the cap is the wrong tool. You need the API with pagination, or the BigQuery export, which has no 1,000-row limit. The export is free for Search Console data, so the cost argument against it gets weaker as the page count grows.