Search Console regex filters turn the Performance report from a list you scroll into a set of questions you can ask. Which queries are questions? How much of your traffic is branded? What does the blog earn on its own? None of that needs an export or a spreadsheet if you know a handful of patterns and the rules Google applies to them. This post covers the rules first, because they explain most broken filters, then the patterns worth saving.
How the Search Console regex filter works
Google documents the feature in its help article on advanced filtering and comparison in the Performance report. Regex filters work on two dimensions, Queries and Pages. In either filter you choose “Matches regex”, which is the default, or “Doesn’t match regex”, which excludes whatever the pattern catches.
Three rules from that article explain most of the surprises people hit.
- The syntax is RE2. Google says: “The RE2 syntax is used.” RE2 is a deliberately limited flavour, so some features you may know from other tools, such as lookaheads, are not available.
- Matching is partial. In Google’s words: “Default matching is a ‘partial match.’ Your regular expression can match anywhere in the target string unless you use ^ (start of string) or $ (end of string).”
- Matching ignores case. The default is not case-sensitive. Google notes: “You can prepend
(?-i)to the beginning of your expression for case-sensitive matches.”
Partial matching is the rule that bites. A filter for seo on queries catches “seo”, but also “seo tools”, “local seo” and anything else containing those three letters in a row. That is often what you want. When it is not, anchor the pattern with ^ and $ so it has to match the whole query.
The characters you actually need
Google’s article lists a short set of metacharacters, and they cover almost every filter worth building.
| Character | Meaning (per Google) | Typical use in a filter |
|---|---|---|
. | Any character | Bridging a variable letter or gap |
[…] | Character set | Spelling variants, such as optimi[sz]e |
* | Zero or more | An optional run of characters |
+ | One or more | At least one of something |
| | OR | Lists of words or brand spellings |
\d | Digit | Years, sizes, model numbers |
\s | Whitespace | Counting words in a query |
^ | Start of string | Queries that begin with a word |
The OR operator does the most work. Most useful filters are a list of alternatives, grouped in brackets and anchored where it matters. If you only learn one thing, learn to write (a|b|c) and to decide whether it needs a ^ in front.
Regex for Search Console: five patterns worth saving
These are patterns we wrote ourselves to illustrate the syntax. They are not drawn from any site’s data; test them against your own property before relying on them.
Question queries
Apply it on Queries with “Matches regex”. The ^ means the query has to start with a question word, and \b marks a word boundary, so “whatsapp” does not slip in under “what”. The result is a list of questions people ask that you already appear for, which is a ready-made brief for FAQ sections and new posts.
Non-branded queries
Apply it on Queries with “Doesn’t match regex”, replacing the made-up brand with your own name and its common spellings. Partial matching helps here: anything containing the brand anywhere is removed. What is left is the traffic you earn from search rather than from people who already know you, which is the number that matters when judging content.
One section of the site
Apply it on Pages. Because matching is partial, this catches every URL containing that path, so you can compare the blog with the rest of the site using the comparison mode. Swap in any directory your site uses.
Long-tail queries
Apply it on Queries. It reads as five or more groups of “a word followed by a space”, then one final word, anchored at both ends, so it matches queries of six or more words. Long queries usually carry specific intent, and they show you phrasing a page appears for that you may never have targeted on purpose.
Case-sensitive matches
The (?-i) prefix switches off the default case-insensitivity. You will rarely need it for queries, but it can matter when filtering page URLs on servers that treat case as significant.
Two mistakes to avoid
The first is the unescaped dot. Because . means any character, a Pages filter for example.com/shop would also match a URL with any other character in that position. It rarely changes the result, but when precision matters, write example\.com/shop so the dot is literal. The second is forgetting the anchors in an exclusion. A “Doesn’t match regex” filter for a short word removes every query containing those letters anywhere, including ones you meant to keep, so check what disappeared before trusting the remaining totals.
Keep the patterns you use in a note, so you are not rewriting them from memory each time. A pattern you have tested once is worth more than a clever one you typed in a hurry, and a shared note means everyone on the team filters the same way, so their numbers can be compared without first arguing about what each filter included.
Reading the results without fooling yourself
A filter changes what you see, not what happened. If question queries look strong this month, check the same filter against an earlier period before reading anything into it. Use the comparison mode, and remember that impressions have their own reporting quirks: our post on the Search Console impressions drop explains why a fall in impressions is not always a fall in visibility.
Filtered views also make CTR comparisons cleaner. Branded queries tend to inflate click-through rates, so strip them out before comparing your figures with any published study; our post on CTR by position covers why those studies disagree. And if you are trying to reconcile filtered Search Console numbers with sessions elsewhere, read Search Console vs Google Analytics first.
The limitation is in the data, not the regex. Search Console does not report every query it shows you for, so a pattern can only sort what Google chooses to report. A non-branded filter therefore shows non-branded queries you can see, not all non-branded traffic, and the totals will not add up to the unfiltered report. Treat filtered views as a way to compare groups of queries against each other and over time, not as complete counts. Within that limit, a few saved patterns will answer more questions than most dashboards. Start with the branded exclusion and the question filter, check them against your own property, and add others only when you have a question that needs one.
Frequently asked questions
How do you use regex in Google Search Console?
In the Performance report, add a Query or Page filter, choose “Matches regex” or “Doesn’t match regex”, and enter your pattern.
Which regex syntax does Search Console use?
RE2. Google’s help article states it directly, so features from other flavours, such as lookaheads, are not available.
Is the Search Console regex filter case-sensitive?
No, not by default. Prepend (?-i) to the pattern for case-sensitive matching.
Why does my filter match more than I expected?
Matching is partial, so the pattern can match anywhere in the query or URL. Anchor it with ^ and $ to match the whole string.
The takeaway Remember the two defaults, partial and case-insensitive, and save a branded exclusion, a question filter and a long-tail filter. They cover most needs.
