Google Search Console's AI-powered branded queries filter is not simply an upgraded version of the traditional branded-versus-non-branded split built with regular expressions. Google classifies queries using its own AI-assisted system, whereas a regex filter follows the character patterns and terms defined by an SEO analyst. As a result, the same query may appear in different segments depending on the method.
Does that mean Google's classification is wrong? Not necessarily. A regex match does not prove that a query expresses brand intent. Equally, a label assigned by Google's AI-assisted filter is not an independently verified ground truth.
Google announced the branded queries filter on 20 November 2025 and confirmed availability for all eligible sites on 11 March 2026. Drawing on Google's official documentation, this article sets out a reproducible method for comparing the two approaches. Because comparable exports from an actual Search Console property have not been supplied, it makes no claims about measured accuracy or error rates.
How Does Google Search Console's AI-Powered Branded Queries Filter Work?
Google's Branded Queries Filter lets you analyse branded and non-branded search queries separately in Performance → Search results in Search Console.
It provides two segments:
- Branded: Queries containing a brand name, a variant of that name, or a closely associated product or service.
- Non-branded: Other queries that Google's system does not classify as branded.
The filter is available across Web, Image, Video and News search. For each segment, Search Console displays clicks, impressions, click-through rate (CTR) and average position. Search Console Insights also includes a breakdown of clicks attributed to branded and non-branded queries.
According to Google's official announcement of 20 November 2025, this is not a keyword inclusion/exclusion feature built on regex. Classification is performed by an internal, AI-assisted system.
Which Queries Can Be Classified as Branded?
Google's definition goes beyond searches that explicitly contain the company name.
Google's own documentation gives these examples for its brand:
| Query | Why it can be branded |
|---|---|
Google |
The brand name itself |
Gogle |
A misspelling of the brand name |
Gmail |
A product associated with the brand |
These examples illustrate Google's stated feature scope. They are not observations from an experiment conducted for this article.
Google says the filter can account for brand names across languages, misspellings, and searches for distinctive products or services even when the brand name is absent.
That scope is conceptually broader than a regex that only matches literal brand names. But broader coverage does not, by itself, demonstrate higher classification accuracy.
What Does Google Not Disclose About Its AI Model?
Google confirms that brand classification is AI-assisted. Its public explanation does not specify the model architecture, training data, query-level confidence scores, decision thresholds or a schedule for classification updates.
There is therefore no sound basis for asserting that the feature uses a particular large language model, embedding architecture or semantic-similarity threshold.
This is an important limitation: we can observe the labels the system produces for visible queries, but cannot independently reproduce every step of its internal decision process.
What Does Google's Warning About Classification Errors Mean?
Google explicitly acknowledges that the dynamic, contextual nature of brand classification can occasionally lead to misidentified queries.
Three practical implications follow:
- Do not treat the AI label as an error-free reference standard.
- Review unexpected classifications against the brand's actual products, services and search context.
- Do not assume classification behaviour will remain identical over time; review it periodically.
The final point is an audit recommendation, not evidence that Google changed classifications on any particular date.
Google also states that this reporting filter has no effect on Search rankings. It is a Search Console analysis feature, not a ranking signal.
Why Is the Branded Queries Filter Missing From Some Properties?
Google states that the feature is offered to eligible top-level properties. Subdirectory and subdomain properties may not qualify, and sufficient query and impression signals are required.
For example, the absence of the filter in a property such as https://example.com/blog/ or developers.example.com does not, on its own, indicate a technical fault.
Eligibility must be checked in the property's actual Search Console interface. Google's published documentation does not specify a universal minimum-impressions threshold.
How Do You Separate Branded Queries With Regex?
A regular expression, or regex, is a pattern used to match strings of characters according to explicit rules.
Its main advantage in SEO reporting is auditability: the definition of branded traffic can be documented, reviewed, reproduced and version-controlled.
To filter queries using regex in Search Console:
- Open Performance → Search results.
- Select + Add filter → Query.
- Choose Custom (regex).
- Enter your regex pattern.
- Use Matches regex for matching queries and Doesn't match regex for those that do not match.
- Record the reporting scope and pattern version before exporting the data.
These steps follow Google's advanced filtering documentation.
Why Does RE2 Matter for Search Console Regex Filters?
Search Console uses RE2 syntax. By default, matching is partial and case-insensitive.
For example:
brand|company: Matches either term.^brand: Looks forbrandat the beginning of the query.brand$: Looks forbrandat the end of the query.brand: Can also match inside a longer word because matching is partial.(?-i)Brand: Makes this expression case-sensitive.
Partial matching matters especially for short brand names. For instance, a filter containing only param could also match parameter, even if the latter has no relationship to the brand.
That is a potential false positive: a query without brand intent is labelled branded simply because the text matches a rule.
RE2's supported syntax and limitations must be considered in the specific tool being used. A pattern that works in a different regex engine may behave differently, or may not be supported, in Search Console.
How Should You Build a Brand-Specific Regex Dictionary?
Using only the legal company name is rarely a sufficient starting assumption for branded-query segmentation.
A practical brand dictionary can have three levels:
| Level | What it includes | Verification required |
|---|---|---|
| Explicit brand | Official brand name, domain, recognised written forms | Official company sources |
| Brand variants | Abbreviations, language-specific spelling, observed misspellings | Actual query evidence |
| Contextual brand references | Distinctive product, service and sub-brand names | Product ownership and human review |
A brand dictionary is not the same as conventional keyword research. Its purpose is to establish a consistent reporting classification rather than to identify search opportunities.
Example Regex for Turkish Characters and Name Variations
ILLUSTRATIVE EXAMPLE — NOT A REAL TEST RESULT
A narrow initial pattern:
gokhanaksoy
A broader pattern designed to capture selected variants:
(g[oö]khan[ -]?aksoy|gokhanaksoy\.com\.tr)
The second expression is intended to match forms such as gokhanaksoy, gökhan aksoy and gokhan-aksoy.
It does not capture every possible typo, joined-word variant or contextually branded query. Nor should it be used in production without checking false positives arising from partial matches.
The point is not to present a perfect regex, but to show why a pattern must be explicitly specified and validated against real queries.
A production pattern should be derived from the verified brand dictionary for the property being analysed.
How Should You Design an AI-versus-Regex Comparison?
Placing two totals from Search Console side by side is not enough to establish the reliability of either approach.
The preferred unit of comparison is the same query under the same reporting scope, wherever the data allows it.
Otherwise, an apparent disagreement may reflect data collection or aggregation rather than query classification.
1. Keep the Measurement Scope Identical
Define these conditions before starting:
| Variable | Control |
|---|---|
| Search Console property | Same property |
| Date range | Same start and end dates |
| Data status | Prefer finalised reporting days |
| Search type | Start with Web |
| Country | Same selected country or all-country scope |
| Device | Same device segment or combined scope |
| Aggregation | Comparable property/query level |
| Regex version | Recorded and unchanged |
| Additional filters | Identical or deliberately removed |
For instance, you cannot directly compare the AI filter across all countries with a regex segment restricted to Türkiye.
Likewise, page-level impression totals should not automatically be treated as equivalent to property-level totals.
2. Export Four Query Segments Separately
Where available, create four separate views:
- AI — Branded
- AI — Non-branded
- Regex — Matches regex
- Regex — Doesn't match regex
Archive the property, dates, search type, country, device, all active filters and regex version with every export.
Apply each filter in a separate, controlled state. A query filter left active in the interface, for example, may restrict the AI segment to an unintended subset of queries.
Critical rule: A query missing from an export must not automatically be assigned to the opposite class.
Record missing labels as not_observed. Then investigate whether the absence reflects classification, row limits, anonymisation or incomplete export coverage.
3. Normalise Query Keys, but Preserve the Raw Text
You can standardise text for joining datasets, but must retain each original query.
Suggested data schema:
| Field | Purpose |
|---|---|
query_raw |
Original query text |
query_normalized |
Standardised join key |
gsc_ai_label |
branded / nonbranded / not_observed / unknown |
regex_label |
branded / nonbranded / not_observed / unknown |
human_label |
branded / nonbranded / ambiguous / not_reviewed |
regex_version |
Rule-set version |
clicks, impressions |
Observed metrics from the same scope |
ctr, average_position |
Source metrics or correctly aggregated measures |
evidence_note |
Label rationale and uncertainty |
property, date_range, search_type, country, device |
Measurement scope |
Unicode normalisation deserves particular care for Turkish brand names. The characters I, İ, ı and i should not be collapsed into a single key without checking whether the resulting matches are valid.
Normalisation is intended to join records reliably, not to reverse-engineer Google's classifier.
4. Build an AI–Regex Agreement Matrix
Queries for which both classifications are observed fall into four cells.
EMPTY COMPARISON TEMPLATE — REAL DATA REQUIRED
| AI classification | Regex: Branded | Regex: Non-branded |
|---|---|---|
| AI: Branded | A — Agreement | B — Disagreement |
| AI: Non-branded | C — Disagreement | D — Agreement |
Cells A and D represent agreement; B and C represent disagreement.
Queries whose classification is missing from either method must be reported separately. They cannot silently be allocated to any of the four cells.
The AI–Regex agreement rate is calculated as:
Agreement = (A + D) / (A + B + C + D) × 100
Only queries with an observed label from both methods belong in the denominator.
This measure tells us how often the two approaches agree. It does not establish whether those shared decisions are correct.
5. Do Not Confuse Agreement With Accuracy
This distinction is central to the comparison.
When AI and regex both classify a query as branded, at least three possibilities remain:
- Both classifications are correct.
- Both systems make the same mistake.
- The query is ambiguous in the context of the brand.
High agreement, therefore, does not guarantee high accuracy.
To evaluate classification accuracy, you need an independent reference standard.
A qualified reviewer familiar with the brand's official products and services can provide reference labels. Ideally, the reviewer should not see the AI or regex labels before making their decision.
A second reviewer can reveal inconsistencies. Disagreements should be resolved through a documented adjudication process.
For queries suitable for binary classification, the principal metrics are:
- Accuracy:
(TP + TN) / (TP + TN + FP + FN) - Precision (branded):
TP / (TP + FP) - Recall (branded):
TP / (TP + FN) - F1:
2 × Precision × Recall / (Precision + Recall)
Here TP means true positive, FP false positive, TN true negative and FN false negative, relative to the independent brand label.
The figures are potentially misleading unless the sample, excluded records and treatment of ambiguous queries are disclosed.
For example, a dataset containing relatively few truly branded queries could produce a high overall accuracy score while still performing poorly at identifying branded queries. Precision and recall must therefore be considered separately.
6. Separate Query-Level and Traffic-Weighted Analysis
Counting every query equally answers a different question from weighting queries by clicks or impressions.
A query-level measure describes consistency across classified terms.
A click-weighted measure helps assess the potential reporting impact of disagreements on organic traffic.
A disagreement on a high-impression query may matter more to executive reporting than one on a low-volume long-tail query.
For that reason, review both the number of disputed queries and their click/impression weight.
Even traffic-weighted agreement, however, is not an independent measure of correctness.
Where Might AI and Regex Disagree?
The following scenarios are derived from Google's documented feature scope and the matching behaviour of regex. They are hypotheses to investigate, not measured findings.
ILLUSTRATIVE EXAMPLE — NOT A REAL TEST RESULT
| Query category | Possible reason for disagreement | How to validate |
|---|---|---|
| Misspelled brand name | Regex does not include that variant | Verify actual spelling variants |
| Brand-specific product | Regex misses a query without the parent brand name | Confirm product ownership |
| Brand name that is also a common word | Regex matches unrelated searches | Review search intent |
| Joined or spaced brand name | Space/hyphen rule is incomplete | Test alternative forms |
| Turkish character variation | Pattern omits a relevant character | Test character matching |
| Multilingual brand reference | Dictionary lacks a translation or local variant | Verify language and brand context |
| Brand name plus competitor | Comparison intent may be ambiguous | Assess the primary brand relationship |
| Ambiguous product or service | Query may relate to several brands | Preserve an ambiguous label |
| Missing export row | A data-coverage issue, not a classification error | Audit available rows |
These are potential disagreement and error categories. No query-level classification by Google was measured for this article, so no inferred Google labels or performance percentages are presented.
Why Can a Narrow Regex Produce False Negatives?
A dictionary limited to the official company name may exclude searches for a distinctive product or service.
In Google's own illustration, Gmail may be considered branded because it is a Google product. A narrow regex looking only for google, by contrast, does not match the text gmail.
This demonstrates a difference in the methods' definitions—not an empirically observed discrepancy for a specific Search Console property.
Why Can a Broad Regex Produce False Positives?
Some brand names are also ordinary words or occur inside unrelated terms.
A literal text-matching rule may therefore capture searches with no meaningful relationship to the brand.
Expanding the dictionary can increase recall but may also increase false positives. Continuously adding terms to a regex is not, by itself, a reliable optimisation strategy.
How Should You Compare Regex v1 and v2?
Keep the two versions distinct:
Regex v1: Official brand names and verified core variants.
Regex v2: Additional variants and matching boundaries approved after reviewing real disagreements.
A better score on the initial test dataset is not sufficient evidence of improvement. The revised pattern should also be evaluated on a separate validation set that was not used to develop the rules.
Otherwise, the regex may overfit historical queries and behave poorly on new ones.
This distinction matters for organisations building comparable SEO reporting over time. When the definition of branded traffic changes, the meaning of the historical series may also change.
Are Search Console Data Discrepancies Really Classification Errors?
One of the largest analytical risks is mistaking missing or differently aggregated query data for a disagreement between AI and regex.
Google documents that Search Console performance metrics can be subject to different filtering, grouping and export conditions.
The relevant limitations are discussed in Google's technical explanation of Search Console performance data.
Why Do Anonymised Queries Matter?
To protect user privacy, Google anonymises certain low-frequency queries.
Their query text is not shown in the performance table, although their associated data may contribute to unfiltered chart totals.
Applying a query filter can exclude anonymised queries, so filtered and unfiltered totals may differ.
The following assumption is therefore unsafe:
Regex-matching clicks + Regex-non-matching clicks = unfiltered total clicks in every case
A gap does not automatically prove that the regex or Google's AI classification is defective.
Because the text of anonymised queries is unavailable, those queries also cannot be independently labelled at the query level.
How Do Interface and API Row Limits Affect the Comparison?
Google's documentation describes an export limit of 1,000 rows in the Search Console interface.
The Search Analytics API can return up to 25,000 rows per request. Pagination can retrieve additional rows, but documented data limitations and anonymisation still apply.
More API rows do not mean that every query that generated an impression is accessible.
The API documents regex filter operators, while the internal AI branded-query label is not documented as a standard API filter dimension or operator.
A regex-defined segment retrieved through the API must therefore not be described as the direct output of Google's AI brand classifier.
Technical reference: Search Analytics API — query.
Why Can Chart Totals Differ From Query Rows?
Search Console charts and tables can be generated using different aggregation rules.
Page filters, canonical URL aggregation, anonymised queries and row limits can all affect the comparison.
For example, a property's impression total will not necessarily equal a sum generated from a differently grouped page-level report.
Check the aggregation level before attributing such a difference to brand classification.
Checklist: Diagnose the Source of a Reporting Discrepancy
When two segments show an unexpected difference, work through these questions:
- Are both reports using the same Search Console property?
- Are dates, country, device and search type identical?
- Are any additional query or page filters active?
- Are the chart and table aggregated at comparable levels?
- Has the impact of anonymised queries been considered?
- Could export row limits or truncation affect the result?
- Are queries without both observed labels reported separately?
- Have remaining discrepancies been reviewed against actual queries?
Only after these checks should the unresolved differences be investigated as potential classification disagreements.
This distinction also matters when investigating organic performance changes. A change in total clicks does not, by itself, tell you which search-query segment changed. Keep it in mind when diagnosing sudden drops in organic traffic.
Should SEO Reporting Use the AI Filter or Regex?
The right choice depends on the decision the report needs to support—not on which method appears more technically sophisticated.
Decision Matrix by Reporting Objective
| Reporting objective | Preferred approach | Reason |
|---|---|---|
| Quick branded/non-branded performance review | AI branded queries filter | Uses Google's built-in segmentation |
| Audit brand-specific classification rules | Regex | Terms and matching logic are inspectable |
| Maintain a reproducible rule set | Version-controlled regex | Definitions and revisions can be documented |
| Examine Google's contextual classification | AI filter | Shows Google's own segment labels |
| Assess accuracy in an executive report | AI + regex + independent labels | Supports review of shared errors and disagreements |
| Apply rule-based filtering through the API | Regex | RE2-based operators are documented |
| Track brand-related demand over time | Consistently scoped AI or regex series | Comparable definitions are essential |
This matrix is not a measured ranking of the two approaches. It is a methodological recommendation based on documented product behaviour and the need for auditability.
Which Errors Are Most Costly in Executive Reporting?
Not all brand-classification mistakes have the same business implications.
For example, treating a genuinely branded product query as non-branded may distort how non-branded search visibility is interpreted.
Conversely, labelling a generic category query as branded can blur the distinction between brand demand and category demand.
Whether either error actually occurs must be established with real query data.
Executive reporting should therefore disclose more than segment totals: it should explain the scope of material disagreements and their potential effect on the business interpretation.
Does a Non-Branded Query Mean a New User?
No.
A non-branded query is a search term classified as non-branded under a particular query-classification method.
The person behind it might have visited the site before, be an existing customer, or already know the brand while searching for a general category.
These concepts are not interchangeable:
- Non-branded query
- New user
- New customer
- Incremental customer acquisition
Growth in non-branded queries may indicate stronger discovery and category visibility. Claims about new users or customers, however, require appropriate analytics and commercial data.
AI search visibility is also distinct from conventional branded-query segmentation in Search Console. Each answers a different measurement question. For the wider context, see SEO in the AI Era: Search and Answer Visibility.
Conclusion: What Would Make the AI Branded Queries Filter Trustworthy?
Google Search Console's AI-assisted filter provides an accessible, built-in way to examine branded searches. Its official documentation does not claim that every classification is correct.
Regex offers explicit, reproducible rules, but its accuracy depends on the completeness of the brand dictionary and the quality of the matching logic.
Four conclusions follow from the documented evidence:
- AI and regex use different approaches. Google's AI-assisted classification is not regex-based, so comparing both on the same queries is a meaningful exercise.
- Disagreement is not proof of error. Independent knowledge of the brand context is needed to decide which classification, if either, is correct.
- Audit coverage before classification. Anonymised queries, row limits, active filters and aggregation differences can affect the comparison.
- Transparency matters in high-stakes reporting. The AI filter supports quick analysis; version-controlled regex supports auditable rules. Claims about accuracy require an independent reference.
This article does not report an AI–regex agreement rate or an accuracy percentage calculated from actual Search Console exports. It therefore does not conclude that either method is more accurate.
Trustworthiness becomes measurable not when two systems agree, but when their decisions can be checked against an independent reference.
Sources
The explanations of product behaviour and reporting limitations in this article rely on Google's official documentation:
- Google Search Central — Introducing the branded queries filter in Search Console — 20 November 2025; update on 11 March 2026.
- Search Console Help — Advanced filtering and comparison — RE2 syntax and filtering behaviour.
- Google Search Central — A deep dive into Search Console performance data — Query anonymisation and row limits.
- Search Console Help — Troubleshooting data discrepancies — Chart, table and filter totals.
- Search Console Help — Dimensions and data groupings — Query dimensions and data limitations.
- Search Analytics API Reference — API operators and query specifications.
Frequently Asked Questions
Does the Search Console branded queries filter use regex?
No. Google explicitly states that branded versus non-branded classification is performed by an internal, AI-assisted system. Regex is a separate query-filtering option in Search Console.
Can Google's AI branded queries filter misclassify searches?
Yes. Google acknowledges that its contextual, dynamic classification may occasionally misidentify queries. Its official documentation does not provide a universal accuracy or error rate.
Why are AI branded-query totals different from regex totals?
The methods may label individual queries differently. Anonymised queries, row limits, active filters and aggregation differences can also affect totals. The cause must be investigated using comparable query-level data and reporting settings.
Which Search Console properties are eligible for the AI branded queries filter?
Google says the feature is available to eligible top-level properties. Subdirectory or subdomain properties may be ineligible, and sufficient query and impression signals are required. Check eligibility in the actual property interface.
How can a search be branded if it does not mention the brand?
Google's definition includes distinctive products or services associated with the brand. Gmail, for example, appears as a branded product-query example in Google's official announcement.
Is the AI branded queries filter available through the Search Analytics API?
As of the official API reference reviewed on 3 November 2026, includingRegex and excludingRegex are documented operators. Google's internal AI brand label is not documented as a standard API filter dimension or operator. Do not treat an API regex result as the AI classification.
Do non-branded queries represent new users?
No. A non-branded query describes how a search term is classified, not whether the person is a first-time visitor or a new customer.
How should regex handle Turkish characters and misspellings?
Use verified spelling variants, character classes and appropriate matching boundaries. For example, [oö] matches either character. Test real queries for false positives and false negatives before treating the pattern as comprehensive.
Comments