Do the API and Search Console interface really display the same data?

Why is this statement from John Mueller important?

Many SEO professionals have long suspected that the Search Console API returns sampled or different data from what is visible in the graphical interface. This mistrust arose from sporadic discrepancies observed during simultaneous queries — often due to cache delays or differences in parameter formatting, not from a distinct data source.

Mueller sets the record straight: one single database, two access points. This means that if you retrieve impressions for a page via the API and compare them to the interface, any discrepancies come from request bias (date range, country filter, aggregation), not from a different repository.

What practical implications does this have for an automated SEO workflow?

If you are developing custom dashboards or monitoring tools that rely on the API, you can trust them just as much as the official UI. This simplifies large-scale audits: no need to manually cross-check each metric in the interface to validate consistency.

However, keep in mind that the API imposes quota limits and different aggregations depending on the selected dimensions. You will not see substantive discrepancies, but the available granularity may vary if you query multiple dimensions simultaneously — it’s a design choice, not a parallel database.

What nuances should be added to this statement?

Even though the source is unique, the display may differ. The web interface sometimes applies rounding, confidentiality thresholds (when volumes are too low), or default filters that are not always explicit. The API returns raw data as is — you need to handle rounding and formatting yourself.

And let’s be honest: Search Console data is never exhaustive. Google samples beyond a certain threshold, especially on infrequent long-tail queries. Whether you go through the API or the UI, you will never see 100% of clicks and impressions — it’s an intrinsic limitation of the tool, not a synchronization issue between two databases.

• API and UI share exactly the same database — no parallel repository or additional sampling on the API side.
• The observed discrepancies stem from filters, cache, or differences in aggregation, not from a divergence in source.
• The API offers superior granularity and flexibility, but remains subject to the same quota and privacy limits as the interface.
• Search Console data remains sampled beyond a certain volume — whether you use the API or the UI, you never get 100% of the real-world data.
• Display differences (rounding, privacy thresholds) are presentation choices, not substantive divergences.

Is this statement consistent with observed practices on the ground?

Yes, overall. SEOs who have previously cross-referenced API extractions with the UI notice a very high consistency on aggregated metrics — total clicks, impressions, average CTR. Discrepancies mainly arise when combining multiple dimensions (page + query + device + country): the API then refuses to display certain rows to protect privacy, while the UI sometimes aggregates this data in a more permissive manner.

In practice, if you query significant volumes (several thousand impressions), you will get exactly the same numbers. It’s in the long tail — queries with 1 or 2 impressions — that the UI hides data that the API simply doesn’t return. Again, this is not a database issue: it’s a privacy rule applied upstream.

What limits should be kept in mind with this statement?

Mueller does not say that the API and UI return exactly the same rows of data — he states that they source from the same repository. Important nuance. If you ask the API for a cross-reference of page × query × device × country, Google may refuse to show you certain combinations to avoid user re-identification. The UI, on the other hand, sometimes aggregates these combinations into catch-all categories (“Other queries”).

Another limit: the freshness delays. The API and UI share the same database, but the data is not updated in real-time. There may be a lag of a few hours between when Google indexes a page and when clicks appear in Search Console — whether you use the API or the UI, you experience the same delay. [To be verified] : some users report latency differences between the two channels, but no official confirmation.

In which cases does this rule not apply?

This statement only covers performance data (clicks, impressions, positions). It says nothing about other sections of Search Console: Coverage, Core Web Vitals, Links, Sitemaps. Each of these sections has its own data pipeline, its own update delays, and its own privacy rules.

For example, data on Core Web Vitals comes from CrUX (Chrome User Experience Report), a dataset completely distinct from search logs. The API will not give you exactly the same metrics as the UI if you compare pages with very low Chrome traffic volumes. The same goes for backlinks: Google heavily samples this list, and the API only returns a subset of the backlinks visible in the UI.

What should you do concretely if you are already using the Search Console API?

Continue to use it confidently for your automated reporting. If you’ve built a dashboard that extracts daily clicks and impressions per page, you don’t need to manually validate each line in the UI — the source is the same. However, do document your filters and aggregations well: a discrepancy with the UI often signals a difference in parameters, not a data error.

If you are cross-referencing several dimensions (page + query + country), plan for a 5 to 10% margin of difference on total volumes — this is related to privacy thresholds, not a different database. In this case, the API masks certain combinations that the UI aggregates into “Other.” Document these limits in your reports to avoid clients questioning your numbers.

What mistakes should be avoided when using this data?

Never compare API and UI extractions with offset date ranges or different country filters — this is the main source of discrepancies. Google applies filters server-side before returning the data: if you request “France only” in the API and forget this filter in the UI, you will get divergent totals.

Another typical pitfall: the API returns average positions weighted by impressions, not a median. If a page fluctuates between position 1 and position 50 depending on the queries, the average might seem counterintuitive. The UI applies the same calculation, but the graphical display might obscure this reality. Make sure you understand the metric before drawing conclusions.

How can you check that your extractions are consistent with the UI?

Run a simple query over a fixed period (for example, the last 28 days, with no country or device filter) and compare the total clicks and impressions. If the figures correspond to 100%, you have confirmation that your API setup is correct. If you see a discrepancy of more than 1%, check your authentication parameters, your filters, and your Search Console account's timezone.

Then, test a query with multiple dimensions (page + query). The API should return fewer rows than the UI, as it masks low-volume combinations. This is normal. If you see more rows in the API than in the UI, it means a filter has slipped into one of the two sides — double-check your query.

• Use the API confidently for automated reporting — the data source is the same as the UI.
• Document your filters and aggregations to explain any discrepancy related to privacy thresholds.
• Plan for a margin of 5-10% difference on multi-dimensional cross-references (page × query × country).
• Never compare API and UI with different date ranges or country filters.
• Run a simple validation query (28 days, no filter) to verify that your setup is correct.
• Understand that the API returns weighted average positions, not medians — this may seem counterintuitive.