# How to run a negative keyword sweep without blocking good demand

Build a defensible negative keyword review queue across Google Ads, Microsoft Advertising, and Apple Ads without treating every costly query as irrelevant.

- **Author:** [R. Garcia](https://offleashmarketer.com/authors/r-garcia/)
- **Published:** 2026-08-26
- **Updated:** 2026-08-26
- **Last reviewed:** 2026-08-28
- **Evidence level:** field tested
- **Canonical URL:** https://offleashmarketer.com/blog/how-to-run-a-negative-keyword-sweep/

> **Theo's read:** The expensive query may be the symptom, not the failure.

## Quick diagnostic

- **Symptom:** A search term has spent enough to look wasteful and has few or no recorded conversions.
- **Likely break:** Intent may be irrelevant, but the real problem could also be conversion lag, broken tracking, poor routing, the landing page, the offer, or an incomplete business-outcome definition.
- **First check:** Trace the query through its triggering keyword, campaign, landing page, conversion action, and downstream outcome before choosing the negative text, match type, or scope.

A negative keyword sweep should not begin with a list of search terms sorted by cost. It should begin with a harder question: **what evidence would justify preventing this demand from entering the account again?**

That framing changes the work. A costly query with no recorded conversion may be irrelevant. It may also have arrived near the end of the reporting window, converted offline, entered the wrong campaign, reached the wrong landing page, or exposed a conversion action that bidding cannot trust. Adding a negative can remove the visible symptom while the underlying failure remains.

The useful output is therefore not an upload file. It is a review queue that keeps the query, evidence, uncertainty, proposed match behavior, scope, conflicts, and human decision together.

## Establish the decision boundary first

Record the operating context before judging a term:

- reporting start and end dates;
- account time zone and currency;
- primary conversion action and whether it is used by bidding;
- expected conversion and sales-cycle lag;
- attribution setting and any offline-import delay;
- account CPA, ROAS, or contribution target;
- minimum clicks and cost required before performance becomes decision-grade;
- protected brand, product, partner, location, and regulated terms.

These are not universal thresholds. Twelve clicks may be meaningful in a narrow, expensive market and nearly meaningless in a high-volume account. A $200 query can be unacceptable for a low-value purchase and inconclusive for a qualified enterprise opportunity.

If the thresholds have not been defined, the sweep can still organize the data. It should not disguise a guess as a performance rule.

> **R. Garcia's field observation:** In a recent cross-platform sweep, a short reporting window condemned a large set of query families that appeared to have no conversions. Extending the review to a materially longer horizon and grouping reordered phrases into normalized intent families spared roughly one third of the initial indexed set. Fewer than one in five reviewed families ultimately survived both the long-window check and the intent review.

That result did not prove every older conversion would recur. It proved that the short window was not sufficient evidence for a permanent exclusion. Conversion lag, sparse volume, match expansion, and query permutations can all make an individual row look disposable before its family is understood.

## Separate Routing Automation From Exclusion Judgment

The most useful distinction in my negative-keyword system is not automated versus manual. It is **routing versus exclusion**.

The routing layer runs unattended against pre-agreed rules. It applies narrow, exact negatives at ad-group level so a generic query cannot enter a specialized route that requires a profession, feature, or use-case signal. The query remains eligible elsewhere in the account.

The sweep does the opposite job. It proposes campaign-level exclusions for demand that appears wrong for the business everywhere. Because that decision can permanently remove a valid edge case, every proposed exclusion remains human-reviewed.

| Layer | Routing automation | Negative sweep |
|---|---|---|
| Decision | Which route should remain eligible? | Should the account stop buying this demand? |
| Typical scope | Ad group | Campaign |
| Rule shape | Pre-agreed and deterministic | Evidence plus business judgment |
| Cadence | Scheduled and unattended | Recurring review queue |
| Recovery | Reapplied from the governed rule | Removed only through another reviewed change |

Across one mature production system, the scale worked out to roughly **550 automated routing decisions for every reviewed exclusion decision**. That is a normalized ratio, not a claim that a larger negative list is better. It shows why I automate the rule-shaped work while reserving the smaller, higher-risk surface for judgment.

One routing rule deliberately used a **200-day lookback** even though related rules used shorter histories. The reason was cost distribution: forbidden-intent queries could be sparse enough to disappear from a recent window but expensive when they returned. That window was not selected because 200 is a magic number. It was attached to a documented failure mode the rule was responsible for catching.

The same standard belongs in the human-reviewed sweep. Choose the history from conversion lag, recurrence, seasonality, and the cost of a false exclusion—not from a convenient preset.

## Preserve the evidence the platform export gives you

Keep an untouched copy of every source export. Build a normalized analysis table beside it rather than rewriting the raw query.

The minimum useful row contains:

- platform and source file;
- raw and normalized search query;
- campaign and ad group;
- triggering keyword and source match type;
- impressions, clicks or taps, cost, conversions, and conversion value;
- most recent activity date when daily data is available.

Also export current positive keywords and existing negatives. A query that looks like a negative candidate may be an intentionally targeted exact keyword elsewhere in the account. That is a routing conflict, not an automatic exclusion.

For a cross-channel sweep, normalize column names but do not pretend the platforms behave identically. Do not combine costs until currencies and reporting windows align. Recurrence across channels raises the priority of the review; it does not prove the same intent or justify the same negative match type.

## Build candidate reasons that can be challenged

Start with measurable rules that can be explained:

### Enough cost and clicks, but no recorded conversion

Flag a query only when it exceeds both the cost and click thresholds. Then check whether recent activity still sits inside the expected conversion lag.

This is a candidate reason, not a conclusion. A zero in the platform can still omit phone outcomes, imported sales, assisted value, consent-limited events, or conversions credited outside the selected window.

### CPA or ROAS outside the review boundary

A query with conversions can still deserve review when CPA materially exceeds the account boundary or ROAS falls below it. The right next question is whether the term is irrelevant or whether a relevant visitor encountered an offer, price, page, location, or qualification problem.

Negative keywords control admission. They do not repair the rest of the experience.

### Repeated unwanted language

Individual exact negatives are useful for isolated queries. Recurring unwanted concepts can justify a phrase or broad negative, depending on the platform. Use n-grams or grouped themes to find that recurrence, then list representative queries that would be blocked.

Do not promote one expensive query into a broad concept rule. The wider the match behavior, the stronger the evidence and review should be.

### Query routing conflicts

Sometimes the query belongs in the account but entered the wrong campaign or ad group. The solution may be a negative at the narrow source scope combined with an intentional positive keyword elsewhere.

That is different from declaring the query unwanted everywhere. The review queue should say which destination should retain eligibility.

### A Converting-Query Collision Can Be Evidence That Routing Works

I learned this boundary during an AI-assisted audit of a production search account with a large, mature negative-keyword system. The audit joined negative criteria to converting search terms and found several queries that converted in one part of the account while being negated in many other ad groups.

The first conclusion looked rigorous: the queries convert, the negatives block them, so remove the negatives. That conclusion was wrong.

The exclusions were deliberate traffic sculpting maintained by account scripts. A specialized ad group required a profession or use-case signal in the query. When a generic query lacked that signal, an ad-group negative kept it out of the specialized route and allowed a more general ad group to compete instead. The queries converted **because the negatives sent them to the appropriate route**, not despite the negatives.

The data join was valid. The interpretation failed because it could not see the scripts acting on the same account or the business rule those scripts enforced. Human review caught the conflict before it became a permanent change, and the existing automation restored the staged exclusions during its next governed run.

This changed my sweep checklist: before classifying a converting-query collision as harmful, inspect every scope where the query is eligible, identify the route that produced the conversion, and inventory the scripts or shared systems that can reapply the negative. An analysis is only as good as its awareness of what else is acting on the account.

## Respect each platform’s negative matching rules

The phrase “add a negative” hides important platform differences.

### Google Ads

[Google Ads documents](https://support.google.com/google-ads/answer/2453972) negative broad, phrase, and exact match for Search campaigns. Google also states that negative keywords do not match close variants or other expansions the way positive matching can. Singulars, plurals, synonyms, and related forms may therefore require separate review.

For one observed unwanted query, negative exact at the narrowest useful scope is the conservative starting recommendation. Phrase or broad should require evidence that the unwanted concept repeats and a preview of potentially valuable variants that would also be blocked.

### Microsoft Advertising

[Microsoft Advertising documents](https://help.ads.microsoft.com/apex/index/3/en-us/51014) negative phrase and negative exact—not negative broad. Microsoft also does not support keyword-level negatives, so campaign, ad-group, and shared-list scope determine the blast radius.

A cross-platform system that converts every recommendation into “broad negative” is not normalized. It is wrong.

### Apple Ads

[Apple Ads documents](https://ads.apple.com/app-store/help/keywords/0059-understand-keyword-match-types) exact and broad negative keywords for search-results campaigns. Apple describes negative exact as the default and as a narrow block that does not automatically exclude close variants in the same way a marketer may expect from positive exact behavior.

Again, one observed query supports an exact review candidate. A broad negative requires theme-level evidence.

Before producing an import or API payload, verify the current first-party platform documentation. The normalized review record can remain stable while upload schemas and interfaces change.

## Give every candidate a conflict check

A proposed negative should be quarantined when it overlaps:

- an approved positive keyword;
- a protected brand, product, partner, or location term;
- an existing negative whose scope or match behavior may already cover it;
- recent activity inside the conversion-lag window;
- a platform whose supported negative semantics have not been verified;
- a query with a known offline or assisted-conversion dependency.

Quarantine does not mean “never.” It means the candidate needs an explanation stronger than the automated rule that surfaced it.

## Produce a decision queue, not an answer file

For each candidate, retain:

- the evidence and threshold that surfaced it;
- proposed negative text;
- proposed platform-supported match type;
- proposed campaign or ad-group scope;
- every conflict flag;
- checks required before approval;
- confidence level;
- blank human-decision, reviewer-note, and approved-scope fields.

The safest automation ends here. A separate approved workflow can translate accepted rows into an editor import or API mutation after the reviewer confirms the actual account state.

This division also creates a useful change record. When performance changes later, the team can reconstruct what was blocked, why it was blocked, which evidence was available, and who accepted the tradeoff.

## Add the part automation cannot know

Performance data can reveal expensive patterns. It cannot determine whether a query describes a valuable edge case, a future offer, a strategic competitor, an offline customer, or a relevant person who received the wrong message.

The sweep needs business context:

- What does the company actually sell?
- Which audiences or use cases are intentionally excluded?
- Which search language has produced qualified revenue even when platform attribution is weak?
- Which queries should be routed rather than rejected?
- What can be learned from the landing page before closing the gate?

That is the part worth documenting from real account work. The field example above demonstrates why a short-window zero is not a safe exclusion rule. It does not establish a universal six-month requirement: the appropriate history still depends on conversion lag, volume, seasonality, business change, and how quickly irrelevant traffic becomes costly.

Use the broader [paid search systems hub](/topics/paid-search/) to connect query review to conversion definitions, attribution, CRM outcomes, and budget decisions. If source preservation is part of the problem, trace the naming and handoff rules before treating the search-term report as complete evidence.

The objective is not the longest negative list. It is a smaller, explainable set of exclusions that the account can defend later.

## Before you act

- [ ] Confirm the reporting window, currency, account time zone, conversion definition, and expected conversion lag
- [ ] Export current positive keywords, existing negatives, and protected brand or product terms with the search-term data
- [ ] Preserve the raw export and require a named human decision for every proposed negative

## Theo's challenge

**A negative keyword can hide a system problem instead of solving it.**

Blocking a query may improve the visible report while leaving broken tracking, weak routing, or an uncompetitive offer untouched.

- Is the query truly outside the offer, or did the landing experience fail to satisfy relevant intent?
- Would the proposed match type block useful variants that have not accumulated enough data yet?
- Which downstream or delayed outcomes are missing from the platform conversion column?