Google Search Console’s Performance report can filter queries and pages with Custom (regex). That is powerful — and easy to get wrong. Search Console uses RE2 syntax, not the full Perl/PCRE flavour many cheat-sheets assume. Lookaheads, lookbehinds and backreferences fail silently or reject the pattern. This free tool builds RE2-safe patterns from plain-English templates, flags constructs Search Console will not accept, and lets you paste sample queries or URLs to see what matches before you paste into GSC.
The builder above runs entirely in your browser. There is no login, nothing is sent to SiteLine, and it does not connect to your Search Console account. Copy the pattern into Performance → Add filter → Queries or Pages → Custom (regex).
When you outgrow one-off filters — brand vs non-brand month after month, folder comparisons across a 16-month archive, or asking an agent to slice the same cuts — SiteLine keeps a GSC history warehouse (about 16 months backfilled on connect, up to 25k rows/day/report, retained while you subscribe) next to cookieless analytics, with read-only MCP for agents. Start a 7-day trial (no card) · Pricing from $4.99/mo.
How to use the builder
- Pick a template (brand queries, question queries, URL folder, exclude list, or start blank).
- Fill in the plain-English fields — brand names, folder path, words to exclude.
- Read the generated pattern. The linter warns if you paste unsupported RE2 features (lookaround, backreferences, and similar).
- Paste a few real queries or page paths from an export and check Matches / Doesn’t match.
- Copy the pattern into Search Console. Use Matches regex or Doesn’t match regex as the secondary dropdown requires — do not try to encode “not” with a negative lookahead; RE2 and GSC do not support that.
How Search Console regex works (RE2)
Search Console documents that Performance Custom (regex) filters use RE2 syntax.
Matching behaviour
- Default match is a partial match: the pattern can succeed anywhere in the query or URL unless you anchor with
^(start) or$(end). - Matching is case-insensitive by default. Prepend
(?-i)if you need case-sensitive matching (useful for path segments that differ only by case). - For several alternatives, use
|inside a group:(foo|bar|baz). - To exclude a pattern, choose Doesn’t match regex in the filter UI. Do not invent a negative lookahead.
What RE2 does not support (common GSC footguns)
| Construct | Example | What to do instead |
|---|---|---|
| Lookahead / lookbehind | (?=…), (?!…), (?<=…), (?<!…) |
Use Doesn’t match regex, or split into two filters |
| Backreferences | \1, \2, (?P=name) |
Repeat the literal or alternative; do not “reuse” a capture |
| Possessive / atomic groups | (?>…), ++ |
Use ordinary +, *, ? |
| Conditional / recursive patterns | (?(…)…), (?R) |
Simplify the pattern; GSC is not a full parser |
If a pattern works in a PCRE tester and fails in Search Console, check for lookaround or backrefs first. This builder’s linter is aimed at those mistakes.
Anchors you will actually use
^blog/— page path that starts withblog/(after the host, depending how GSC shows the page string — paste a real row and test).how (to|do|can|does)— question-ish queries containing those phrases (partial match).(brand|brandname)— brand variants on Matches regex; non-brand via Doesn’t match regex with the same pattern.
Plain-English templates (copy patterns)
Replace the placeholders with your brand, folder, or word list. Test in the builder before pasting into GSC.
Brand queries (include)
Goal: queries that mention your brand or close variants.
(acme|acme tools|acmetools)
Use Matches regex. For non-brand traffic, use the same pattern with Doesn’t match regex — that is the supported way to exclude in Search Console.
Question / intent queries
Goal: who / what / how / why style queries (rough, high-recall).
^(who|what|when|where|why|how|does|do|can|is|are)\b
Partial match without ^ also works if you want the words mid-query: (who|what|why|how)\b. Tighten with the tester so you do not pull brand navigational noise you care about separately.
URL folder or section
Goal: pages under a path segment.
/blog/
Or start-anchored if your Page strings are path-only and consistent:
^/blog/
Always paste 5–10 real Page rows from Performance. GSC sometimes shows full URLs and sometimes paths depending on property type and view — the tester exists so you do not guess.
Multiple folders (OR)
(/blog/|/docs/|/guides/)
Exclude a noisy word or competitor (via UI)
Pattern:
(free|cheap|torrent)
Apply with Doesn’t match regex on Queries so those rows drop out. Do not write (?!free) — unsupported.
Exact query (whole string)
^exact phrase here$
Use sparingly; most Performance work wants partial or OR groups.
Case-sensitive path segment
(?-i)/API/
Matches /API/ but not /api/ when you need that distinction.
Step-by-step in Search Console
- Open Search Console → your property → Performance → Search results.
- Click + Add filter → Query or Page.
- Choose Custom (regex).
- Paste the pattern from this builder.
- Choose Matches regex or Doesn’t match regex.
- Apply. Compare charts and tables before vs after so a too-broad
|does not empty the report.
Filters apply to the live ~16-month window Google still holds. They do not restore days that have aged out of Search Console — see When does Google delete Search Console data? and the GSC data expiry calculator.
When a free regex filter is not enough
Regex in the UI is excellent for one investigation. It is weak as a system of record:
- You retype the same brand pattern every month.
- Exports stay capped and manual (export more than 1,000 rows).
- Month-17 year-over-year is empty if you never archived the prior year (year-over-year Search Console).
- Agents and notebooks cannot reliably reuse ad-hoc UI filters.
SiteLine’s job on that problem: connect once with webmasters.readonly, backfill about 16 months of what Google still holds (capped by property age), keep importing up to 25k rows/day/report, retain imported days while you subscribe, and query the warehouse over MCP without write tools. Cookieless product analytics sits beside the GSC archive in the same product. Compare options in Best Google Search Console history tools. Setup: Connect Google Search Console to SiteLine.
Start free for 7 days — no card · See pricing from $4.99/mo · MCP overview · Register with MCP intent
Related free tool: GSC data expiry calculator · All free tools
FAQ
Does Search Console support full PCRE regex?
No. Performance Custom (regex) uses RE2. Features that need backtracking — lookaround and backreferences especially — are not supported. Prefer simple groups, |, anchors, and the Doesn’t match regex filter option.
Why does my regex work in an online tester but not in GSC?
Most online testers default to PCRE or JavaScript flavour. If the pattern uses (?!…), (?=…), or \1, Search Console will not behave the same. Rebuild with RE2-safe alternatives in this tool, then retest.
Should I use Matches or Doesn’t match regex?
Matches regex keeps rows that contain a match (partial by default). Doesn’t match regex keeps rows that do not. Use the second for exclusions instead of negative lookahead.
Are regex filters case-sensitive?
By default, no. Add (?-i) at the start of the pattern for case-sensitive matching from that point.
Does this tool need access to my Search Console account?
No. It only builds and tests strings in your browser. It never calls Google and does not send your samples to SiteLine.
Can regex recover Search Console data older than 16 months?
No. Filters only apply to days Google still serves. Once a day ages out of the ~16-month window, neither the UI nor the API returns it. Archive while the day still exists — expiry calculator, deletion guide.
How is SiteLine different from pasting regex in GSC?
GSC regex slices the live window. SiteLine stores that window (and later days) in a hosted archive — ~16-month backfill, 25k rows/day/report, retention while subscribed — with cookieless analytics and read-only MCP. Trial is 7 days, no card; plans from $4.99/mo.