Search Console regex filters with worked examples
Read the conclusion first
A regex filter is useful only when it classifies the intended inputs correctly. Start with a small rule, test positive and negative examples, then inspect the returned rows. A rule being accepted does not prove it is accurate, and filtering does not reveal hidden queries.
Applicable conditions
Applies to brand variants, multiple query tasks, or directory filtering. The examples here are reviewable teaching inputs, not customer search data.
Before you open the report
The intended URL prefix, positive and negative test URLs, and GSC’s supported regex syntax.
Use one concrete URL or report first. Keep account credentials and private visitor data out of shared notes.
Steps and verification
Translate the analysis question into test inputs
Write the task before the expression: brand spellings, a directory, or a family of query phrases. Build a short list of inputs that should match and similar inputs that should not. For a teaching brand, ‘searchsignal’ and ‘search signal help’ might be positives; an unrelated ‘signal cable’ is a negative.
Decide whether a substring or the entire string should match. In an unanchored expression, a matching fragment anywhere in the query is enough. Keep ambiguous examples separate instead of broadening the rule until every row fits.
Use supported syntax and escape literal punctuation
A teaching brand expression is (searchsignal|search signal). To require the whole string, use ^(searchsignal|search signal)$. A directory example is ^https://example\.com/blog/ : the escaped dot means a literal dot, and the final slash distinguishes /blog/ from /blogger/.
GSC uses RE2 syntax and normally applies regex filters without case sensitivity. Confirm the current filter behavior and avoid unsupported lookaround or backreferences. Select matching versus not matching explicitly; changing that option reverses the intended group.
Audit the output and keep the rule version
Apply the rule to a completed report with the intended dimension and search type. Inspect included rows for false positives and a separate unfiltered sample for missed positives. An empty group can mean no visible matches, a wrong dimension, or an over-restrictive rule—not necessarily absent demand.
Save the expression, inclusion/exclusion choice, test inputs, dates and observed errors. When the rule changes, rerun earlier comparisons using the same version. Do not classify a trend using two different dictionaries, or infer anonymous queries from the residual total.
Common mistake: Copying complex expressions without checking output
Syntax being accepted only proves it can run, not that classification is accurate; you must manually spot-check positive and negative examples.
How to decide when you encounter different situations
Match your actual observation to a row before changing the page. If it does not match, collect the missing evidence first.
| What you see | Next step | How to confirm |
|---|---|---|
| False match on ordinary words | Add boundaries or adjust the brand dictionary | Save positive and negative examples |
| Directory rule matches /blogger/ | Clarify slash or path boundaries | Check final matched URLs |
| Rule passes but results are empty | Check the expression against actual queries | Do not treat empty results as zero demand |
A directory filter that does not include the wrong directory
Teaching scenario. Names, URLs and numbers illustrate the method; they are not customer or measured site results.
- What you observe
- Example rule: ^https://example\.com/blog/ . Positive: https://example.com/blog/post/ . Negative: https://example.com/blogger/ .
- What it establishes
- The escaped dot matches a literal dot; the slash after blog sets the directory boundary. A broad “blog” match can include unrelated paths.
- What to do next
- Apply the rule in the Pages filter and inspect returned URLs. Test an unexpected subdomain and a URL with blog only in a query parameter before using the result for a decision.
What counts as a checked result
Save the exact expression, include/exclude mode, filters and test set. A rule accepted by the interface is not evidence of accurate classification.
If a required check fails, keep the error and return to the matching decision branch. A blank record means unverified, not passed.
Leave with a checked result, not another vague instruction
- Your deliverable
- A named filter with positive and negative examples that were actually checked.
- Stop and resolve this first
- Do not classify demand from a filter that has not been tested for false matches.
Record missing evidence in the worksheet below. An unresolved test is useful information; a blank field is not a pass.
Checklist for this page
Fill in your own check results, then decide the next step. Blank means not yet verified, not normal. Content is saved only in the current local session and is not submitted to the server or AI.
Frequently asked questions
Can regex read anonymous queries?
No. Filtering does not remove GSC's privacy filtering or data limitations.
What if my accepted rule returns no rows?
Check the property scope, dates, include/exclude mode and an actual URL that should match. An accepted expression does not prove that matching data exists in that report.
Official materials and usage boundaries
This page provides operational judgment and checking methods, and does not show customer success cases. Calculation examples and request samples are teaching materials, not actual website metrics. Google's reports, conditions, and interfaces may change; please refer to the current official documentation.
Read the corresponding Google official documentationContinue with the relevant tool
Check the query wording in AISEO Site, then test your regex in native Search Console. A broad match is not proof that all queries share one task.
See how it works →