Build a Search Console query filter
Create an RE2-compatible expression for branded, non-branded, product, or topic query groups.
GSC Regex Builder & Tester
Free, no signup. Catch PCRE syntax GSC cannot run, then test a safe RE2 pattern locally. Put the pattern on line one and one query per line after it.
RE2 rejects lookarounds, backreferences, atomic groups, and possessive quantifiers. Separate data sets with a line containing ---. Files never leave your browser.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Runs entirely in your browser — nothing you paste is uploaded or stored. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Rate this tool
How to use it
- Write the regular expression on the first line. Do not wrap it in slashes.
- Paste one Search Console query on each following line.
- Select Analyze. Review syntax issues first, then the true/false match beside every query.
- Copy a clean pattern into a Search Console custom query filter. Recheck the filtered total before using it in reporting.
Example output Example data
This static example uses ^(how|what)\b against three illustrative queries. It shows the exact result shape; it is not connected to a Search Console property.
Syntax issues0
how to audit redirectsMatch: true
what is crawl budgetMatch: true
technical seo toolsMatch: false
What you get
Issues lists every incompatible token the linter recognizes, its character index, why RE2 rejects it, and a safer rewrite direction. An empty array means no known lint issue was found; it is not a guarantee that a complex pattern expresses your intended audience.
Match is the browser test result for that query. When the pattern has any lint or compile issue, all test rows return false rather than pretending the broken pattern ran successfully.
How it works
The linter scans for unsupported RE2 constructs including lookarounds, numeric and named backreferences, atomic and conditional groups, possessive quantifiers, and \Z. It also asks the browser regex engine to catch unbalanced brackets and other compile errors. Only a lint-clean pattern is applied to the supplied queries, with case-insensitive matching.
Features
- Specific explanations and rewrite directions for common PCRE-to-RE2 mistakes.
- Per-query match results for a realistic list, entirely in the browser.
- Support for ordinary RE2-compatible anchors, groups, alternatives, classes, and quantifiers.
Limitations
- This is a compatibility linter and local tester, not Google's production RE2 runtime.
- JavaScript and RE2 differ at some Unicode and escaping edges; validate the final filter in Search Console.
- The tool does not connect to GSC, estimate matched clicks, or generate exclusion filters automatically.
Frequently asked questions
What regex syntax does Google Search Console support?
Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. uses RE2 syntax. It supports common groups, alternation, character classes, anchors, and quantifiers, but not lookarounds, backreferences, atomic groups, conditional groups, or possessive quantifiers.
Why does a regex work in another tester but fail in Search Console?
Many general-purpose testers use PCRE or JavaScript regex. Those engines accept features that RE2 deliberately excludes. This tool flags the known incompatible constructs before testing the pattern.
Are matches case-sensitive?
No. This tester applies the pattern case-insensitively, matching the behavior expected for Search Console query filtering.
Does this tool send my queries anywhere?
No. The pattern and query list are processed in your browser and are not uploaded.
Can I use negative lookahead to exclude branded queries?
No. RE2 does not support lookahead. Use a Search Console exclude filter separately, or write an inclusive pattern for the terms you want to keep.
Feature requests for Gsc Regex Tester
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Catch unsupported regex syntax
Lint patterns for constructs that Search Console's RE2 engine does not support before saving a filter.
Test against real query samples
Paste a query list and inspect exactly which rows the expression includes or excludes in the browser.
Refine reusable reporting segments
Iterate on a pattern until it cleanly represents a reporting cohort you can reuse in GSC.
Watch the full workflow
GSC Regex Builder & Tester walkthrough
Read the transcript
GSC Regex Builder & Tester
A regex can work in a general tester yet fail in Search Console because the engines differ. I’ll show you how to use presets, format the input, test a valid pattern, interpret true and false rows, catch unsupported P-C-R-E syntax, handle brand filters, understand limitations, and validate the final filter safely in G-S-C.
Step 1
Search Console uses R-E-two syntax, which supports ordinary groups, alternatives, character classes, anchors, and quantifiers but rejects several P-C-R-E features. This browser tool lints known incompatibilities and tests the remaining pattern against your own query list.
Step 2
Use it to segment question queries, comparisons, long-tail searches, branded traffic, or recurring product terms before creating G-S-C reports. Testing real query examples helps reveal patterns that are technically valid but too broad, too narrow, or poorly anchored.
Step 3
Choose a question, comparison, long-tail, brand, or non-brand preset. Brand and non-brand use the same generated brand pattern; Search Console’s Include or Exclude control creates the difference. Add every important brand spelling before inserting the pattern.
Step 4
Put the regex on line one without surrounding slashes, then add one query per following line. Select Analyze. This example anchors how or what at the beginning, uses a word boundary, and tests mixed matching and nonmatching queries entirely in the browser.
Step 5
The output lists syntax issues and per-query match booleans. An empty issues array means no known problem was detected. It does not prove that the regex captures the audience you intended, so inspect both true and false examples.
Step 6
Matching is case-insensitive, so the uppercase how example can still match. Anchors and word boundaries remain important: they control position and token edges, while case folding only removes capitalization differences.
Step 7
This second pattern uses negative lookahead to exclude a brand. R-E-two does not support lookahead, so the linter reports the construct and all query tests return false. That avoids pretending a broken Search Console pattern ran successfully.
Step 8
The linter also checks numeric and named backreferences, atomic and conditional groups, possessive quantifiers, lookbehind, and backslash Z. The browser compile check catches unbalanced brackets and similar syntax errors before any rows are marked as matches.
Step 9
For brand segmentation, enter names and common variants, insert the generated pattern, and test real queries. Use it with an Include custom regex for branded traffic or an Exclude custom regex for non-brand traffic. Negative lookahead is neither needed nor supported.
Step 10
Features include common preset patterns, brand-term generation, copy support, specific explanations for incompatible tokens, rewrite direction, case-insensitive per-query tests, ordinary R-E-two constructs, and fully local processing of the pattern and query list.
Step 11
This is a compatibility linter and browser tester, not Google’s production R-E-two runtime. JavaScript and R-E-two can differ at Unicode and escaping edges. The tool does not connect to G-S-C, estimate matched clicks, or automatically build exclusion filters.
Step 12
Copy the lint-clean pattern, paste it into the intended G-S-C custom query filter, and confirm Include versus Exclude. Review examples from both sides and compare the filtered clicks and impressions with expectations. Save the tested query set so future regex edits can be checked consistently.
Lint locally—validate in Search Console.
Copy only a lint-clean pattern, choose the correct Include or Exclude filter in Search Console, and inspect sample queries plus the filtered total. Recheck after editing the regex. Local true and false results are useful evidence, but the production G-S-C filter remains the final validation step.
Common issues & how to fix them
- Warning Regex misses an intended query Fix: Adjust the pattern to include the missed query while rerunning the full intended and excluded test set.
- Warning Regex matches an unintended query Fix: Add a boundary, exclusion, or more specific token so the unintended query no longer matches.
- Warning Regex is broader than intended Fix: Replace broad wildcards with explicit terms and boundaries that describe only the intended query set.
- Warning Regex anchors exclude valid queries Fix: Remove or reposition ^ and $ anchors so they match the intended whole-query or substring behavior.
- Information Case handling changes the match set Fix: Normalize case or enable case-insensitive matching when capitalization should not change membership.