Google Search Console Hacks: Regex Filters That Reveal What Searchers Really Want

Direct answer: Google Search Console's Performance report hides its best feature behind one dropdown — Custom (regex). With a few copy-paste patterns you can split your search traffic into questions, buyers, brand fans, long-tail searches and fading pages, instead of scrolling one giant query list. This guide gives you eight of those patterns, explains what each one reveals, and tells you exactly what to do with the results. The first one fixes a viral image that is going around: its question regex works, but it misses real question words like did, was, were, has, have and am. The improved version is below, and it is the one you should paste.

The viral regex, fixed

The image shows a chat assistant answering a request for a regex that filters Search Console queries to only questions. Its answer is a pattern that matches queries starting with a question word:

^(who|what|why|how|when|where|which|can|does|do|is|are|should|will|could|would)\b

That pattern is genuinely useful, and it is correct as far as it goes. But it leaves out question words people type every day. "Did my parcel arrive?", "Was the plugin updated?", "Were prices reduced?", "Has anyone tried this tool?", "Have you fixed the bug?", "Am I eligible?" — none of those start with a word in the image's list, so all of them slip through the filter. Here is the improved version, with the missing words added:

^(who|whom|whose|what|why|how|when|where|which|can|could|may|might|must|shall|should|will|would|do|does|did|is|are|was|were|am|has|have|had)\b

Three parts of the pattern do the work, and understanding them means you can adapt every other pattern in this guide:

• ^ anchors the match to the start of the query. Without it, "see how it works" would match because "how" appears in the middle. With it, only queries that begin with a question word pass.
• (word|word|word) groups alternatives. The pipe | means "or", so the group matches if the query starts with any one of the listed words.
• \b is a word boundary. It stops "whoever" and "however" from matching "who" and "how", and stops "whatsapp" from matching "what". Without it, a pattern meant to find a few hundred questions can quietly balloon into thousands of unrelated rows.

Question word	In the viral image's regex	In the improved regex
who, what, why, how, when, where, which	Yes	Yes
can, does, do, is, are, should, will, could, would	Yes	Yes
did, was, were, has, have, am	No — these questions are missed	Yes
whom, whose, may, might, must, shall, had	No	Yes

One honest note: even the improved pattern only catches questions that start with a question word. "Best laptop for students — how much RAM?" starts with "best", so it will not appear. If your list looks thin, drop the ^ and use the same group without the anchor to catch question words anywhere in the query — at the cost of noisier results.

How regex works in Search Console

Search Console's filter does not use the regex flavour most tutorials assume. It uses RE2, Google's own regex engine. RE2 is fast and safe, but it deliberately leaves out three features other engines have: lookahead (patterns like (?=...) and (?!...)), lookbehind ((?<=...) and (?<!...)), and backreferences (\1, \2). This matters because the single most copied exclusion pattern on the internet — a negative lookahead like ^(?!.*brand) meant to hide brand queries — simply does not run in Search Console. It returns nothing, and an empty report looks exactly like a segment with no traffic, so the failure is silent. The correct way to exclude things is built into the filter itself: choose Doesn't match regex instead of Matches regex. That dropdown does the excluding for you, no lookahead needed.

Four more rules explain nearly every pattern in this guide:

Rule	What it means	Example
Partial match by default	A pattern matches if it appears anywhere in the query or URL — you do not need wildcards around it	shoes matches "red shoes" and "shoes for men"
^ and $ anchor	^ locks the start, $ locks the end; use both for an exact match	^shoes$ matches only the query "shoes"
\b word boundary	Matches a whole word, not a word fragment	\bseo\b matches "seo" but not "seoul"
Case	Queries are stored in lowercase, so case rarely matters for query filters; page URLs keep their case, so URL filters are case-sensitive	/Blog/ does not match /blog/ — add (?i) at the start for case-insensitive matching

Two practical warnings before you paste anything. First, a stray trailing pipe breaks everything: a pattern ending in "|" (for example, brand|) contains an empty alternative that matches every query, so a "Doesn't match regex" filter with a trailing pipe silently empties your whole report. Second, keep patterns short: very long lists of alternatives can hit the filter's character limit, so split a giant brand list into two filters rather than one enormous pattern.

How to paste a regex into Search Console

Every hack below uses the same six clicks. Search Console is free, and there is no paid tier — these filters are available on every property.

