Why is Search Console data two to three days behind?
Search Console finalizes performance data roughly two to three days after the fact; the freshest rows are preliminary and still move. Any report built directly on the raw feed either shows numbers that later change or silently mixes final and preliminary days.
We treat the finalization window as a first-class fact: recent days are re-synced until they settle, and the data models mark where ‘final’ ends — so nobody screenshots a number that was about to move.
Why don’t query rows add up to the property totals?
Google withholds anonymized queries — rare or privacy-sensitive searches — from the API’s query-level results, while still counting them in totals. On many sites that gap is a double-digit share of impressions, and if you only store query rows it looks like missing data or a broken join.
We store totals alongside query rows so the gap becomes a measurable, explainable number. The bulk export goes one better: it includes anonymized queries as flagged, query-less rows, so on that path the gap is itself a column you can chart.
Why does Search Console history stop at 16 months?
The API’s retention window rolls forward daily: every day you wait, a day of history is permanently deleted at the far end. Year-over-year comparisons need at least 24 months, which Search Console alone can never give you.
The only fix is structural — land the data in a database you own before you need it. The bulk export accumulates forward without caps from the day it’s enabled, the API backfills the trailing 16 months, and from then on the window stops rolling for you.
How do you get more than 1,000 rows out of Search Console?
The interface caps every report at 1,000 rows regardless of how many queries or pages actually have data. Head terms fill the visible rows; the long tail — the thousands of specific, low-competition phrases you almost rank for — is exactly what the cap hides.
Both routes surface it: paged API pulls return up to 25,000 rows per request and reach depths of up to 50,000 rows per property per search type per day, and the bulk export has no row caps at all. Depth is the first thing this pipeline fixes.
Why does average position mislead you?
Position is an impression-weighted average of averages. Combine two queries, two pages or two date ranges and the blended number can move in the opposite direction of every part — a classic aggregation paradox. Raw exports make this worse by inviting naive AVG() over rows at mixed grain.
The data models recompute position weighted by impressions at each grain, so the number means what it appears to mean.
