Google Search Console Search Analytics API gains Discover, News and Regex

The addition of Discover, Google News and regex filtering to the Search Analytics API, reported in the Search Engine Land article linked at the end of this page, looked like a minor capability note at the time. It was actually the change that made honest reporting practical, because it is the point at which you can ask the API a precise question instead of downloading everything and reconstructing the answer in a spreadsheet.

This page covers what the parameters actually do, the constraints that bite in production, and the query patterns worth having on hand.

The request, parameter by parameter

Everything happens in one POST to the searchAnalytics.query endpoint. The body is where all the decisions live.

The type parameter is the one that quietly determines whether a report is trustworthy. Because it defaults to web, a dashboard built without thinking about it reports Search only, and a publisher whose Discover traffic halved will see a chart that looks broadly stable. Any reporting layer intended to explain traffic changes needs to pull each surface as a separate series.

Understanding AI Content Consumption

Discover deserves a section of its own, because it is the surface that behaves least like search and the one this API change made measurable.

Discover has no query, which is not a data gap but a description of the mechanism. Google is predicting what an individual will want to read without being asked, so the selection is driven by inferred interest, entity level authority and engagement rather than by matching a string. That is algorithmic recommendation, and it is the closest thing in the Google ecosystem to how an AI system decides what is worth surfacing on a user's behalf: no explicit request, a model deciding relevance, and the publisher never seeing the intent that triggered it.

The practical consequence is that Discover performance has to be analysed with different dimensions and different expectations. Without a query dimension, your levers are page and date, which means the analysis is about which content types and which publication patterns get picked up, not which keywords won. Volatility that would signal a penalty in web search is normal behaviour in Discover, and treating a Discover swing as an SEO incident is one of the most common misdiagnoses in publisher reporting. Reporting on the two together, unsplit, guarantees that error.

Optimization Approaches

Three query patterns cover most of what teams actually need.

Separate the surfaces. Run the same date range once per type value that applies to your site and store the results as distinct series. This is the foundation, and it is the step that turns "traffic is down" into "Discover is down and web is flat".

Group queries with regex instead of exporting everything. Filtering server side keeps you inside the row limit and makes the grouping logic explicit and reviewable rather than buried in a spreadsheet formula.

{
  "startDate": "2026-01-01",
  "endDate": "2026-06-30",
  "type": "web",
  "dimensions": ["query"],
  "dimensionFilterGroups": [{
    "filters": [{
      "dimension": "query",
      "operator": "includingRegex",
      "expression": "(?i)^(how|what|why|when|which|where) "
    }]
  }],
  "rowLimit": 25000
}

Two details in that snippet matter more than they look. The (?i) prefix makes the pattern case insensitive, and without it you will miss a substantial share of matching queries. The ^ anchor is required because RE2 matching here behaves as a search rather than a full match, so an unanchored pattern matches anywhere in the string.

The same operator applied to the page dimension gives you section level reporting without maintaining a URL list, which is the practical way to report on a content hub as it grows. For a deeper treatment of pattern design, including the branded and non branded split, see using regex in Google Search Console.

Watch the RE2 limits. Lookahead, lookbehind and backreferences are absent by design, since RE2 guarantees linear time matching. Patterns that depend on them are rejected outright rather than running slowly, and the usual rewrite is an alternation list or two passes instead of one clever expression. Very long alternation lists can also exceed the accepted expression length, so a pattern that grows every time a brand variant is added will eventually need restructuring.

What has changed since this was published

The article this page is built on documented the original capability addition. Several relevant things have happened since, and they change the recommended approach.

• Regex filters reached the Search Console interface as well. Patterns can be prototyped in the UI and then moved into API calls, which is a much faster loop than debugging expressions through API responses.
• A bulk data export to BigQuery arrived in 2023. This is the significant one. It streams daily performance data into your own BigQuery dataset with no row limit and no sampling, which makes it the correct choice for any site large enough to be paginating heavily. The API remains the right tool for targeted questions and for keeping history beyond the retention window in your own store.
• The retention window did not move. Roughly 16 months remains the ceiling, so long term trend analysis still depends on you exporting and warehousing the data yourself. This is worth setting up before it is needed, since data outside the window cannot be recovered afterwards.

If you are building an extraction pipeline rather than running one off queries, the wider workflow is covered in reading the page indexing report for the coverage side, and connecting GA4 and Search Console for joining performance data to behaviour.

Strategic Implications

The reason this API matters is that it decides what your organisation is able to notice. A reporting layer that pulls only the default web type cannot see a Discover collapse, and a team that cannot see it will attribute the traffic loss to whatever is culturally salient that quarter. That is how content strategies get rebuilt on top of a misdiagnosis.

Surface separated reporting is cheap to build once and expensive to retrofit during an incident. The same applies to warehousing: the 16 month window means the historical baseline you will want during your next major traffic event is being permanently discarded right now unless something is already exporting it.

The broader pattern is that measurement granularity is becoming a competitive input rather than a hygiene task. As discovery fragments across more surfaces, each with its own selection mechanism, the aggregate number becomes less interpretable every year. Teams that can decompose it will diagnose correctly and respond proportionately, and teams that cannot will keep responding to the wrong thing.

Frequently asked questions

Source: https://searchengineland.com/google-search-console-search-analytics-api-gains-discover-news-and-regex-375468?utm_source=feedburner&utm_medium=feed&utm_campaign=feed-main