Filters, comparisons & regex

Build precise Performance report views for query families, directories, devices, and countries.

Automatable now Intermediate

Filters turn the Performance report from a sitewide summary into a specific question. Comparisons place two equivalent segments side by side. Regular expressions let you define query or URL families that a simple text filter cannot express.

The mechanics are easy; the analytical boundary is the important part. Write down the exact population, metric, and period before adding controls. “Mobile web clicks to /guides/ from Spain this quarter versus the same quarter last year” is reproducible. “How is Spain doing?” is not.

Filters and dimensions do different jobs

A filter restricts the rows included in every metric, chart, and dimension. A dimension tab changes how that filtered population is grouped in the table.

For example, apply:

  • Search type: Web
  • Date: Last 28 days
  • Country: Spain
  • Device: Mobile
  • Page: URLs containing /guides/

Then select Queries to see the queries for that population or Pages to see its landing pages. Changing the table tab does not remove the filters.

Search type and date are always present. Other available Performance dimensions include query, page, country, device, and search appearance. Google documents that filters across different dimensions are combined with AND logic. A view filtered to Spain and Mobile contains searches that meet both conditions, not either condition.

Build a precise filtered view

  1. Open Performance → Search results.
  2. Choose the correct search type: Web, Image, Video, or News. Search types are separate datasets, not another table dimension you can add together.
  3. Choose a complete date range. Avoid preliminary hours or days when producing a stable report.
  4. Select + Add filter, or click a table row to restrict the report to that value.
  5. Add the narrowest useful filters one at a time.
  6. Confirm every active filter shown above the chart before interpreting the result.
  7. Select the dimension that answers the next question.

Add filters progressively. If a filter unexpectedly removes most data, you will know which condition caused it.

Query and page text filters

Use a simple containing filter when one literal substring defines the group.

Examples:

  • Queries containing search console
  • Queries not containing acme
  • URLs containing /products/
  • URLs not containing /internal-search/

These matches are case-insensitive but otherwise respect the characters and spaces entered. A simple /blog/ page filter is usually clearer than regex when that directory is the entire scope.

Clicking a query or page row is useful for an individual value. Use a regular expression when the group includes alternatives, optional pieces, or structural boundaries.

Page filter traps

  • Match the URL pattern that Search Console reports, which is usually the Google-selected canonical URL.
  • Include slashes around a directory when they express a real boundary. /shop/ is safer than shop.
  • A URL substring can appear in a hostname, path, parameter, or filename unless the pattern excludes those locations.
  • Redirect destinations and canonical selection can make the reported URL different from the URL in an analytics tool.

When regex is the right tool

Search Console custom query and page filters use Google’s RE2 syntax. Use regex for groups such as:

  • Several brand names or common misspellings.
  • Multiple content directories.
  • Question words at the beginning of a query.
  • Product or SKU patterns.
  • Locale folders with consistent URL structure.
  • Exact query families that should exclude longer phrases.

Do not use regex merely because it is available. A pattern that only its author understands is difficult to audit and easy to break.

Search Console regex rules that matter

Matching is partial by default

The expression:

seo

matches anywhere in the query or URL. Use anchors when position matters:

^how

matches values beginning with how, while:

\.pdf$

matches URLs ending in .pdf.

Use both anchors for an entire-value match:

^(google search console|search console|gsc)$

Matching is case-insensitive by default

ACME, Acme, and acme match the same pattern. Prefix with (?-i) only when case is genuinely meaningful:

(?-i)/SKU-[A-Z]+$

Alternation means OR inside the pattern

Use a pipe to match alternatives:

(price|pricing|cost|quote)

Parentheses keep alternatives together. For brand work, include only variations that uniquely represent the brand:

\b(acme|acme corp|acmecorp)\b

RE2 is deliberately limited

RE2 does not support lookahead, lookbehind, or backreferences. Patterns such as (?!...), (?<=...), and \1 will not work. Use the report’s Doesn’t match regex option for exclusion, simplify the pattern, or perform the classification after export.

Practical regex examples

A group of directories

^https://www\.example\.com/(blog|guides|resources)/

This restricts the host and requires one of three folders immediately after it.

Question queries

^(who|what|when|where|why|how|can|does|is|should)\b

This detects phrasing, not intent with certainty. Add equivalents for every language in scope.

Product pages with numeric IDs

/products/[0-9]+(?:/|$)

Exclude a brand family