1. Open Google Search Console and pick your property.
2. In the left sidebar, open Performance, then Search results.
3. Above the chart, click + New (on some accounts it reads + Add filter).
4. Choose Query for search terms or Page for URLs.
5. Open the match-type dropdown (it defaults to "Queries containing") and select Custom (regex).
6. Leave the second dropdown on Matches regex to keep only what fits the pattern, or switch it to Doesn't match regex to exclude what fits. Paste the pattern, click Apply, and the chart, totals and table all re-filter at once.

Set the date range before you judge a list. The report defaults to the last three months, but question and long-tail queries are rare by nature — a twelve-month view gives you a far longer list to work from. The maximum is sixteen months. You can also combine filters: a question regex plus a Page filter for one section shows only the questions one part of your site receives.

Hack 1: Question queries — what people actually ask

Paste into: Query filter, Custom (regex), Matches regex.

^(who|whom|whose|what|why|how|when|where|which|can|could|may|might|must|shall|should|will|would|do|does|did|is|are|was|were|am|has|have|had)\b

What it reveals: the literal questions searchers typed before Google showed them your site. No keyword tool gives you this list — these are real sentences from real people, in their own words.

What to do: sort by impressions. Take the ten questions with the most impressions and give each one its own heading on a real page, phrased the way the searcher typed it, with the answer in the first two sentences. Questions with no good page behind them are your next articles. Re-run the same filter in a month and watch the list move.

Hack 2: Brand vs non-brand — how strangers find you

Paste into: Query filter, Custom (regex), Doesn't match regex — and replace the placeholders with your own brand names, spellings and common misspellings.

yourbrand|your brand|yourbrand.com

What it reveals: everything left is non-brand traffic — people who found you without already knowing your name. That is the honest measure of your discovery: brand queries show how many people already know you, non-brand queries show how many new people you reach. Flip the dropdown to Matches regex with the same pattern and you get the brand half for comparison.

What to do: compare the two totals. If nearly everything is brand, your content is not reaching strangers yet, and non-brand informational pages are the gap. One trap: if your brand is a common word or a place name, the filter hides unrelated queries too — a firm called "Riverside" filtering out "riverside" also hides searches from people in Riverside. In that case filter on the full brand name, not the single word.

Hack 3: Commercial-intent queries — who is ready to spend

Paste into: Query filter, Custom (regex), Matches regex.

\b(price|pricing|cost|buy|purchase|hire|near me|cheap|discount|deal|best|review|vs|versus|compare|alternative)\b

What it reveals: searches with buying intent behind them — people checking prices, comparing options, or looking for someone to hire nearby.

What to do: read this list differently from the question list. A query like "website cost dubai" should land on a page with prices and a clear next step, not a general blog post. And calibrate "best" and "review": they often signal research, not a wallet already open — "best laptop 2026" is someone still deciding. Pair this filter with the Pages tab to check which page each commercial query lands on; if a buying query lands on an informational page, that page needs a commercial section or the query needs its own landing page.

Hack 4: Long-tail queries — the specific, winnable searches

Paste into: Query filter, Custom (regex), Matches regex.

^(\S+\s+){4,}\S+$

What it reveals: queries of five or more words. The pattern counts words mechanically: four groups of "a word plus a space", then a final word. Change the 4 to 6 and you get seven or more words. Long queries are specific by nature — "emergency plumber near me open now" instead of "plumber" — and they tell you exactly which problem the searcher is trying to solve.

What to do: these are usually the easiest wins on a site. A long query with impressions but a weak position often needs only one focused section on the ranking page, written in the searcher's own words. Group similar long queries together and each group is a ready-made article outline.

Hack 5: URL grouping — which section of your site earns its keep

Paste into: Page filter, Custom (regex), Matches regex.

/blog/

What it reveals: the performance of one whole section of your site at once — every page whose URL contains /blog/, for example. Swap the pattern to /tools/, /shop/ or any other folder and you can compare sections head to head: total clicks, impressions, CTR and average position per section, without exporting anything.

What to do: run each section in turn and write down the totals. A section with big impressions and a low CTR has a title and snippet problem. A section with clicks but falling position needs fresh content. For an exact section boundary, anchor the pattern to your domain with escaped dots, like ^https://example\.com/blog/ — remember the Page filter matches the full URL and is case-sensitive, so /Blog/ and /blog/ are different filters.

Hack 6: Striking distance — the rankings one push away from page one

Paste into: nothing — this hack uses the table itself, not a regex. Apply any filter above first (questions and commercial queries work best), then sort the Queries table by average position and look at rows sitting between position 8 and 20, starting with the ones carrying the most impressions.

