Reference guide · search-console · Published 2026-08-16 · 3 min read
Search Console performance report filters
Search Console performance report filters explained: search type, date range, page and query filters, custom filters, and the traps when combining them.
- ·The filter bar
- ·Search type and date
- ·The traps
The filter bar is the report's switchboard
The performance report surface in Search Console is one underlying dataset, and the filter bar is what turns it into a specific story. Everything you can filter on is there: search type, date range, page, query, country, and device, plus a "custom" filter option for building exact-match and exclusion rules.
Filters change the rows, so they are the difference between "our site got 1,000 clicks" and "our climbing-shoes-review page got 40 clicks on mobile in the UK". This page covers the filter mechanics; the segmentation article covers which slice answers which question, and the performance report reference covers the dimensions themselves.
Search type and date range
| Control | What it does | How to use it |
|---|---|---|
| Date range | Picks the window, with a compare control | Set the same window each time so periods stay comparable |
| Search type | Web, Discovery, News, Image, Video | Switch to "Web" for normal organic; each surface is a separate dataset |
| Page filter | Narrow to a URL or URL folder | Use it to isolate one page or one template |
The search-type toggle is easy to miss because the same "performance" link opens "Search results" by default. If a client asks why clicks fell, the first check is which surface you are looking at, because a Discover or News entry is not the same as a web query. The separate Discover report is a reminder that each surface keeps its own rows.
Custom filters combine cleanly
A custom filter adds "contains", "equals", or "not" logic against a dimension. You can stack a page filter with a query filter with a country filter, and each one narrows the same underlying dataset further. The order is always additive: every row must satisfy every filter you have applied.
A practical set for an investigation:
- Search type: Web only.
- Page filter: contains
/guide/so you see a template, not one URL. - Query filter: contains one keyword.
- Country: United Kingdom.
The result is a small population you can read as a trend instead of an average, which is exactly what the segmentation workflow is designed to protect.
The traps when combining filters
- A filter hides the rest. Filtering to one page removes every other row, so "clicks fell" can actually be "a different page now ranks". Always compare the filtered view against the unfiltered total before deciding.
- Search type is sticky in a way that misleads. Re-opening the report carries some settings over; a stale "Video" toggle can make a normal report read almost empty.
- Date range resets silently. Changing the range changes the denominator, so a 28-day window that spans a different set of weekends is not a like-for-like comparison.
- Query strings and folders. A "contains" filter on a URL matches any part of the string, so
/guide/and/guides/need two filters unless you confirm the exact convention.
Filters narrow the report, they never add data. The honest habit is to start unfiltered, form the hypothesis, then add the minimum number of filters needed to test it, and confirm the story against the live crawl and indexing picture before acting.