Search Console regex filters: segment queries and URLs by pattern
Table of contents
The default Search Console filter takes one exact term and stops there. To learn how much traffic every query starting with "how" brings, or to separate branded from non-branded demand, you need a search console regex: one pattern that groups hundreds of queries or URLs into a single view.
What the Custom (regex) filter does and when to use it
The performance report offers three ways to filter. "Contains" and "Doesn't contain" compare literal text: you type running shoes and Google looks for that string inside the query, nothing more. The third option, Custom (regex), hands the text to a regular expression engine, so you can ask for "any query starting with one of these question words" or "any URL in this folder carrying a campaign parameter".
That engine is RE2, the same one Google uses elsewhere. It does not understand meaning: it compares characters. One scope detail matters: the custom filter is only available on the Queries and Pages dimensions, because those are the only ones with free text. Every other dimension (country, device, search appearance) comes from a closed list you simply tick.
The same filter appears in the Discover performance report, where there are only URLs: there the pattern is applied to the path, which is useful to measure how much Discover exposure a single section concentrates.
When not to use it: if you need the full dataset to join queries with another source, if you want history beyond the 16 months shown in the interface, or if you are about to build dozens of different segments. That is a job for bulk export.
How to apply a regex filter step by step
- Open Performance in Search Console and stay on the Search results tab. The filter also exists in Discover, but the two datasets never mix.
- Click + Add filter and pick the dimension: Query if you are segmenting demand, Page if you are segmenting inventory.
- From the operator list choose Custom (regex).
- Write the pattern. For several alternative values, group them and separate with a pipe:
(value1|value2|value3). The parentheses are not decoration, they mark where the alternation ends. - Pick the direction: Matches regex keeps the rows that satisfy the pattern; Doesn't match regex excludes them. The second one is how you get the complement.
- Before trusting the filter, check the match preview in the dropdown. If you see rows you did not expect, the pattern is badly anchored. Fix it there, not after exporting.
A habit that saves pain: review the query list that ended up inside the filter. If something shows up that should not, you either missed a start anchor or left a wildcard too loose.
The minimum RE2 syntax you need
You do not have to learn regular expressions in full. This table covers most real filters:
| Operator | What it does | Example |
|---|---|---|
. | Any single character | example.com |
[ ] | One character from a set | shoe[s]? |
* | Zero or more of the previous | seo.*guide |
+ | One or more of the previous | \d+ |
| | Alternation, this or that | (price|cost) |
\d | One digit | page-\d |
\D | One non-digit character | \D+$ |
\s | One whitespace character | best\s+seo |
\S | One non-whitespace character | \S+ |
^ | Anchor at the start | ^how |
$ | Anchor at the end | -\d+$ |
(?-i) | Force case sensitivity | (?-i)SEO |
The three recurring mistakes
One: forgetting that matching is partial. By default the pattern is searched anywhere in the text, it does not have to cover it whole. Typing seo also catches cheap seo consultant. Anchor with ^ if it must start there, close with $ if it must end there.
Two: assuming it is case sensitive. The filter ignores case by default, and in practice it rarely matters because queries are displayed in lowercase. URLs do keep their capitals, so on the Page dimension it can matter: prefixing (?-i) turns sensitivity on, meaning (?-i)Blog will not find blog.
Three: accents are different characters. optimizacion does not match optimización. Group the vowel instead: optimizaci(o|ó)n. The same happens with busqueda and búsqueda, which in Spanish affects a huge number of queries.
Finally, know what does not exist in RE2: no lookahead ((?=...)), no lookbehind ((?<=...)), no backreferences and no atomic groups. If a pattern copied from another engine fails, it probably relies on one of those.
Copy-paste regex patterns
Replace the brand name and the domain. Each one is meant for the dimension stated.
Branded vs non-branded
^(brand|brand example|example\.com)\b
On Queries with "Matches", it leaves branded traffic. The dot in the domain is escaped (\.) because unescaped it means "any character". There is no negation inside the pattern: use the same text with "Doesn't match regex" for non-branded traffic.
Question queries
^(how|what|when|where|why|which|who|is|can|does)\b
Captures informational intent while the user is still exploring. If CTR in this segment is low, the problem is usually the title, not the position.
A single folder
^https://(www\.)?example\.com/blog/
On Pages. The start anchor stops a URL that carries the string inside a parameter from slipping in. Swap the folder for whichever section you want to isolate.
URLs with parameters
[?&](utm_|fbclid|gclid|page=)
Finds crawlable campaign variants and pagination. If this segment shows many impressions, crawl budget is being spent on duplicates.
Legacy URLs by numeric suffix
-\d+$
Finds paths ending in an identifier, typical of old migrations. Handy to decide what to redirect.
Commercial intent
(best|vs|comparison|price|alternative)
No anchor, so it scans the whole query. Cross this segment with average position to see whether you are outside the top 3 on the queries closest to a purchase.
Limits that will bite you
Filtering changes the totals. Google warns that filtering by query or URL can alter the report aggregates: part of the data is truncated and queries the system keeps anonymized are left out. Your segment clicks do not have to add up to the site total. Read every segment as a partial snapshot, not an exact slice of the pie.
One comparison at a time. Adding a second comparison replaces the first instead of stacking: do not expect three periods on screen. For long trends, switch the granularity to weekly or monthly, which also neutralizes the day-of-week effect.
Case rules depend on the dimension. Queries are shown in lowercase, so a regex over queries almost never needs case sensitivity. URLs are not: they keep their original capitalization.
Rare values show as ~. When a data point is infrequent, the interface summarizes it that way instead of printing the number. Do not read it as zero.
When regex isn't enough: BigQuery and the API
The practical rule is simple: one question per session, regex; cross-cutting or historical questions, export. If you want to know how many question queries bring clicks on mobile from one country, the interface filter cannot get there, since it allows one comparison and does not freely cross dimensions.
For that there is the bulk export to BigQuery, which delivers the full table and lets you write SQL: see how to export Search Console to BigQuery and query it with SQL. And if what you need is to check indexing for many URLs at once, the URL Inspection API does the work without touching the interface.
A 20-minute monthly routine with regex filters
Four fixed segments are enough to keep your bearings:
- Branded: compare clicks and CTR against last month. If CTR falls at the same position, review the result Google shows for your name, a separate topic covered in controlling your brand SERP.
- Non-branded: this is where real growth lives. Read absolute clicks, not share percentage.
- Questions: if impressions rise and clicks do not, the content answers but the title does not convince. That is the cheapest work available.
- Main folders: one per section. It catches the one losing traffic before the site total reveals it.
One caution when reading positions: the average misleads when a single query appears at very different positions depending on the variant. I cover it in how to measure your rankings and why average position misleads.
Final checklist
- The pattern is anchored with
^and$whenever partial matching is not what you want. - Dots in domains and subdomains are escaped (
\.). - You checked the match preview before trusting the result.
- You used a single comparison filter, and weekly or monthly granularity for trends.
- You read the totals as a segment, not as the whole site.
- If the pattern used lookarounds or backreferences, you rewrote it: RE2 does not support them.
Official reference for the syntax and operators: Search Console help on advanced filtering and the RE2 syntax reference.