What it reveals: queries your site already ranks for on page two or the bottom of page one — close enough that a better answer, a clearer title or a missing section on the ranking page can plausibly move them up. Read position with care: average position is the average of your topmost result across impressions, so a query shown at position 4.6 sometimes appears at 2 and sometimes at 9. Always read it next to impressions and CTR, never alone.

What to do: pick five striking-distance queries, open their ranking pages (switch to the Pages tab with the filter still applied to see which page ranks), and improve exactly those pages: answer the query in the first paragraph, add the missing subheading, tighten the title. This is the highest-return editing list most sites own, and it is free.

Hack 7: Declining queries and pages — catch the slide early

Paste into: nothing — this one uses the date comparison. Open the Date filter, switch to the Compare tab, and compare the last 28 days against the previous 28 days (or three months against the previous three). A Difference column appears in the table. Sort the Queries tab by the clicks difference, smallest first.

What it reveals: the queries and pages losing the most clicks, ranked by damage. The same comparison on the Pages tab shows which whole pages are sliding rather than single queries.

What to do: work from the top of the losers list. Check whether the ranking page still answers the query, whether a competitor's fresher page took the spot, and whether the page itself changed recently. A query that fell while its page stayed still usually means the search results around it changed; a page that fell across all its queries usually means the page itself needs attention.

Hack 8: High-impression, low-CTR questions — the FAQ goldmine

Paste into: Query filter, Custom (regex), Matches regex — the improved question regex from Hack 1 — then sort the table by impressions, highest first, and scan for rows with a low CTR.

^(who|whom|whose|what|why|how|when|where|which|can|could|may|might|must|shall|should|will|would|do|does|did|is|are|was|were|am|has|have|had)\b

What it reveals: questions Google already associates with your site — it shows you for them — but searchers are not clicking. That combination usually means the page ranks but does not visibly answer the question: the answer is buried, the title promises something else, or the snippet shows a competitor answering better.

What to do: for each top row, open the ranking page and add a short FAQ answer or a dedicated heading with the question phrased exactly as searched, answered in the first two sentences. This is the closest thing Search Console offers to a content brief written by your own audience.

Hack	Filter	What it reveals	First action
1. Question queries	Query regex, Matches	Real questions searchers asked	Answer the top 10 as headings on real pages
2. Brand vs non-brand	Query regex, Doesn't match	Discovery vs existing fans	Compare totals; grow non-brand content if brand dominates
3. Commercial intent	Query regex, Matches	Buyers and comparers	Point them at pages with prices and a next step
4. Long-tail (5+ words)	Query regex, Matches	Specific, winnable searches	Group similar queries into article outlines
5. URL grouping	Page regex, Matches	Section-by-section performance	Compare sections; fix low-CTR sections' titles
6. Striking distance	Sort by position 8–20	Rankings one push from page one	Improve the five ranking pages directly
7. Declining queries	Date Compare, sort by clicks difference	What is losing traffic fastest	Diagnose the top losers first
8. FAQ goldmine	Question regex + sort by impressions	Seen-but-not-clicked questions	Add exact-phrased FAQ answers to ranking pages

A thirty-minute monthly routine that uses all eight

Filters are only useful if they become a habit. Once a month, open the Performance report, set the date range to the last twelve months, and work through this order: first the declining comparison (Hack 7) to stop any bleeding, then striking distance (Hack 6) for the quickest wins, then the question list (Hack 1) and the FAQ goldmine (Hack 8) for new content, then brand vs non-brand (Hack 2) to check whether discovery is growing, and finally the section comparison (Hack 5) to see which part of the site deserves the next month's effort. Export the filtered tables to a spreadsheet when a list is worth working through over several sessions — the report keeps its totals even when you change filters, so write down section totals before you swap patterns.

A small business owner with a services site will get the most from Hacks 1, 3 and 8: real customer questions, buying queries, and the answers missing from their pages. A blogger will live in Hacks 1, 4 and 5: questions, long-tail groups, and which section actually earns traffic. An online store will lean on Hacks 2, 3 and 7: how much traffic is strangers versus fans, which commercial queries land on the wrong pages, and which product pages are sliding. The patterns are the same; the priority changes with the site.

Limitations and fine print

