GSC's native compare mode lets you compare time periods or compare results for queries that share a single string. It does not let you compare two completely unrelated keyword groups against each other — for example, how your "SaaS" content performs against your "Enterprise" content, or how product line A is doing versus product line B. For that, you need a regex filter.
Here's the pattern. Apply it as a Custom (regex) filter on the query field:
(product-a|feature-x|tool-1|category-a)Then take a snapshot of the metrics (clicks, impressions, CTR, position). Change the regex to match the second group:
(product-b|feature-y|tool-2|category-b)Compare the two snapshots manually. That's the regex-based workaround for GSC's compare-mode limitation, and it's how most SEO teams handle category-level comparisons today.
Why Native Compare Mode Doesn't Solve This
GSC's compare function only handles two scenarios cleanly:
- Compare time periods: Last 28 days vs previous 28 days. Useful for checking trends but only for the same set of queries.
- Compare strings that share a pattern: "Queries containing 'pricing'" vs "Queries containing 'features'." Works if both groups share predictable substring patterns, but breaks if your category keywords don't share a common token.
If you want to compare "SaaS sales tools" performance against "enterprise sales tools" performance — two groups with overlapping terms but distinct keyword sets — the native compare can't filter them apart. Regex is the only way.
The Manual Regex Comparison Workflow
- Open GSC → Performance → Search Results
- Set the date range to your comparison period (90 days minimum for stable averages)
- Apply the first regex filter:
(product-a|feature-x|tool-1) - Note the totals: clicks, impressions, CTR, average position
- Remove the filter; apply the second regex:
(product-b|feature-y|tool-2) - Note the same totals
- Build the comparison in a spreadsheet
For trend comparison over time, you have to repeat this for each time window you want to compare. If you want to see how the two groups have performed over the last 12 months at monthly granularity, that's 24 separate filter applications. This is where the workflow becomes a real time tax.
Common Use Cases
Product Category Performance
For SaaS or e-commerce sites with multiple product lines, comparing the search performance of one category against another:
(crm|customer relationship|sales pipeline)
(marketing automation|email campaigns|drip campaigns)Funnel Stage Comparison
Comparing top-of-funnel informational queries against middle-of-funnel commercial queries:
\b(how to|what is|guide to|tutorial)\b
\b(best|top|review|vs|alternative|compare)\bGeographic or Language Performance
If your queries contain language or geographic indicators that GSC's country filter doesn't quite capture:
\b(uk|britain|british|england)\b
\b(usa|us|american|united states)\bFeature vs Feature
For product comparison content where you want to see whether your "live polls" content is performing better or worse than your "Q&A" content:
\b(live poll|polling|live polls)\b
\b(q&a|q and a|question and answer|audience questions)\bWhere the Manual Approach Breaks
A few situations where the regex-and-spreadsheet workflow stops being practical:
- Tracking a moving group of keywords over time: Categories are rarely static. Adding a new product means updating the regex everywhere it's been used; old data won't reflect the new keyword inclusion.
- Multi-year comparison: GSC retains 16 months. Comparing this year's Category A performance to two years ago is impossible without the BigQuery export.
- Comparing more than two groups: Three- or four-way comparisons become exponentially more painful — each combination of group and time period requires its own filter application.
- Layering competitor mentions: If you want to see how your performance for "Category A" tracks against competitor mentions in the same data (e.g., "Competitor X" appearing in queries), you need joined data, not just two separate filter snapshots.
The Done-For-You Version
The functional difference: rather than capturing point-in-time metrics from two separate filter applications, the comparison is a permanent view that updates as your data does. When a new query joins one of the groups (matches the regex), it's retroactively counted in the historical group performance — meaning the comparison stays internally consistent even as your keyword footprint grows.
One Practical Note on Regex Syntax in GSC
GSC uses RE2 regex syntax (the same as Google Sheets and BigQuery). A few quirks to know:
- Case insensitivity is on by default —
(SaaS|saas)isn't needed,(saas)matches both - The pipe character
|is OR. Use parentheses to group alternatives \bis a word boundary — useful for avoiding partial matches like "policies" matching "police"- The filter input has a character limit (roughly 4,096 characters) — very long group definitions hit this ceiling
Comparing unrelated keyword groups is one of the more common GSC analyses that the native interface doesn't directly support. Regex handles it for one-off comparisons. For ongoing comparison work — particularly category or funnel-stage analysis over multi-year windows — it stops being the right tool.
