Search Console Regex Filters: 20 Patterns Worth Saving

Search Console's Performance report has carried a regular-expression option on its Queries and Pages filters for years, and Google's help centre documents it in a few dozen lines: the engine is RE2, matching is partial unless you anchor the pattern, and matching ignores case unless you switch that off. Those three rules are the whole specification. What the help centre does not give you is a working set of patterns, and most of the ones circulating on marketing blogs were never run through the engine Google actually uses.

This reference fixes that. Twenty patterns, grouped by the question they answer, with what each one finds, an example of a matching query or URL, and the mistake that makes it match too much or too little. Every pattern was compiled and run against sample strings in Google's own open-source RE2 engine on October 9, 2026, so a pattern printed here will not be rejected by the filter for using a feature RE2 does not support.

It is written for the site owner or content editor who opens the Performance report once a week and wants a saved answer to "which questions do people ask us" or "how is the blog doing versus the product pages", and for the SEO who already uses the filter and wants the edge cases written down. If your traffic has just fallen and you are here to find out why, start with our step-by-step traffic-drop diagnosis and come back for the patterns that isolate each page group.

Open the Performance report for Search results, click the filter row's add button, and choose either Queries or Pages. Each of those two dimensions offers the same three ways to narrow the data. Google's filtering article lists them as a containing filter, a not-containing filter and a custom regex filter. The containing filter takes one substring and matches it exactly apart from case, spaces included. The regex filter takes a pattern and offers two directions: the default matches-regex, and a doesn't-match-regex option that returns everything except what the pattern catches.

The practical difference is breadth. A containing filter answers one question: does this query include the word "pricing". A regex answers a family of questions at once: does this query include "pricing", "price", "cost" or "cheap", as whole words, without also catching "costume". Google's own suggested form for the simplest case is a parenthesised list separated by vertical bars, and most of the patterns below are elaborations of that one idea.

One example of where the containing filter is the wrong tool: a site with a blog at /blog/ and a product catalogue at /product/ wants to compare the two groups. "URLs containing blog" works for the first and fails for the second, because a product called "blog-planner-notebook" lands in both. The regex version anchors on the host and the first path segment and the ambiguity disappears. One failure case the other way: a regex that is only a plain word, with no anchors or boundaries, behaves exactly like the containing filter and gains nothing but complexity. Reach for regex when the question has an "or", a position, or a shape in it.

Google's filtering article gives three statements under "Regular expression details", and every pattern in this reference depends on them. First, the syntax is RE2, the open-source engine Google maintains on GitHub. Second, default matching is a partial match: in Google's words, your regular expression can match anywhere in the target string unless you use the start-of-string or end-of-string anchors. Third, matching is not case-sensitive by default, and you prepend (?-i) to make it case-sensitive. Google's example is that (?-i)AAA matches a URL ending in uppercase AAA and not one ending in lowercase aaa.

The implied rule is the one that trips people who learned regex elsewhere. RE2 is deliberately a smaller language than Perl, PCRE, Python or JavaScript regex, and it leaves out the constructs that can make a pattern slow. The RE2 syntax page lists each feature it omits and marks it "NOT SUPPORTED". The ones that matter for Search Console are lookahead and lookbehind in all four forms, backreferences in every notation, possessive quantifiers, atomic groups, and the \Z end-of-text escape. If a pattern from a tutorial uses any of these, the filter will not accept it.

Why it matters in practice: the most common tutorial pattern for "queries that contain A but not B" uses a negative lookahead, and it will never run in Search Console. The alternative is two conditions, one matching A and one not matching B: the Search Console API combines an includingRegex and an excludingRegex filter on the same dimension, and Google's help pages do not say whether the report UI accepts both at once, so check your property. A failure case on the other side: \b is supported, but RE2 defines it at an ASCII word boundary, so a pattern like \bcafé\b may not behave as expected because the accented character is not an ASCII word character. For non-English queries, prefer explicit spaces or anchors over word boundaries.

The first group reads intent from the words people type. Question queries are a common first request from editors, because they tell an editor which FAQs the archive already ranks for and which it is missing. The pattern anchors a list of question words to the start of the query and closes it with a word boundary so "how" does not match "however" and "is" does not match "island". The how-to pattern is a narrower cut of the same idea for instructional content.

The remaining six catch comparison shopping, list-seeking, local intent, price intent, a date modifier and navigational queries for an existing customer. Each one is a whole-word alternation. The year pattern deserves a note: \b202[4-7]\b matches 2024 through 2027 as standalone tokens, which is what you want when checking whether a refreshed guide is picking up the current year's searches, and it will need its range widened in 2028.

One failure case runs through the whole group. Without the word boundaries, "free" catches "freedom", "top" catches "topic", "vs" catches "versatile", and the filtered totals are quietly wrong. The pitfall column names the specific false match each boundary prevents, because that is the test to run after you edit a pattern for your own vocabulary.

The brand split is the oldest use of this filter and the one Google has partly automated. Its dimensions page documents a branded and non-branded queries filter that separates data on whether the search term included your brand name. Three caveats come with it in Google's own text: the filter is not available for sites with a low number of impressions, it provides a 16-month history starting from its introduction in March 2025, and some queries might be incorrectly identified as branded or non-branded. Google also says the classifications are for information only and do not affect ranking.