Limit	What it means for you	Workaround
16 months of history, no more	Performance data older than sixteen months is gone from the report and the API alike	Export tables regularly, or set up the bulk export before history expires
Default view is 3 months	Short views hide rare question and long-tail queries	Switch the date range to 12 or 16 months before judging a list
Rare and anonymised queries are omitted	Filtered totals are always lower than the site total; long, rare searches are the likeliest to be hidden	Treat every filtered list as a sample, not a census
Tables show at most 1,000 rows	Big sites see only the top rows in the interface and its export	Use the Search Console API, or split the view with extra filters
Data lags 2–3 days	The most recent days are incomplete and can still shift	Do not judge a change on the last two days of data
RE2 has no lookahead or backreferences	Many copied patterns silently return nothing	Use "Doesn't match regex" for exclusions; test patterns in Search Console itself
Average position is an average	One query's position blends many appearances across devices and places	Read position with impressions and CTR, and split by device or country when it matters

Two more honest caveats. Search Console shows queries, not people: it tells you what was typed, never who typed it, and that is by design — rare queries are withheld precisely so no individual search can be identified. And a regex segment is a lens, not a measurement: if forty percent of your clicks have no named query behind them, a brand vs non-brand split built from named queries alone is a split of the visible share, not of your whole traffic. Use the segments to decide what to write and fix, not to publish precise percentages.

Security and privacy: whose data is this, and how to handle it

Search Console data belongs to the verified owner of the property — it is your own site's aggregated search data, and it contains no names, emails or personal details of searchers. That is the privacy story in one line: the product is designed so you cannot identify individuals from it, and Google withholds the rare queries that might come close. Your responsibility is on the access side. Keep the property's user list short: give full access only to people who actually work on the site, use restricted access for everyone else, and remove users who no longer work with you. When you share a filtered table or a screenshot, check it the same way you would any report — it shows your own traffic, which competitors would happily read. And never paste anything secret into a filter box: a regex pattern needs no keys, tokens or passwords, and any guide asking you to put one there is not a Search Console guide.

Frequently asked questions

Do I need to learn regex to use these filters?

No. The eight patterns in this guide are copy-paste ready — replace only the brand placeholders in Hack 2 and your domain in Hack 5. The cheat-sheet table explains the five symbols (^, $, \b, | and groups) that let you read any pattern you meet later, but you can use every hack here without writing a pattern yourself.

Why does a regex I copied from another site return nothing?

Almost always because it uses a feature RE2 does not support — usually a lookahead like (?!...) for exclusions, or a backreference like \1. Search Console fails silently: an empty report looks identical to a segment with no traffic. Rewrite exclusions with the "Doesn't match regex" dropdown, and test every borrowed pattern in Search Console itself before trusting it.

Why don't my filtered totals add up to my site total?

Because Google withholds rare and anonymised queries for privacy, and tables show at most 1,000 rows. Filtered totals are always a sample of your traffic, not the whole of it. Compare segments against each other rather than treating any filtered total as a complete count.

How far back can I look, and why is my data only three months?

Three months is only the default view. Open the date filter and choose up to the last sixteen months — that is the maximum Search Console keeps for Performance data, in the report and the API alike. Data also lags two to three days, so the most recent days are still settling.

Is Search Console free, and does it work without a paid SEO tool?

Yes. Search Console is free with no paid tier, and every filter in this guide is built into the Performance report. Paid tools add competitor data, keyword volumes and rank tracking — useful, but not needed for any of the eight hacks here. For data about your own Google traffic, Search Console is the source the other tools are estimating from.

Sources

• Google Search Console Help: About Search Console data — rare and anonymised queries omitted, 1,000-row table limit, 2–3 day data lag — https://support.google.com/webmasters/answer/96568?hl=en
• Google Analytics Help: [GA4] Queries report — "Search Console keeps data for the last 16 months" — https://support.google.com/analytics/answer/13682862?hl=en&co=GENIE.Platform%3DAndroid
• Google Cloud: RE2 specifications — RE2 does not support lookahead, lookbehind or backreferences — https://docs.cloud.google.com/load-balancing/docs/re2-support
• RE2 project: syntax reference — supported and unsupported constructs — https://github.com/google/re2/wiki/Syntax
• Search Console API pricing and limits — API use is free with usage limits — https://developers.google.com/webmaster-tools/pricing
• Search Console regex guides corroborating the filter location, partial matching and case behaviour — https://aiblogautopilot.com/regex-filters-search-console/ · https://www.actuatemedia.com/blog/how-to-use-google-search-console-for-seo/ · https://professionalstoolkit.com/articles/google-search-console-performance-report
• Related on this site: How to Read Google Search Console — https://asadwebs.com/blog/how-to-read-google-search-console-2026