Discrepancies between the Search Console UI and the API for what looks like the same query most commonly come from three sources: different default aggregation and deduplication behavior between the two surfaces, different handling of data freshness (the most recent one to two days of data can still be processing and shift as more data arrives, and the UI and API may capture that in-flight data at slightly different points), and mismatched dimensions or filters that appear identical but aren’t, particularly around timezone handling and default grouping behavior the UI applies that an API call may not replicate exactly. Before treating a discrepancy as a bug, the reliable first step is confirming both surfaces are actually querying identical dimensions, filters, and date ranges, including timezone.
Aggregation and deduplication differences
The Search Console UI applies its own default aggregation logic when presenting a report, in some views grouping or deduplicating data in ways that aren’t necessarily identical to a raw API call requesting the same nominal metrics and dimensions. A UI report showing totals for a date range may be summing or deduplicating underlying rows differently than an API request that returns row-level data for the analyst to aggregate manually, and if the manual aggregation logic doesn’t exactly replicate whatever the UI does internally (for instance, around how the UI handles a query or page appearing in multiple dimension combinations), the totals won’t match even though both are technically drawing from the same underlying dataset.
This is a case where the discrepancy isn’t evidence of incomplete or incorrect data from either surface, it’s evidence that “the same date range and dimension filters” can still mean subtly different aggregation logic depending on which surface is doing the summarizing.
Data freshness and processing lag
Google’s own documentation around Search Console data notes that the most recent days of data are often still processing and can be incomplete or subject to revision as additional data arrives and finishes being processed. If a UI report and an API call are pulled at different moments, even a few hours apart, and both include very recent dates in the range, they can each be capturing a different snapshot of still-settling data for those most recent days, producing a discrepancy that isn’t a bug but a reflection of when each pull happened relative to Google’s own data-processing completion for that date. This effect is strongest for the most recent one to two days in a report and generally isn’t a factor for older, fully-processed date ranges.
Default filters and definitional mismatches
The UI often has default behaviors, timezone handling, certain default groupings, filtering conventions around specific dimension combinations, that aren’t automatically obvious from looking at the UI’s displayed filter panel. A UI report and an API request that look like they’re specifying “the same” date range can actually differ if one is implicitly using a different timezone convention for what counts as a given calendar day, since Search Console’s data is date-bounded and a day boundary shift due to timezone handling can move a meaningful number of clicks or impressions across the boundary between adjacent days, especially for high-traffic days near the range’s edges.
Similarly, device, country, or search-type filters that appear identical between a UI report and an API call need to be checked precisely, since a subtle default (for example, the UI defaulting to “Web” search type while an API call inadvertently includes all search types, or vice versa) produces numbers that look like they should match but are actually drawing from different underlying data subsets.
What this doesn’t mean
None of this should be read as Google Search Console having unreliable or arbitrary data. Google frames these discrepancies, in its own documentation notes about data processing and aggregation, as expected variance from definitional and timing differences between surfaces, not as an acknowledged bug. Treating every UI-versus-API mismatch as evidence of a data-quality problem in GSC itself is generally the wrong diagnosis; the more common and more actionable diagnosis is that the comparison wasn’t actually apples-to-apples in dimensions, filters, or timing, even when it appeared to be.
Practical implication
When a UI-versus-API discrepancy shows up, first verify exact equivalence of date range (including timezone), search type filter, device filter, country filter, and any other dimension filter applied on both sides, since a mismatch in any of these is the most common actual cause. Second, exclude the most recent one to two days from the comparison to rule out data-processing lag as the source of the difference. Third, if a discrepancy persists after confirming genuinely identical filters and excluding recent in-flight days, treat it as an aggregation-methodology difference between the two surfaces rather than an error in either, and standardize on one surface (commonly the API, or the BigQuery bulk export for the most granular access) as the authoritative source for any analysis requiring precise, reproducible numbers, rather than trying to reconcile the UI and API to match exactly on every report.