Choose Doesn’t match regex and enter:

\b(acme|acme corp|acmecorp)\b

This creates a documented rule-based non-brand segment. It will not necessarily match Google’s AI-classified branded-query segment.

Test every expression

Before reporting a regex segment:

  1. List several values that must match.
  2. List several similar values that must not match.
  3. Apply the filter and inspect actual rows.
  4. Check whether unexpected hostnames, paths, or words slipped in.
  5. Save the expression, purpose, owner, and revision date with the report.

How comparisons work

A comparison shows two values from one dimension, such as:

  • One date range versus another.
  • Mobile versus desktop.
  • Spain versus France.
  • One page versus another.
  • Two search appearance types.

Open the relevant filter, choose Compare, select the two values or periods, and apply it. The table adds separate values and a Difference column.

Search Console permits only one comparison at a time. Adding another replaces the existing comparison. Other ordinary filters can remain active, so you can compare Mobile versus Desktop while filtering to Spain and /products/.

For devices, countries, search types, or search appearances, a comparison is also the normal way to view two selected values together. It is not an arbitrary multi-select control.

Choose equivalent date periods

A valid date comparison normally uses:

  • The same number of complete days.
  • The same days of the week.
  • The same seasonal window when seasonality is material.
  • Finalized rather than preliminary data.
  • The same search type and all other filters.

Google recommends weekly or monthly granularity for longer comparisons because it reduces day-of-week noise. Compare a holiday period with the corresponding holiday period, not merely with the immediately preceding days.

Use two views when needed:

  1. A recent-period comparison for operational change.
  2. A year-over-year comparison for seasonality and demand context.

Filter versus comparison

Use a filter when the other segment is irrelevant. Use a comparison when the gap itself is the question.

Question Correct control
Which queries brought mobile clicks? Filter to Mobile, group by Query
Is mobile CTR lower than desktop CTR? Compare Mobile vs Desktop
Which Spanish pages gained clicks? Filter to Spain, compare dates, group by Page
Did /guides/ beat /blog/? Compare the two Page values or export directory groups
Which queries mention any of five products? Query regex filter

Why filtered totals can change unexpectedly

Query filters affect more than visible rows. Search Console omits some queries for privacy and truncates lower-importance rows. Anonymized queries are included in unfiltered chart totals, but Google says they are removed when any query filter is applied. Consequently:

  • Branded and rule-based non-branded totals may not add to the unfiltered total.
  • The visible query rows may not sum to the chart.
  • A narrower filter can sometimes expose values that were rare in a broader comparison.
  • A ~ in a comparison means the value is unavailable for that rare side, not necessarily zero.

Page and search-appearance groupings also switch table aggregation from property to page. Do not compare a page-grouped table sum directly with a property-level chart as though they were calculated identically.

Natural-language report configuration

Google is testing an AI-powered configuration tool that translates a request into filters, a comparison, metrics, and a table selection. As of this guide’s verification date, Google describes it as experimental, limited to a small percentage of users, available only for the Search results Performance report, and limited to 20 requests per user per day.

It configures the view; it does not perform the analysis. It cannot sort table results, export data, calculate custom metrics, or understand external event windows reliably. Always review the proposed filters before applying them. Do not write workflows that assume every property has this feature.

Reusable analysis recipes

Directory performance year over year

  1. Search type: Web.
  2. Page filter: URLs containing /guides/.
  3. Date comparison: target period versus the same dates last year.
  4. Granularity: Weekly.
  5. Pages tab, then Queries tab.

Mobile non-brand discovery in one country

  1. Country filter: target country.
  2. Device filter: Mobile.
  3. Query filter: Google’s Non-branded option, if available, or a documented negative brand regex.
  4. Date comparison: equivalent periods.
  5. Inspect clicks, impressions, CTR, and position by Page and Query.

Several content templates

  1. Page regex: /(products|categories|collections)/.
  2. Compare dates.
  3. Export the table.
  4. Classify each URL into exactly one template after export if separate template totals are required.

Final quality checklist

  • The search type is explicit.
  • Both date ranges are complete and equivalent.
  • Every active filter is recorded.
  • Regex has positive and negative test examples.
  • The aggregation level is understood.
  • Absolute metric differences are reviewed before percentages.
  • Query privacy and truncation are disclosed.
  • The same filter definition is used in recurring reports.
  • Any AI-generated configuration has been checked manually.

Official sources