So why keep a regex version? Because the regex is yours. A small site below the impressions threshold has no built-in switch at all. A larger site with a brand name that is also a common word, or a portfolio of product names, gets to decide what counts. The pattern below is a whole-word alternation of the brand, its common misspelling and its two-word form; replace "acme" with your own list. Run it once as matches-regex for the brand view and once as doesn't-match-regex for the non-brand view, and every visible query lands in exactly one of the two by construction, which the automated filter does not promise. The totals still will not sum to the unfiltered figure, for the reason in Section 07.

The failure case is a brand that appears inside other words. A company called "Ion" cannot use ion without boundaries, and even with them it will catch "ion exchange". The fix is to list the brand's real query forms, "ion software", "ion login", "ion pricing", rather than the bare word, which is what the second pattern does.

Some useful filters say nothing about vocabulary and everything about form. The long-tail pattern counts words: a run of at least four "non-space then space" groups followed by one more word means five words or more, anchored at both ends so the count is of the whole query. Change the number inside the braces to change the threshold. This is the cleanest way to see whether a site's growth is coming from long, specific searches or short head terms. The anchors matter once you add an upper limit, such as {2,3} for three to four words, because Google's partial-match default would otherwise find four words inside a longer query.

The non-ASCII pattern matches any query containing a character outside the basic ASCII range, which on an English-language site is a fast way to find traffic from other languages or from accented brand names, and on a multilingual site a way to split by script. The spelling-variant pattern shows the general trick for a term people write three ways: an optional hyphen-or-space between the two parts, and the one-word form as a second alternative.

Failure cases: the word-count pattern treats any run of whitespace as one separator, but a leading or trailing space makes the anchored pattern miss the query entirely. And the non-ASCII class catches typographic quotation marks and em dashes too, so a handful of English queries will land in it; sort by impressions and the genuine other-language rows will dominate.

The Pages dimension holds full URLs, which Google's dimensions page defines as the final URL linked by a Search result after any redirects. Because they are full URLs, the strongest patterns anchor on the scheme and host and then name a path. The blog-subfolder pattern is the model: it matches everything under /blog/ on one host and nothing under /blogs/ or on a staging host. The product-template pattern goes the other way and matches only the leaf page of a section, excluding its sub-pages such as reviews.

Three more find URL shapes that usually should not be earning impressions at all: tracking parameters, pagination, and date-stamped archive paths that were meant to be redirected. The file-type pattern finds PDFs and office documents that rank, which is a routine surprise on business sites and a reason to give the content an HTML home. The parameter pattern is one character, an escaped question mark, and it is the quickest way to see whether Google is indexing parameterised duplicates of canonical pages.

Failure cases are mostly about escaping. A dot in a hostname must be written \. or it matches any character, which is harmless on a host filter and dangerous on a file-type filter, where .pdf unescaped also matches "/pdf-guide". The question mark must be escaped for the same reason, since a bare ? is a quantifier. And remember partial matching: a product pattern without the end anchor matches every URL that merely passes through the section.

A regex filter is only as complete as the rows it runs over, and Google's dimensions page is candid that the rows are not complete. Two statements matter. On anonymized queries: some queries are omitted to protect user privacy, and they are included in chart totals unless a query filter is applied. On truncation: due to internal limitations, Search Console stores and shows only the most important data rows, and the most complete list of queries is available through bulk data export.

The consequence for any report built on these patterns is that a filtered total is not a share of the unfiltered total. Add a regex on Queries and the chart's anonymized share drops out, so a brand view and a non-brand view will not sum to the all-queries figure you saw before filtering. Say so in the caption of any chart you share, or compute shares only between two filtered views. Google's filtering and troubleshooting pages say the same applies to page filters: filtering by query or URL can change the totals, through truncation and the omitted anonymized queries.

One more limit is structural rather than documented: the regex applies to one dimension at a time. There is no pattern that joins a query to a page. For "question queries landing on blog pages", apply the question pattern on Queries and the blog pattern on Pages as two filters, which the report supports. The router below says which tool to reach for in each situation, including the cases where the regex is the wrong answer. For the related question of how the AI Mode and follow-up query rows behave under a filter, see our note on AI Mode follow-up queries and data quality.

Search Console can reject a pattern RE2 does not support, and it cannot tell you a valid pattern is matching the wrong rows. Both problems are cheap to catch outside Search Console, because the engine is open source. The google-re2 package on PyPI wraps the same RE2 library, and four lines are enough to compile a pattern with Google's default case handling and assert what it should and should not match. That is the check every pattern on this page passed.

The method we used: for each of the 20 patterns, a list of strings that must match and a list that must not, including the specific false match named in its pitfall column. The script compiles the pattern with the (?i) prefix, which mirrors Search Console's case-insensitive default, and fails if any assertion fails or if RE2 rejects the pattern. All 20 passed, with 0 compile failures and 0 wrong matches, on October 9, 2026. Any pattern you adapt for your own brand, host or vocabulary deserves the same minute, and the failure to look for is a boundary or anchor you removed while editing.

Two things the test cannot do. It does not know your data, so it cannot tell you a pattern matches nothing on your site; sort the filtered table by impressions and check the top rows by eye. And it does not reproduce Search Console's row truncation, so a pattern that is correct can still return fewer rows than the site really has. If you want this set extended for a specific property, or the patterns turned into a standing weekly report, that is the kind of work our agentic SEO service builds and maintains. The related multimodal search-type filter and the repaired links report are covered separately.