How Do You Find Question Queries With Search Console Regex Filters?

How do you find the questions people actually search before landing on your site?

Use the Custom regex filter in the Search Console Performance report, applied to the query dimension, with a pattern that matches question words. It takes about two minutes to set up and it surfaces the real phrasing people use, which is almost never the phrasing you assumed when you wrote the page.

This is the single most useful report I run for clients, and it is free. Most site owners never touch it because the word regex sounds like programming. It is not. For this job you need roughly four symbols, and Google's own documentation gives you the example to start from.

What follows is the exact workflow, step by step, for one specific situation: you run a blog or a resource section, you get impressions, and you want to know which questions are already bringing people to you so you can answer them properly.

What is the Custom regex filter in Search Console?

It is a filter type that matches your queries or pages against a pattern instead of a single word. Google's Search Central blog describes it as the Custom (regex) option in the filter selector, and says the Performance report filter supports both matching and not matching regex filters, chosen through a secondary dropdown that appears after you pick that option.

That not matching option is the half people forget, and it is often the more useful one. Matching shows you a slice. Not matching shows you everything except a slice, which is how you strip out your own brand terms and see what the rest of your traffic is really doing.

On syntax, Google points you at a specific standard. Its blog post says to check the RE2 regex syntax reference for all metacharacters supported by Search Console. So this is not a loose search box with wildcards. It is a defined syntax, and patterns that work elsewhere may behave differently here.

Before you rely on the fine details, check Google's own help documentation for how the Custom regex filter handles case and whether a pattern must match the whole string or only part of it. Those behaviours decide whether your filter is too narrow or too broad, and they are worth reading from the source rather than inferring from results.

Which regex should you start with?

Start with the one Google published. Its Search Central blog gives this exact example for understanding user intent: a query filter of what, how, when, or why, joined by the pipe character, which it notes might show results indicating your content should easily answer questions, maybe through an FAQ.

Written out, that pattern is the four words separated by vertical bars: what then a bar, how then a bar, when then a bar, why. Google's post explains the symbol directly, saying the pipe metacharacter represents an OR statement. So the filter reads as any query containing any one of those words.

To do this, open Search Console, go to the Performance report under Search results, click New filter at the top, choose Query, then choose Custom (regex) from the match type dropdown. Leave the secondary dropdown on matching, paste the pattern, and apply. You now have every question-shaped query from your reporting window.

Once that works, widen it. Real question queries also start with who, where, which, can, should, does, is, and do. Add each one with another bar. The pattern gets long and stays readable, because all you are doing is listing alternatives. I keep mine in a note and paste it in rather than retyping, which also means I am comparing the same thing month to month.

How do you narrow this to one section of your site?

Add a second filter on the page dimension, also using Custom regex, pointed at the directory you care about. Google's blog gives the pattern shape for this too, using the example of shoes followed by the wildcard and then green, and explaining that the dot star matches any character any number of times.

For a blog, the equivalent is straightforward. Filter pages by your blog path, then apply the question-word query filter on top. Search Console combines the two, so you are now looking at question queries that landed specifically on your blog rather than on your homepage or your pricing page.

This combination is where the report starts paying for itself. Site-wide question data is interesting. Section-level question data is actionable, because it tells you which piece of content is already being treated as an answer and what it is being asked.

If your URL structure does not separate sections cleanly, that is your finding for the day. Fix the structure first. A site you cannot slice is a site you cannot learn from, and no amount of clever filtering compensates for it.

What do you do with a query that gets impressions but no clicks?

Treat it as a mismatch between the question and the page, not as a ranking problem. The query proved Google thinks you are relevant. The absence of clicks says the person did not believe your page would answer that specific question, or they got their answer without needing to click.

Sort your filtered list by impressions, descending, and look for rows where the click count is at or near zero while impressions are substantial. Open the top few, then actually search the query yourself and look at what your listing says. Usually the title promises something adjacent rather than the thing being asked.

The fix is often smaller than a rewrite. Adding a heading that states the question in the reader's words, followed immediately by a direct answer in the first sentence, tends to do more than restructuring a page. That is the same discipline I use when I write answer blocks that get cited by AI, and it serves both audiences at once.

Be honest about the third possibility, though. Some question queries are answered in the search result itself and will never click through, no matter what you do. Recognising those saves you from optimising for a click that was never available.

How do you find questions you rank for but do not answer directly?

Use the not matching option in reverse. Filter queries to question words, then add a second query filter set to not matching, containing the terms your page already covers well. What remains is the set of questions arriving at your site that your existing content does not address head on.

Google's blog describes this negative option as the second half of the feature, chosen from the secondary dropdown after you select Custom (regex). Its own suggested use is filtering out brand terms so you can see non-brand behaviour, and the same mechanic works for any vocabulary you want to subtract.

Run this on a page that gets a lot of impressions and you will usually find two or three questions you had not considered. Those are the cheapest content decisions available to you, because demand is already proven and you are not guessing at a topic.

My rule is that a question needs to appear across more than one reporting period before I act on it. One month of data on a long-tail query is noise. Two months of the same question is a signal, and I would rather write one well-evidenced section than four speculative ones.

What limits should you know before you trust the numbers?

Search Console does not show every query, and it does not keep data forever. Both of those shape what your filter can tell you, so check Google's documentation for the current reporting window and the conditions under which queries are withheld before you build a process on top of the numbers.

The practical effect is that long-tail question queries are exactly the ones most likely to be missing. So absence in this report is weak evidence. A question you cannot find may still be asked. A question you can find is definitely asked, which is why I use the report to confirm demand rather than to rule it out.

There is also a sampling problem in your own head. Filtering to question words excludes questions phrased without question words. Someone searching for the cost of a service is asking a question without using one of your keywords. Keep a second, unfiltered pass in your routine so the filter does not become the whole picture.

Finally, remember what this report measures. It measures Google. It does not tell you what people asked an AI assistant before arriving, and pretending otherwise is how teams end up confidently wrong. I have written separately about what Search Console does and does not report about AI citations.

How do you turn this into a repeatable monthly pass?

Save the filter combination as a habit rather than a project. Pick a fixed day each month, run the same two filters over the same window length, and paste the top rows into a sheet with the date. The value is in comparison, and comparison requires that you do the same thing twice.

Keep the sheet simple. Query, impressions, clicks, the page it landed on, and a column for what you decided. That last column is the one that matters, because it stops you rediscovering the same question three months running and doing nothing about it each time.

Give each run a small, fixed output: one page updated, or one new section written. A report that produces no change is a hobby. Tying the pass to a single deliverable is what turns it into a system, and it is also how a monthly content calendar builds itself from evidence rather than brainstorming, which I have covered in building a content calendar from Search Console data.

What should you do next?

Open Search Console right now and run Google's own example on your query dimension. Four words joined by pipes, Custom regex, matching. Look at the top twenty rows by impressions and find the first question you had not thought about. That is twenty minutes, start to finish.

Then decide what you will do about exactly one of those rows this week. Add the question as a heading, answer it in the first sentence beneath, and leave the rest of the page alone. Small, evidenced changes compound far better than a quarterly content overhaul built on assumptions.

If you want help setting this up properly for a site with a lot of pages, or you want someone to run the first pass with you and show you what the rows actually mean, reach out. It is a short conversation and it usually changes what people write next.