Group Search Console Queries with Regex Without Misreading the Results

Suppose a site is called Cedar Atlas, but people search for “Cedar Atlas”, “CedarAtlas” and “Cedar-Atlas”. Filtering the Queries table for one spelling misses the others. A regex query filter can collect the variants in one view. The useful result is a repeatable definition of the group, accompanied by an audit of what it includes and misses.

Search Console's Performance report shows how a property appears in Google Search, including clicks, impressions, click-through rate (CTR) and average position. Its query data does not list every search. Keep that limitation in view whenever you describe a branded or nonbranded group. Google’s Performance report guide explains the metrics and report dimensions.

Set up a comparable report

Open the Search results Performance report and select the property, search type and date range. Record any country, device or page filter. Choose the Queries tab to inspect the matching strings. If you change one of these settings while comparing groups, you change the basis of the comparison.

Choose + Add filter, then Queries and Custom (regex). Leave Matches regex selected. Search Console uses RE2 syntax; matching is case-insensitive by default and can occur anywhere in a query unless you add a start or end anchor. Google documents those controls in Google’s advanced filtering instructions.

Write the pattern around the decision

For Cedar Atlas, start with (cedar atlas|cedaratlas|cedar-atlas). The vertical bars mean “or”. This finds “cedar atlas courses”, “CEDARATLAS reviews” and “cedar-atlas login”. It can also find the name after another word, as in “best cedar atlas courses”. That is usually appropriate when the aim is to include modified brand searches.

Partial matching can also admit an unrelated longer string: cedaratlas appears inside “mycedaratlasguide”. If the name must stand alone, use (^|[^a-z0-9])(cedar atlas|cedaratlas|cedar-atlas)([^a-z0-9]|$). The first group requires either the start of the query or a character that is not a letter or digit. The last requires the equivalent boundary after the name. It keeps “best cedar atlas courses” but rejects “mycedaratlasguide”.

Keep the alternatives together inside the parentheses. An anchor attached to just one alternative can leave the others free to match elsewhere. A pattern such as ^cedar atlas$ has a different purpose: it checks the exact two-word query, ignoring case, and excludes searches with modifiers. Use it only when that narrower group is the question you mean to answer.

Write down why each spelling belongs in the group before adding it. A space and a hyphen are different literal characters in these examples. If users also search for “cedar_atlas”, decide whether the underscore is a recognised name variant and add it explicitly if so. Avoid replacing the separators with a broad wildcard merely to save typing: a wider pattern may match a name you never intended to include. Test the shortest and longest expected queries as well as a few near misses.

The boundary rule is a practical choice, not a test of intent. It excludes “cedaratlas2” because a digit touches the name, while punctuation next to the name is allowed. It cannot tell whether “cedar atlas moth” refers to the brand or to something else. Inspect actual rows before deciding whether to add a genuine variant or exclude an ambiguous phrase. Widening the expression without checking the results can turn a precise brand group into a collection of unrelated strings.

Audit both sides of the filter

Apply the matching filter and scan the Queries rows. Check prominent rows by clicks and impressions, then inspect some less prominent rows. Confirm that each included query belongs to the group you defined. For example, “CEDARATLAS reviews” should match despite its capitals; “cedar atlas moth” may match the expression while failing the editorial test of brand intent. Record that ambiguity rather than treating every syntactic match as a branded search.

Next change the same filter to Doesn’t match regex without changing the property, dates, search type or other filters. Look through the visible excluded queries for alternative spellings, abbreviations or product names that clearly belong to the brand. If one appears, decide whether to add it as an alternative. Then recheck both views: a broader expression may repair a missed query while also admitting false matches.

Neither review can prove that every query was classified correctly. The visible table is a sample of reportable rows, and human judgement is needed for names that also have ordinary meanings. Keep a short note with the regex explaining which spellings count, which ambiguous terms were found and why you included or excluded them. The note makes a later comparison intelligible even if someone else prepares it.

For a repeatable check, keep a small set of example queries beside the pattern: expected matches, expected exclusions and ambiguous cases requiring judgement. Run those examples again whenever you edit the regex. If the expression is used for several brands or product lines, test each one separately; a single extra alternative can affect the entire group. This is particularly useful when a team shares saved reports, because the chart alone does not show the reasoning behind a boundary or an exception.

Read the numbers on the right basis

Record clicks and impressions from the matching view, then from the nonmatching view, with the same report settings. If comparing another period, reuse the exact expression and write down both date ranges. Call the second view “queries that did not match the pattern”, rather than “all nonbranded searches”: an omitted brand spelling could be in it, and some searches are absent from query-filtered data altogether.

CTR and average position are rates or averages, so do not add their displayed values across views. Also keep the chart and table dimensions straight. The chart aggregates by property, as does the Queries table; the Pages table aggregates by page. When multiple pages from one property appear in a search result, page and property counts can differ. Google’s explanation of Performance data aggregation describes the distinction.

Do not assume matching clicks plus nonmatching clicks reconstruct the unfiltered total. Google omits anonymised queries from the Queries table and applies data limits; adding a query filter can change which data contributes to totals. The table can display at most 1,000 rows, so even a careful scan of visible queries is not a complete inventory. Google explains these discrepancies in its data discrepancy guidance.

When reporting a change over time, compare the same metric and filter definition across periods. A rise in matching impressions does not by itself establish that more people sought the brand: the report shows appearances in search results, and the query group may include ambiguous terms. If the pattern changed, keep the old and new definitions in the report instead of presenting their figures as one uninterrupted series. Review query examples again when a major product name or brand spelling changes.

A clear result states the rule and its scope: “For this property, search type and date range, the three-variant pattern matched these reportable clicks and impressions. The nonmatching view used the same settings. The two views are not an exact inventory of all searches.” Include the actual regex alongside any saved figures. If the expression changes next month, label it as a changed definition before comparing the trend.

Before sharing the comparison

• Save the property, search type, date range and every additional filter.
• Save the exact regex and the spellings it is intended to include.
• Check matched rows for false positives and nonmatched rows for missed variants.
• Compare clicks and impressions on the same basis; interpret CTR and position within each view.
• State that filtered views and visible query rows do not cover every search.