Why don’t the Search Console API and the web interface return the same data?

Do the API and the interface really use the same backend?

Yes. John Mueller confirms it unequivocally: the Search Console API and the web interface query exactly the same data source. No differentiated processing, no specific latency, no filters applied on the API side.

This clarification puts an end to a persistent belief among some practitioners: the idea that the API would provide 'raw' data while the interface applied filters or aggregations. That is false. Both access points point to the same backend system, with the same sampling rules and limitations.

Where do the observed data discrepancies come from?

The problem almost always arises at the level of domain verification. Search Console strictly distinguishes between HTTP and HTTPS, www and non-www — each combination constitutes a distinct property.

Imagine: you verify your property in HTTP without www in the interface, but your API script queries the HTTPS version with www. Result: zero data returned by the API, while the interface displays metrics. This is not a bug — you are simply querying two different properties.

What is the difference between a domain property and a URL property?

Search Console offers two types of properties: domain property (covers all HTTP/HTTPS variations, www/non-www, subdomains) and URL prefix property (a single specific version). The domain property requires DNS verification.

If you use a URL prefix property, you must query the API with exactly the same prefix as the one verified. A single character difference — a final slash, a missing s — and the API will return nothing. With a domain property, this issue disappears, but the initial verification is more stringent.

• The API and the web interface share the same backend — no technical difference between the two systems.
• Data discrepancies arise from differences in domain verification: HTTP vs HTTPS, www vs non-www.
• A domain property aggregates all variations; a URL prefix property only covers one specific version.
• Always ensure your API script queries exactly the same property as the one displayed in the interface.
• A single character difference in the URL can cause the API call to fail without an explicit error message.

Is this statement consistent with practices observed in the field?

Totally. Practitioners who have delved into this issue confirm: API/interface discrepancies almost always stem from a configuration error, not a technical divergence. I have personally debugged dozens of scripts querying the wrong property — and in 100% of cases, correcting the property URL resolved the issue.

What remains unclear is the propagation delay between verifying a new property and its availability via the API. Some practitioners report latencies of several hours, while others report no delay. Google does not document this point — [To be verified] if you are deploying critical automations.

What nuances should be added to this statement?

Mueller's statement is correct, but it overlooks sampling limitations. Search Console does not display all your queries — only a representative sample. This limitation applies to both the interface and the API, but becomes more apparent when aggregating data via a script.

Another point: IAM permissions and API quotas can create perceived discrepancies. If your service account does not have the appropriate permissions on the property, the API will return a 403 error — which some scripts interpret as 'no data'. This is not a backend issue, it’s an authentication problem.

In what cases does this rule not apply?

If you observe data in the interface but zero results via API after verifying the property, two possible scenarios: either you are querying a date range prior to the property verification, or you have hit sampling limits for very granular dimensions.

Also beware of disabled or deleted properties. The interface may cache data for a few days after the deletion of a property, while the API will return an error immediately. This is not documented but is empirically observed — [To be verified] in your own audits.

What should you concretely do to avoid API/interface discrepancies?

First, list all your verified properties in Search Console. Note their exact prefix: HTTP or HTTPS, www or non-www, final slash or not. Then, ensure that your API script queries exactly the same string of characters.

If you use multiple domain variations (HTTP redirects to HTTPS, non-www redirects to www), prefer a domain property. It requires DNS verification, but eliminates 90% of configuration errors on the API side. This is an initial investment that will save you hours of debugging.

What mistakes should you avoid when querying the API?

Never assume that your site's canonical URL matches the verified property in Search Console. These are two distinct concepts. Your site may canonically point to HTTPS with www, but if you have only verified HTTP without www, the API will return nothing.

Another pitfall: service account permissions. If you use OAuth to authenticate your API calls, ensure that the account has 'Owner' or 'Full access user' rights on the property. 'Restricted access user' is not sufficient for some endpoints.

How to verify that my script queries the right property?

Use the searchanalytics.query endpoint with a short date range (last 7 days) and no dimensions — just the totals. If this call returns zero rows while the interface shows data for the same period, you are querying the wrong property.

To diagnose precisely, list all your properties using the sites.list endpoint. Compare the returned URLs with those displayed in the interface. They must match character for character, final slash included. If any discrepancy appears, that’s where your bug lies.

• Check that the property URL used in the API matches exactly that of the interface (HTTP/HTTPS, www, final slash)
• Prefer a domain property (DNS verification) to cover all URL variations
• Test the API call with a short date range and no dimensions to isolate configuration errors
• Use sites.list to compare available properties via API with those in the interface
• Check service account permissions: 'Owner' or 'Full access user' rights required
• Document API quotas (1,200 requests/minute) and implement rate limiting in your scripts