Google Search Console is the only keyword tool whose data is actually yours — real queries, real impressions, real positions, from your site’s own record. And most businesses use perhaps five percent of it: they open the Performance report, glance at the top twenty queries sorted by clicks, recognize their brand name and their two biggest services, and close the tab. The other ninety-five percent — the thousands of long-tail queries where buying intent hides, the questions prospects ask on the way to hiring someone, the near-miss commercial terms sitting at position 9 one push from page-one traffic — stays buried, because the default interface can only filter one phrase at a time, and nobody has time to run two hundred single-phrase filters.
Regex filtering is the key that opens the rest. Since Search Console added regular-expression support to its query and page filters, one well-built pattern can slice the entire query set by intent: every query containing any hiring signal (cost|price|near me|best|hire|quote) in one view; every question (^(how|what|why|can|should)\b) in another; every city you serve, every service you offer, every comparison someone is making — each as a single reusable filter. Combined with the report’s position and impression columns, the patterns turn raw query logs into a prioritized opportunity list: commercial terms with impressions but weak positions, questions with demand but no dedicated answer, services people search that your site barely mentions.
This guide is the working manual: the regex syntax subset that Search Console actually uses (RE2 — and the quirks that make patterns silently fail), a library of copy-adaptable intent patterns for service businesses, the three analysis workflows that convert filtered views into content and optimization decisions — striking-distance mining, question harvesting, and cannibalization detection — the export-and-spreadsheet layer for anything the interface can’t do, and the recurring-audit cadence that keeps the whole thing a monthly hour instead of a quarterly archaeology dig.
Search Console’s regex filters turn its query report from a top-20 glance into an intent-mining engine. Mechanics: choose Custom (regex) in the query filter; syntax is RE2 (no lookaheads/lookbehinds), patterns are partial-match by default and case-sensitive unless you build otherwise — use (?i) for case-insensitivity and ^…$ anchors only when you truly mean whole-query. The working patterns: commercial intent — (?i)(cost|price|pricing|quote|estimate|hire|near me|best|top|affordable); questions — (?i)^(how|what|why|when|which|can|should|do|does|is|are)\b; your geography — alternation of served cities; your services — alternation of service terms; comparisons — (?i)\b(vs|versus|compare|alternative)\b. The workflows: striking distance (commercial pattern + position 5–15 + real impressions = the optimization queue), question harvest (unanswered questions = the content plan, FAQ blocks, and AEO fodder), cannibalization check (one query pattern → Pages tab: multiple pages splitting impressions = a consolidation decision). Export anything serious — the UI caps rows — and rerun the saved pattern set monthly.
The Mechanics: RE2, Partial Match, and the Quirks That Silently Break Patterns
In the Performance report, the query (and page) filter offers Custom (regex) alongside contains/exact modes, with match and no-match directions. Five facts prevent ninety percent of regex-filter frustration:
- The engine is RE2 — Google’s regex library. Practical consequence: no lookaheads, no lookbehinds, no backreferences. Patterns copied from generic regex tutorials that use
(?=…)fail — usually silently, returning nothing. Everything you need is achievable with alternation, character classes, anchors, and quantifiers. - Matching is partial by default.
plumbmatches “plumber,” “plumbing cost,” “emergency plumbers dallas.” You don’t need.*wrappers — and adding^…$anchors means only whole queries matching the pattern, which is almost never what you want except in question-start patterns (^how\b) and exact-set filters. - Case sensitivity is on by default. Queries arrive lowercase overwhelmingly but not universally; prefix patterns with
(?i)as a habit and never think about it again. - Word boundaries save you from substring surprises.
(?i)\bac\bmatches “ac repair” without matching “package” or “replacement”;vswithout boundaries matches “canvas.” Use\baround short tokens, always. - There’s a length cap on the pattern (a few thousand characters — generous, but city-list alternations on large service areas can hit it; split into two filters or trim to the cities that matter).
The Pattern Library for Service Businesses
| Intent slice | Pattern (adapt the vocabulary) | What it surfaces |
|---|---|---|
| Commercial / hiring intent | (?i)(cost|price|pricing|quote|estimate|rates|hire|near me|nearby|best|top|affordable|cheap|licensed|emergency|same day) | Queries from people ready to spend — the primary mining vein; expect it to be a minority of queries and a majority of value |
| Questions | (?i)^(how|what|why|when|where|which|who|can|should|do|does|is|are|will)\b | The research layer: content plan, FAQ blocks, featured-snippet and AI-answer targets |
| Comparisons | (?i)\b(vs|versus|compare|comparison|alternative|better than|or)\b | Decision-stage prospects weighing options — including yours against competitors |
| Your services | (?i)(water heater|drain|sewer|repip|slab leak|tankless) — your service vocabulary | Demand per service line; cross with commercial pattern for the money map |
| Your geography | (?i)(dallas|plano|frisco|richardson|allen|mckinney) — your served cities | Geo demand distribution — the query-side companion to grid tracking, and the evidence layer for which city pages to build |
| Brand isolation | Your brand + misspellings: (?i)(mantas|mantasauk|mantas auk) — used as doesn’t match to see non-brand performance honestly | The single most clarifying filter in the tool: your real organic acquisition with the brand halo removed |
| Urgency | (?i)(emergency|24/7|24 hour|same day|now|today|weekend|after hours) | The highest-converting slice in trades — and a landing-page and LSA strategy input |
| DIY / job-seeker exclusions | (?i)(diy|yourself|salary|jobs|hiring|career|course|license requirements) as doesn’t match, or matched to measure the irrelevant tail | Cleans analysis views — and doubles as the negative-keyword research from the search-terms audit, on free organic data |
Search Console doesn’t save custom regex filters between sessions, which is how regex adoption dies in most teams: someone builds good patterns once, loses them, never rebuilds. Keep a plain-text pattern file (or a row in your reporting doc) with each named pattern, its purpose, and the date last updated — and treat the vocabulary alternations (services, cities, brand variants) as living lists updated when the business changes. Bonus: the same patterns work in Looker Studio’s regex filters on the Search Console connector, which is where monthly reporting on these slices belongs once the patterns stabilize — build once, filter forever.
The Three Workflows That Turn Filters Into Decisions
1. Striking-Distance Mining (the optimization queue)
Apply the commercial-intent pattern (brand excluded), set a date range of 3–6 months, and sort the surviving queries by impressions. Now read positions: queries at position ~5–15 with meaningful impressions are your striking-distance list — demand proven, ranking almost-there, and improvable with on-page work rather than new content: title/heading alignment to the query’s exact language, a content section that actually answers it, internal links from strong pages with matching anchors (the equity-routing discipline), and refreshed depth where competitors out-answer you. Rank the queue by impressions × commercial weight, work the top ten, re-measure in six weeks. This single workflow, run monthly, out-produces most keyword-tool subscriptions — because it optimizes toward demand you’ve already demonstrated you can almost win.
2. Question Harvesting (the content and AEO plan)
Apply the question pattern; export; cluster the results by topic. Each cluster gets a verdict: answered well (a page exists and holds a strong position — leave it), answered poorly (impressions land on a page that only glances at the question — add the section or FAQ entry), or unanswered (impressions with terrible positions or landing on irrelevant pages — a content-plan item, pre-validated by your own demand data). Questions your prospects ask are also precisely what AI answer engines assemble responses from — the question harvest feeds FAQ schema, dedicated answer sections, and the AEO layer in one motion.
3. Cannibalization Detection (the consolidation trigger)
Filter to a single important query family (a tight service pattern), then switch to the Pages tab: multiple pages splitting that family’s impressions — especially with none holding a strong position — is the cannibalization signature. The verdict logic is content architecture, not tags: differentiate the pages’ intents, merge-and-301 the redundant one, or fix the internal links that vote for the wrong page — the full adjudication is in the canonical guide’s tool map. Regex made the detection a two-minute check per query family; run it on your top ten families quarterly.
Three data realities keep regex findings honest. First, the interface caps visible rows (1,000 in the table) and the query report omits rare/anonymized queries entirely — your filtered view is a large sample, not a census; export via the UI or API for serious analysis, and treat ‘total impressions under this filter’ as directional. Second, the position column is an average across all impressions in range — a ‘position 8’ can be position 3 in your city and position 30 statewide averaged together; segment by country/device (and remember local-pack dynamics live largely outside this report) before treating the number as a rank. Third, aggregation changes when filters change: clicks and impressions by query and by page don’t sum identically across views, so compare like with like — trend the same filtered view over time rather than reconciling different views against each other. None of this weakens the workflows; it just means regex slices are for finding and prioritizing opportunities, and verification happens on the page and in the trend line, not by staring harder at an averaged number.
The Monthly Hour
- Non-brand health check (5 min): brand-excluded view, clicks and impressions trend vs prior period — the honest topline.
- Striking-distance refresh (20 min): commercial pattern, re-rank the queue, pick the month’s optimization targets, log last month’s targets’ movement.
- Question harvest delta (15 min): new questions since last run — usually a trickle that feeds the FAQ backlog continuously instead of a quarterly dump.
- One cannibalization spot-check (10 min): rotate through your query families.
- Pattern maintenance (5 min): new services, new cities, new competitor names into the alternations; date the file.
5 Common Regex-Filter Mistakes
- Tutorial regex in an RE2 tool. Lookaheads fail silently; rebuild with alternation and boundaries.
- Anchoring everything.
^…$turns a broad intent slice into an exact-match trickle — partial match is the default for a reason. - Unbounded short tokens.
vsmatching “canvas,”acmatching “replacement” —\bor noise. - Reading averaged position as rank. Segment before believing the number; optimize against the trend, not the artifact.
- One heroic session, no saved patterns. The value is the recurring hour on a stable pattern set — the file outside the tool is what makes it recurring.
Frequently Asked Questions
Where exactly do I find the regex option in Search Console?
Performance report → the ‘+ New’ filter bar above the charts → Query (or Page) → in the filter dialog, the dropdown that defaults to ‘Queries containing’ also offers ‘Custom (regex)’ — select it, and note the second dropdown that toggles between ‘Matches regex’ and ‘Doesn’t match regex,’ because the negative direction powers half the useful workflows (brand exclusion above all). The same custom-regex option exists on the Page filter, which is how you slice performance by URL pattern — all city pages (/locations/ or your city-slug alternation), all blog posts, all service pages — and crossing a query regex with a page regex is where the sharper questions get answered: commercial queries landing on blog posts (content that should hand off to service pages), question queries landing on service pages (FAQ sections earning their keep). Two interface notes: filters don’t persist between sessions (keep the pattern file), and the regex applies within the other active filters (date range, country, device), so build the view from the outside in — range and geography first, then the pattern.
My regex returns nothing but I know matching queries exist. What's wrong?
Run the standard diagnostic sequence. First, RE2 compatibility: any lookahead ((?=), lookbehind ((?<=), or backreference (\\1) makes the pattern invalid — and the interface’s error signaling is easy to miss, so a ‘working’ filter may simply be a rejected one; rebuild using alternation and character classes. Second, case: matching is case-sensitive by default and while most queries are lowercase, your pattern might not be — prefix (?i) universally. Third, over-anchoring: ^plumber repair$ matches only that exact whole query; drop the anchors unless whole-query matching is genuinely the intent. Fourth, escaped characters: literal dots, pluses, and parentheses in your vocabulary (service names, brand variants) need escaping (\\.), and an unescaped special character can change the pattern’s meaning without erroring. Fifth, the data reality: the query you ‘know exists’ may be below the anonymization threshold or outside the date range — test the pattern logic against a query you can see in the unfiltered table first, then widen. And keep a regex tester handy (one that supports RE2 or at least flags lookarounds) for anything beyond simple alternation — thirty seconds of testing beats ten minutes of squinting at an empty report.
What's a realistic example of finding a commercial opportunity with this method?
The archetypal find, pattern by pattern: you run the commercial regex with brand excluded over six months, sort by impressions, and a query like ‘tankless water heater installation cost’ surfaces with, say, thousands of impressions at average position 9 — page two, close enough to touch. The Pages tab (query filter still applied) shows the impressions landing on a general water-heater service page that mentions tankless in one paragraph and pricing nowhere. The intervention writes itself from the evidence: a dedicated section (or page, if the demand cluster is deep — the question harvest will show related queries like ‘how much does tankless installation cost’ and ‘tankless vs tank water heater’) that actually answers the cost question with honest ranges, a title/H2 using the query’s language, FAQ schema on the question variants, and two or three internal links from your strongest related pages with matching anchor text. Six weeks later the striking-distance re-run shows the position moved — or it doesn’t, and the query graduates to a content-gap item needing a fuller page. The method’s honest advantage isn’t magic; it’s that every step was driven by demonstrated demand (your impressions) and a diagnosable gap (your page), instead of a keyword tool’s estimate and a hunch.
Can I use these regex patterns anywhere else besides the Search Console interface?
Yes — and the pattern file compounds across the stack. Looker Studio: the Search Console connector supports regex in filters and calculated fields (REGEXP_MATCH/REGEXP_CONTAINS), which is where the monthly slices belong once stable — a standing dashboard page showing non-brand trend, commercial-slice trend, and question-slice trend, no manual filtering required. The Search Console API (or its bulk-export-to-BigQuery pipeline): pulls the full query data past the interface’s row caps, and BigQuery’s REGEXP functions run the same intent slicing over the census rather than the sample — the upgrade path when the long tail becomes strategically interesting. Google Analytics 4 explorations accept regex on page paths and other dimensions, letting the page-side patterns (your /locations/ and service-URL alternations) carry over for behavior analysis. Spreadsheets: RE2-flavored regex functions (REGEXMATCH/REGEXEXTRACT in Google Sheets) apply the same patterns to exported data for clustering and tagging. Even Google Ads scripts and some SEO crawlers speak compatible regex. The practical takeaway: because nearly all of Google’s ecosystem runs RE2, one honest afternoon building your vocabulary alternations pays out across every tool you touch — and one shared pattern file keeps them all in sync.
How is this different from just paying for a keyword research tool?
Different data answering different questions — the mature setup uses both, with Search Console doing the jobs it’s uniquely qualified for. What GSC-plus-regex does better: prioritizing optimization (real impressions at real positions on your real pages beats estimated volume for deciding what to improve this month), discovering the exact language your market uses (queries as typed, not lemmatized into tool-speak), finding cannibalization (only your own data can show your pages splitting a query), measuring intervention results (the same filtered view, trended), and doing it all free with no sampling of intent — every slice is your actual demand. What third-party tools do that GSC can’t: show demand you’ve never touched (queries where you have zero impressions are invisible in GSC — the tool’s blind spot is precisely the whitespace keyword research exists to map), competitor visibility (whose pages rank for what), volume estimates for planning net-new content areas, and SERP-feature landscapes. The failure mode to avoid is using either for the other’s job: keyword-tool estimates driving this month’s on-page priorities (over your own striking-distance evidence), or GSC’s existing-demand view convincing you no whitespace exists. The workflow order that works: GSC regex for exploiting what you’ve earned; tools for scouting what you haven’t.
Sitting on a query goldmine you’ve read twenty rows of?
We’ll build your pattern library — services, cities, intent slices — run the striking-distance and question harvests on your actual data, and hand you the prioritized queue plus the monthly workflow that keeps it producing.
Get a Query Mining Audit Explore AEO Services