Google Search Console lets you stack filters to narrow down query, page, country, and device data. But the way it combines multiple conditions isn’t intuitive—and if you’re used to spreadsheet filter logic or SQL, you’ll get surprising results the first time you try to isolate a segment.
The interface offers two combination modes: “Filter by AND” and “Filter by OR.” The labels sound clear. In practice, they behave differently depending on whether you’re filtering within the same dimension or across different ones.
Same dimension: OR is the only option that works
If you want to see data for two specific queries—say, “WordPress caching” and “WordPress CDN”—you’d think you could add both as separate query filters and choose AND to show rows matching both. You can’t. When you add multiple filters to the same dimension (queries, pages, countries, devices), Search Console forces OR logic even if you select AND.
Why? A single search impression can’t satisfy two different query strings simultaneously. A click either came from “WordPress caching” or “WordPress CDN,” never both. So AND would return zero rows. Google’s interface quietly overrides your selection and treats same-dimension filters as OR.
This trips up operators who want to exclude certain queries while viewing others. You can’t add a “Query contains ‘caching’” filter and a “Query does not contain ‘plugin’” filter and expect AND logic to show caching queries that aren’t about plugins. Both filters apply to the query dimension, so Search Console ORs them—you’ll see every caching query plus every query that doesn’t contain “plugin,” which is almost your entire dataset.
Different dimensions: AND and OR work as labeled
When you filter across different dimensions—one filter on queries, another on pages, a third on country—the AND/OR toggle behaves as expected.
Example: You want to see how the query “email deliverability” performs on your /guides/postmark-setup page in the United States. Add three filters: query exactly matches “email deliverability,” page exactly matches your URL, country exactly matches USA. Set the combination mode to AND. You’ll get rows that satisfy all three conditions.
Switch to OR, and you’ll see every impression that matches any of the three: every “email deliverability” query across all pages and countries, every impression on that Postmark guide regardless of query, and every US impression regardless of query or page. The dataset explodes.
For cross-dimension filtering, AND is almost always what you want. OR is useful when you’re trying to compare performance across segments—like traffic from the US or the UK combined, filtered to a specific landing page.
The non-obvious workaround: use regular expressions for exclusions
If you need to exclude certain query patterns while keeping others, don’t stack multiple query filters. Use a single filter with a regular expression that combines inclusion and exclusion logic in one pattern.
Say you want queries containing “WordPress” but not “theme” or “plugin.” Instead of three separate filters, use one: set the filter type to “Custom (regex)” and enter wordpress(?!.*(theme|plugin)). The negative lookahead excludes rows matching your unwanted terms without triggering Search Console’s forced OR behavior.
Regular expressions aren’t exposed prominently in the filter dropdown—select “Custom (regex)” under the query filter type menu. The interface doesn’t validate your regex in real time, so test patterns in a regex tester before applying them to avoid silent failures.
When filter combinations cost you accurate attribution
Stacking too many filters—especially across queries and pages—can shrink your sample size below Search Console’s anonymization threshold. Google suppresses rows when impression counts fall under ~10 to protect user privacy. If your AND filter combination is too narrow, you’ll see “(not set)” or missing rows, even though the traffic exists.
This happens most often when you filter by long-tail queries (low volume) AND specific pages (also low volume) AND a narrow date range. Broaden one dimension—expand the date range to 28 days, or widen the query filter to “contains” instead of “exactly matches”—and the data reappears.
If you’re debugging attribution or trying to confirm whether a specific query drives traffic to a specific page, export the full dataset as a CSV and filter locally in a spreadsheet. The export includes rows that fall below the UI threshold, though Google still suppresses some for privacy.
Want to catch more tool-behavior nuances like this? Subscribe to One Two Three Send for weekly breakdowns of how online-business software actually works—no fluff, just the mechanics that matter.