Open any Search Console query report with a reasonable impression volume and you will find rows that look wrong. Long strings of unrelated words. Queries in scripts your business does not serve. Terms that read like someone pasted a paragraph into the search bar. Phrases that have no plausible relationship to what you sell, appearing with hundreds of impressions and zero clicks.
The instinct is to delete them from the report. That instinct is half right. These rows do distort averages, and leaving them in makes CTR and average position close to meaningless. But filtering them badly is worse than not filtering at all, because the same filter that removes noise routinely removes real demand — the awkwardly worded, long-tail, question-shaped queries that are often the most commercially useful rows in the whole export.
This is a data-governance problem, not a spam problem. What follows is the workflow we use to keep reports clean and defensible.
First, an accuracy note that governs everything else
Search Console does not tell you where a query came from. There is no field for origin, no bot flag, no automation indicator. When a query looks strange, you know exactly one thing: it looks strange.
That means "suspicious" is a review signal, not a verdict. Calling a set of rows bot traffic, scraper traffic or automated traffic is a claim the data cannot support, and stating it in a client report is a credibility risk. The correct language is that a query was excluded from the priority view because it did not match the business's commercial intent, with the rule that excluded it written down.
Everything in this guide is built around that constraint: exclude with a stated rule, never with an unstated assumption.
Build three views, not one filtered report
The single biggest improvement most reporting setups can make is to stop maintaining one report and start maintaining three. Each has a different job and a different audience.
1. The raw view
Unfiltered, untouched, exported and archived on a fixed schedule. Nobody presents from it. Its purpose is to be the record you can return to when a filter turns out to have been wrong, when someone asks whether a query was always absent or was excluded, or when you need to rebuild a comparison after changing your rules. Without a preserved raw view, every filtering decision becomes irreversible.
2. The reviewed view
The raw view with clearly defined exclusions applied — nonsense strings, irrelevant languages, obviously off-topic terms — each traceable to a documented rule. This is the working dataset for analysis. It should still contain plenty of low-value queries, because low value is not the same as invalid.
3. The priority view
The reviewed view narrowed to queries that map to services you actually sell in markets you actually serve. This is what goes into monthly reporting and what decisions are made against. It is deliberately small. For a Vancouver service business, it might be a few hundred queries out of tens of thousands of rows.
Presenting the priority view while retaining the other two is what makes the reporting defensible. Anyone can ask what was removed, and you can show them.
A six-step filtering workflow
Step 1: Export the raw data before touching anything
Pull the full query export for a consistent window — we use a rolling 28 days plus a matching prior period — and store it with the date range in the filename. Search Console's interface caps what you can see; the API and the bulk export give you far more rows, and the rows below the interface cutoff are where the strange queries and the valuable long tail both live.
Step 2: Establish the shape of the data
Before excluding anything, describe what you have. How many unique queries? What share of impressions comes from the top 10 queries versus the long tail? What is the impression-to-click distribution? What proportion of rows have zero clicks?
Zero-click rows are normal and expected, especially at low average positions. In our own property, the July 20 to August 16, 2026 window recorded 63 clicks against 118,567 impressions — a CTR of roughly 0.05% at an average position of 31.29. Those are our own observations rather than a benchmark, but they illustrate the point: at position 31, almost nothing is clicked, and a report that treats every zero-click query as suspicious would exclude nearly the entire dataset.
Step 3: Classify, do not delete
Add a column. Tag each row rather than removing it. A workable taxonomy:
- Core commercial — direct service and product terms in your markets.
- Supporting informational — questions and research terms a real buyer would plausibly type.
- Brand — your name and variants, including misspellings.
- Out of market — clearly relevant intent, clearly wrong geography.
- Off topic — no plausible relationship to the business.
- Unparseable — strings with no coherent linguistic structure.
Only the last two categories are candidates for exclusion from the priority view, and both stay in the reviewed view with their tag intact.
Step 4: Write rules, then apply them
A rule is a written statement of what is excluded and why, applied identically every month. "Excluded: queries containing non-Latin scripts, because we serve English-language markets only" is a rule. "This looked like bot traffic" is not.
Rules should be conservative by default. When a query is ambiguous, keep it. The cost of one noisy row in a report is small. The cost of silently excluding a query that represents a real customer segment is a strategy built on a hole in the data.
Step 5: Apply regex only where it is genuinely deterministic
Search Console supports RE2 regex filtering in the performance report, which is the right tool for repeatable, unambiguous exclusions. It is the wrong tool for judgement calls.
Patterns that hold up well:
^(?i).*\b(vancouver|burnaby|richmond|surrey|coquitlam)\b.*— an inclusion filter to build a local-intent view.(?i)\b(thinkprofits|think profits)\b— brand isolation, so branded and non-branded performance are never averaged together.[^\x00-\x7F]— flags queries containing non-ASCII characters for review. Note "for review": this catches accented French terms as well as unrelated scripts, so it is a triage filter, not an exclusion filter.^\S{40,}$— single unbroken tokens of 40 characters or more, which are almost never human-typed queries.(?i)\b(free download|crack|torrent|\.apk)\b— off-topic terms that recur across many properties.
Two practical cautions. RE2 does not support lookarounds, so patterns written for PCRE may silently fail to match rather than error. And Search Console's regex filter is case-sensitive unless you prefix (?i), which is the single most common reason a filter appears to do nothing.
Test every pattern in the interface with "custom (regex)" and confirm the match count looks sane before it goes into a saved view or an automated pipeline.
Step 6: Reconcile the totals
After filtering, check what you removed against the raw totals. If your exclusion rules dropped more than a small percentage of clicks, something is wrong — the rules are catching real demand. Impressions can legitimately drop by a large share, because noise is overwhelmingly a zero-click phenomenon. Clicks dropping is the alarm.
Document the reconciliation each month: raw impressions and clicks, reviewed impressions and clicks, priority impressions and clicks. Three lines that make the whole process auditable.
The anonymized-query problem
Search Console withholds rare queries for privacy reasons. Those impressions and clicks appear in your totals but never in your query table, which produces a permanent gap between the sum of your rows and the reported total.
This matters for filtering in three ways. First, your query-level analysis is always incomplete, so conclusions drawn from it should be stated as directional. Second, the anonymized bucket is disproportionately long-tail, meaning the queries you cannot see are exactly the type you should be least aggressive about excluding when you can see them. Third, comparing filtered query sums across periods introduces drift, because the size of the hidden bucket changes.
The practical response is to report page-level and totals-level numbers for trend, and query-level numbers for direction and opportunity — never the reverse.
Filter governance
Filters accumulate. Without governance, a reporting setup ends up with rules nobody remembers writing, quietly hiding a growing share of the data.
Keep a filter register with one row per rule:
- The rule, written in plain language.
- The regex or condition that implements it.
- Why it exists.
- Who approved it and when.
- The date it was last reviewed.
- Impressions and clicks it excluded last month.
That last column is what keeps the register honest. A rule that starts out excluding 200 impressions and grows to excluding 40,000 has changed meaning, and it needs re-examining regardless of how sensible it was when written.
Review the register quarterly. Retire rules that no longer fire. Re-approve rules that now exclude materially more than they did.
Automating without losing the audit trail
Once the rules are stable, the workflow should run itself. A reasonable setup pulls the query export through the Search Console API on a schedule, writes the raw rows to storage untouched, applies the classification and exclusion rules as a separate step, and outputs the reviewed and priority views as derived tables.
The non-negotiables in any automated version:
- Raw data is written before rules are applied, and never overwritten.
- Rules live in a versioned configuration file, not embedded in a dashboard.
- Every derived row keeps the tag that explains its classification.
- The pipeline logs the exclusion counts each run.
A dashboard that cannot answer "what was excluded and why" is not a reporting system; it is a filtered screenshot with extra steps.
Monthly QA checklist
- Raw export archived with date range in the filename.
- Reconciliation of raw, reviewed and priority totals recorded.
- No exclusion rule dropped more than a small share of clicks.
- New off-topic patterns reviewed before any new rule is added.
- Filter register reviewed for rules that changed scope.
- Branded and non-branded reported separately.
- Trend commentary based on totals and pages, not on filtered query sums.
- Report language avoids claiming query origin.
Where this fits
Query hygiene is unglamorous, and it is also the difference between a report that survives scrutiny and one that quietly misleads for a year. Clean views make ranking movements interpretable, make CTR a usable metric again, and stop noisy impressions from masking genuine declines in commercial queries.
This is part of what our marketing reporting service sets up: preserved raw data, documented rules, and a priority view that reflects the queries your business is actually competing for. If the underlying visibility work needs attention too, it sits inside a broader SEO program.
If you want a quick read on the technical and AI-visibility foundations behind those queries, run your site through the tool below.
The rule to hold onto: exclude with a written reason, keep the raw data forever, and never tell a client where a query came from — because Search Console never told you.
