Google Ads Negative Keywords: Test Match Behaviour, Scope and Conflicts

Google Ads negative keywords exclude searches according to the negative’s wording, match type and scope. A useful exclusion must pass two tests: it should stop the demand you have deliberately ruled out, and it should preserve the demand your business can serve. Checking only the first test is how an apparently sensible list can become a source of lost opportunities.

Start with a small exclusion-test matrix before changing an account. For each candidate, record the unwanted request, the campaigns it should affect, a valuable counterexample, the expected matching outcome and the person reviewing the decision. A row that exposes a conflict is useful: it gives you a chance to narrow or reject the exclusion before it affects delivery.

This guide focuses on those mechanics and regression tests. For the recurring process of finding and classifying search terms, use Canada Create’s high-intent search-query guide. If the underlying problem is unsuitable enquiries rather than a demonstrated query mismatch, start with the lead-quality diagnosis guide.

Evidence and example note: Google’s public documentation was checked on 8 October 2026. Every business, campaign, query scenario and decision in the worked examples is fictional. The matrix contains simulated expectations, not observed Google Ads matching results. No account was connected, no exclusions were uploaded and no live campaign was tested.

Define the exclusion as a business decision first

A negative keyword is the implementation of a decision. Before choosing its text, finish this sentence: “This campaign should not pay to attract people requesting ___, because ___.” The second blank needs a business reason that someone responsible for the offer can defend.

“We do not sell replacement components separately” is a specific service boundary. “People who mention price are bad leads” is an assumption. “The repair campaign should not attract course registrations” is a campaign objective. “Nobody in our account should search for courses” becomes a different decision if another campaign advertises training.

Separate a permanent restriction from a temporary problem. A company that never offers a particular service may need a different exclusion from a company that has no appointments this week. A temporary capacity issue should have an expiry condition. Otherwise, a short-lived operational problem can become a long-lived rule that nobody remembers to revisit.

Also distinguish the request from the person. A customer who asks for a free estimate may be ready to buy a substantial project. Someone researching repair costs may be preparing a budget. The query alone does not establish their income, seriousness or eventual purchase. Keep the proposed rule tied to the service and campaign objective.

Write the decision in ordinary language before putting it into the matrix. A useful fictional example is: “Exclude self-service repair-manual requests from the repair campaign, while preserving requests to hire a technician.” That gives the reviewer both an exclusion target and a protected outcome. “Block manual” gives them neither.

For every proposed exclusion, ask a colleague who understands sales or service delivery to supply the strongest valid counterexample. This is deliberately different from asking whether a word looks irrelevant. A counterexample forces the decision to survive a plausible customer request.

If the team cannot agree whether the request is valuable, record the ambiguity and hold the candidate. A spreadsheet can test a specified rule, but it cannot settle an unresolved commercial policy. Do not disguise uncertainty by choosing the broadest match type.

Understand negative broad, phrase and exact match

For Search, Google describes three negative match types: broad blocks when all terms occur, regardless of order; phrase requires the stated phrase in the same order; exact requires the complete terms in that order without extra words. These are negative-keyword rules, not positive-keyword definitions. See Google’s negative keyword documentation.

Keep the raw text and match type in separate worksheet columns. Quotation marks and brackets in this article show conventional match notation; they are not part of the raw text stored in the companion matrix. This separation makes accidental changes easier to spot.

In the fictional matrix, broad repair manual is tested against both boiler repair manual and manual boiler repair service. The first is an intended exclusion. The second is a deliberately challenging counterexample: imagine that the company services manually operated equipment and wants that enquiry. Both contain the two candidate terms, so the simulated broad result conflicts with the second business objective.

Changing the candidate to phrase match is a proposed repair to that specific problem, not a universal preference. The reviewer still needs to consider longer requests containing the ordered phrase. Narrower syntax can remove one conflict while leaving another.

Exact match can be useful when the decision concerns one complete request. However, a successful test for that request does not establish coverage of longer wording. Treat each candidate as a hypothesis whose reach needs explaining. The best choice is the one justified by the intended boundary and the counterexamples, not the one that produces the longest exclusion list.

Choose where the exclusion belongs

Match type describes the text condition. Scope describes where that condition is applied. Both belong on the same decision record. A carefully written negative can still be harmful when attached to the wrong campaign or inherited from a broader level.

Google documents account negatives as applying automatically to eligible Search and Shopping inventory across relevant campaign types, including Search, Performance Max, App, Shopping, Smart and Local. That is broader than a single Search campaign, and it is not a claim about every placement on every channel. See account-level negative keywords.

Google’s instructions for adding negative keywords cover ad-group and campaign selection and applying lists. A shared list is a managed collection applied to campaigns; its name does not establish its coverage. Google also explains that editing a list affects the campaigns sharing it in About negative keyword lists.

In the fictional business used here, Repair and Install sell technician services, while Workshops sells paid training. A service-only list containing a training-related exclusion may be a candidate for Repair and Install. Attaching the same list to Workshops would contradict the offer that campaign promotes.

The important review object is therefore the pair of list and membership. “Service-only list reviewed” is incomplete. “Service-only list reviewed for Repair and Install; Workshops deliberately excluded” is actionable. Save that membership alongside the test cases so a later attachment change can be assessed against the original intent.

For ad-group rules, include the parent campaign. Labels such as “Boiler” may appear in several campaigns and can be renamed. In a real implementation record, retain stable platform identifiers where available, as well as readable names. The public examples use fictional labels only.

Account-wide negatives deserve particular care when the business has multiple divisions, franchise services, recruitment activity, training or a separate product catalogue. Ask each affected offer owner for exceptions before elevating a local rule. Convenience is not evidence that the same restriction is valid everywhere.

If you cannot describe the affected scope in one clear sentence, resolve the account map before finalizing the negative. The point is not to make the map elaborate. It is to know which valid request could disappear if the change is applied.

Test valid demand before accepting a broad exclusion

Generic “bad word” lists are attractive because they look decisive. Their weakness is that the same word can describe very different requests. Build a protected-demand set that reflects the business’s actual offers, including the awkward phrases customers might use.

The fictional matrix includes free boiler repair estimate. An account-wide broad negative for free would conflict with an advertised free estimate in the simulated review. The business decision concerns unpaid repair work, while the negative concerns a word that also appears in a valid offer.

Similarly, small boiler repair jobs can describe a customer’s projects rather than employment. Rejecting the broad candidate jobs in this example does not mean employment enquiries must be accepted. It means a more specific candidate, such as a recruitment phrase, deserves its own tests.

Combined requests also matter. A business might accept a project involving installation and repair even when a particular ad group mainly promotes repairs. An exclusion for installation can make the account structure look tidy while removing a commercially sensible enquiry. Record whether the combined project should remain eligible somewhere and whether the proposed scope supports that decision.

Test language that reverses an apparent meaning. In the fictional request boiler repair without free parts, the customer may be saying they expect to pay. The matrix deliberately marks the broad free candidate as conflicting with that protected scenario. Do not assume a negative will interpret the business meaning you had in mind.

Use at least one ordinary counterexample and one difficult counterexample per candidate. The ordinary case prevents obvious mistakes; the difficult case exposes hidden assumptions. For a business offering estimates, financing, warranties or consultations, make those offers part of the protected set.

A protected query is a review fixture, not a promise to buy every matching click. It simply means the proposed exclusion should not remove that opportunity for the reason currently under review. Other business decisions may still apply. Keeping those decisions separate makes the negative easier to explain and reverse.

Handle variants, accents and Canadian language needs explicitly

Google says negative keywords do not expand to close variants generally, but its current guidance specifically accounts for casing and misspellings. Synonyms and singular/plural forms need separate consideration. It also treats accented and unaccented negatives differently. These details are documented in About negative keywords.

A review should therefore avoid two opposite shortcuts: assuming one English term excludes every related concept, and generating hundreds of spelling permutations without a reason. Instead, identify the concepts the business has excluded and the actual language forms that need consideration.

In the matrix, repair manuals is a distinct coverage question from repair manual. The reviewer also tests repair handbook separately. These are fictional examples of why a concept-level decision needs more than a single row. The worksheet is not a translation engine or a catalogue of all possible expressions.

For an English/French business, ask someone who understands the service vocabulary in each language to review proposed exclusions and protected examples. A translation that looks reasonable in isolation may describe a different service, qualification or customer task in context. Keep the original query wording visible, alongside a plain-language explanation if needed.

The fictional jobs candidate is tested against emploi technicien chaudière. The worksheet does not assume automatic translation of the negative. The appropriate next step is a French-language exclusion decision, with a French-language counterexample, rather than marking the English candidate as comprehensive.

Accents deserve a separate row when relevant. A business-policy example using café and cafe tests whether the planned wording covers the intended form. Preserve accents in your files; do not silently strip them while cleaning data. A text-normalization convenience can change the question you are testing.

Language settings are also changing. Google’s current documentation says a transition starting in September 2026 removes campaign-level language targeting for Search and stops that setting applying to Performance Max’s Search Network ads. Search matching instead uses ad language and user comprehension. Selected language settings continue to apply to channels such as YouTube, Display, Discover and Gmail; Shopping ads within Performance Max are not affected by language settings. Confirm the current behaviour for the account rather than relying on an older interface walkthrough. See Google’s language-targeting guidance.

For this review, the practical consequence is simple: language is part of the test context. Do not use a campaign-language label as proof that another language can never appear in a customer’s search. Preserve the query, the ad language and the business’s ability to serve the request as separate facts.

Respect campaign and platform limitations

The matrix is designed around Search exclusion decisions. It must not be presented as a universal simulator for every Google Ads inventory type. When a row concerns a different campaign or channel, first verify that the selected negative control applies there.

For Performance Max, Google currently supports campaign negatives and existing negative lists, but their exclusion effect is limited to Search and Shopping inventory. An account negative is not a universal Performance Max placement filter. Google’s Performance Max negative-keyword instructions describe that boundary.

The fictional YouTube row in the matrix is intentionally marked out of scope. It is a query-shaped fixture used to expose an incorrect assumption, not a record of a YouTube impression. Passing Search tests gives no evidence about placement controls on that channel.

For Display and Video, Google describes different behaviour and does not support treating negative phrase and exact settings as Search-style controls. Its adding instructions say those negatives are handled as broad match, and unrelated-content controls need their own review. See Google’s campaign instructions. Keep those cases outside the simple Search simulation.

Current published limits are also scope-specific:

• Account-level search/shopping negatives: 1,000, according to the account-level documentation.
• Negative lists: 5,000 keywords per list and up to 20 lists per account; Google’s limits page separately describes manager and child accounts.
• Campaign negatives: 10,000 per campaign. The published Display/Video maximum is 1,000.

The list and campaign figures come from Google Ads account limits. Google also confirms the 10,000 campaign-level figure for Performance Max in its Performance Max questions and answers. Limits are capacity ceilings, not suggested list sizes.

There are text edge cases too. Google notes that a negative appearing after the sixteenth word in a long search may not prevent serving. It also documents symbol handling, including meaningful accent differences and ignored or invalid operators. Do not treat punctuation as a programmable query language. Review unusual inputs against the current matching and symbol guidance.

A sensible response to an edge case is “needs platform review”. Replacing that label with a confident pass would make the worksheet look more complete while making it less useful. Keep the boundary visible and explain what additional evidence would be needed.

Build the exclusion-test matrix

Download the negative-keyword exclusion matrix and validation kit (ZIP).

Use one row per candidate, query and context combination. Several rows can share the same candidate ID. This avoids the common problem of putting three queries in one cell and writing “passes” without explaining which query was evaluated.

The companion set contains a blank CSV, a 26-row fictional CSV, a field dictionary, instructions, an offline Python runner and its validation report. The blank file contains headers only. Nothing in either CSV is an upload specification for Google Ads. You can also start a worksheet by copying this header:

test_id,candidate_id,negative_text,match_type,scope,applies_to,test_context,query,intended_exclusion,desired_outcome,expected_outcome,valid_query_risk,ambiguity,review_decision,reviewer,reviewed_on,basis,observed_live

The fields separate three questions that otherwise become confused: what the business wants, what the candidate is expected to do, and what has actually been observed. A simulated matching success can still represent a bad business decision.

Record the candidate and context

negative_text holds the proposed wording without match notation. match_type identifies broad, phrase or exact. scope identifies account, campaign, ad group or list. applies_to records the intended targets or list membership. test_context identifies the campaign, ad group or inventory being assessed.

Do not leave context implicit. Two identical query strings can have different desired outcomes in different campaigns. A training request may be unwanted for repair services and valuable for a workshop. Copy the query into two rows rather than forcing one verdict to cover both.

Separate desired and expected outcomes

Use block or preserve for the desired outcome. Expected outcomes are blocked, not_blocked_by_candidate, out_of_scope or needs_platform_review. “Not blocked by candidate” is intentionally narrow: it says nothing about whether an ad will actually serve.

The risk field describes the valid demand that could be affected. The ambiguity field explains what remains unsettled, such as a warranty policy, unclear customer meaning, a missing attachment or an unsupported simulation case. Write an explanation another person could act on, rather than “check this”.

Keep review separate from test execution

Use candidate when a proposal is ready for consideration, revise when wording or scope needs changing, reject when the proposal conflicts with the business rule, and hold when evidence is insufficient. None of those example labels authorizes a live change.

The reviewer and review date remain blank in the fictional files. A genuine reviewer fills them only after assessing the actual proposal. Keep observed_live as not_tested until a separate, documented platform check exists. Never copy a synthetic result into that column.

The basis field explains whether the row uses a simple rule simulation, a scope check, a language review or a documented behaviour that the local exercise does not model. This small distinction prevents a neatly formatted spreadsheet from being mistaken for an integration test.

Work through a fictional exclusion review

Imagine a Canadian heating business with Repair, Install and Workshops campaigns. It repairs equipment, offers estimates and sells separate training workshops. These are invented business rules, not a description of a Canada Create client. The team has already identified several requests for consideration and now needs to test proposed exclusions.

Decision one: manual requests

The team begins with broad repair manual. The basic exclusion case behaves as intended in the simulation, but the valid-demand counterexample fails. That is enough to reject this version of the proposal for the fictional business. A majority of passing rows would not erase a known protected-demand conflict.

The next version uses phrase match and is evaluated independently. It preserves the particular reversed-order counterexample, but a plural request remains a coverage question. The reviewer should decide whether an additional candidate is justified and give it its own protected examples. Quietly adding more terms without recording the reason would lose the audit trail.

The exact candidate illustrates a different trade-off. It can address the complete short request in the example, yet does not meet the broader desired exclusion for the longer manual query. The row is marked revise because the proposed implementation and intended coverage disagree. This is a coverage failure, not evidence that exact negatives are generally unsuitable.

Decision two: free services and estimates

The broad free candidate is rejected because the fictional company advertises free estimates. A narrower exact candidate for free boiler repair is then considered. It preserves the estimate example in the simulation, but the business has not settled how warranty requests should be treated.

The correct disposition is hold. A manager must decide whether warranty work is supported by this campaign and whether the short query is sufficiently clear. A passing text test cannot answer that question. The reviewer records the unresolved policy, rather than presenting the narrower candidate as approved.

This distinction is valuable in any business that combines paid work with a free first step. A consultation, sample, assessment or estimate may be part of a legitimate buying process. Test the advertised offer itself before excluding a word that appears in it.

Decision three: training and list membership

The service-only list is intended for Repair and Install. A workshop query in Workshops is preserved by scope in the example: that campaign is not a member. Moving the same candidate to account scope produces a protected-demand conflict. The wording has not changed; the decision has.

A second scope fixture removes Repair from the list membership while keeping the manual candidate unchanged. The unwanted request is now out of scope. This catches a different error: a carefully reviewed list that was never attached to the campaign it was meant to protect.

These two fixtures belong together. One checks excessive reach; the other checks missing coverage. A review that considers only blocked words will miss both operational mistakes.

Review conflicts across the combined configuration

Candidate-by-candidate checks are necessary, but they are not the last step. Build a view of every applicable negative affecting each protected context: account entries, attached lists, campaign entries and ad-group entries. Then ask whether the protected requests survive the combined set.

A narrow replacement does not solve a problem if an older broad negative remains elsewhere. In the fictional estimate case, adding a carefully scoped exact exclusion would not repair the conflict while the account-wide free entry is still applicable. The change record must identify the conflicting entry and the intended replacement relationship.

Check overlap with the positive keywords and intended offers too. Google warns that overlapping negatives and regular keywords can prevent ads from showing in its negative-keyword setup guidance. Do not assume that adding a positive exact keyword creates an exception to an applicable negative.

For each conflict, record the layer responsible. “Estimate query blocked” is less useful than “account candidate N04 conflicts with protected estimate request T08”. A precise reference makes the repair reviewable and stops the team from removing unrelated protections.

Do not solve one collision by deleting an entire shared list without reviewing its other duties. The same list may contain justified exclusions for several services. Consider narrowing the candidate, changing the list membership or separating rules with different scopes. Choose the smallest understandable change that resolves the documented problem.

Retain rejected proposals as test history. They explain why a tempting generic negative was not used and help prevent someone reintroducing it during a later cleanup. A short reason can be enough: “Rejected because it also blocks our advertised free estimate.”

Finally, distinguish routing from eligibility. Excluding a query from one campaign does not establish that another campaign will receive it. This worksheet records protected opportunities and exclusion behaviour; it does not certify auction participation, budget availability or a guaranteed destination.

Turn the matrix into a compact regression check

A regression check repeats previously important cases after a proposed change. Its purpose here is to catch a familiar protected request becoming excluded, or a required exclusion losing its intended scope. You do not need a software framework to do this: a versioned worksheet with stable test IDs is enough.

Keep a baseline containing the current candidate text, match type and membership. Make the proposed version separately. Evaluate the same protected and excluded fixtures against both versions and record what changed. This creates a readable explanation of the intended difference.

When a list gains a campaign, add that campaign’s protected requests before considering the attachment complete. When a business launches a new service, revisit negatives that name that service or its vocabulary. When an offer changes from paid assessment to free assessment, the protected set should change with it.

Do not discard the old expectation silently. Date the policy change and explain why the desired outcome changed. Otherwise, a later reviewer cannot tell whether the business changed its mind or the test was edited merely to make a proposal pass.

Keep the suite proportionate. For a small proposal, a few strong intended-exclusion cases, plausible protected cases and scope controls may be enough. A thousand nearly identical spelling rows can hide the one business exception that matters. Prefer cases that test a different assumption.

The fictional companion includes intentional failures and unresolved cases. Its quality is not measured by how many rows say blocked. Its value is that it exposes six kinds of decision risk: excessive wording, insufficient wording, excessive scope, missing scope, ambiguous meaning and behaviour outside the simple simulation.

This regression process begins when a candidate change is proposed. It does not prescribe a recurring search-term review schedule. The ongoing discovery and classification process remains in the linked high-intent guide.

Prepare a change that someone can review and reverse

Once the tests support a proposal, prepare a short change record. Include the reason, exact candidate text, match type, affected scope, list membership, protected cases and outstanding limitations. Identify the current entries that would be removed or replaced; adding a new entry and forgetting the old one is a different configuration.

Record the prior state in enough detail to restore it. For a shared-list change, that includes the list’s contents relevant to the proposal and its campaign attachments. For a local negative, it includes the original level and parent campaign or ad group. A screenshot alone may be difficult to compare later; a concise text record helps.

The implementer should compare the proposed scope with the actual destination before saving. Similar campaign names, copied lists and renamed ad groups create avoidable confusion. Confirm the match type explicitly, then inspect the saved state rather than assuming the entry was interpreted as intended.

For a live account, keep configuration verification and performance assessment separate. Configuration verification asks whether the agreed rule exists at the agreed level. Performance assessment asks what happened to relevant demand after the change. Neither should be labelled complete solely because a spreadsheet simulation passed.

Choose a reversal trigger before implementation. A confirmed protected-offer conflict should prompt immediate investigation of the exclusion configuration. A change in lead volume requires broader interpretation because budgets, demand, reporting and other edits may also have changed. Avoid attributing every movement to the negative list.

Document concurrent changes so the account owner can interpret the evidence. If the offer, landing page, budget and exclusions all change together, a later improvement does not isolate the effect of any one component. The exclusion record should still show precisely what it was meant to accomplish.

The public files perform none of these account actions. They help an authorized account owner make the proposal concrete, review the trade-offs and preserve a recovery path.

Know what the companion checks prove

The companion’s fictional records were checked for structural consistency and simple, explicit matching expectations. The included runner reproduced 24 simple matching or scope expectations with no mismatches. The misspelling and long-query edge cases remain unevaluated, with no pass assigned. These are two unresolved cases, not two additional successful simulations. The exercise does not attempt to reproduce Google’s matching system.

A structural check asks whether every row has the expected columns, a unique test ID, a valid outcome label and a usable reason. A simulation check asks whether straightforward literal examples agree with the rule model described in the instructions. A scope check asks whether the fictional target is included in the stated context.

The report separately shows whether each simulated result meets the fictional business objective. Six protected-demand conflicts and seven coverage gaps are intentional examples: correctly reproducing a harmful exclusion does not make it a good proposal. Those checks can catch malformed files, contradictory examples and accidental loss of a protected case. They cannot prove how a live account will serve, how Google will interpret every misspelling, or whether a campaign will improve commercially. The example reviewer fields are deliberately blank, and every live-observation field remains not_tested.

After adapting the files, repeat the structural review and read the counterexamples aloud with the offer owner. A worksheet that is technically valid but describes the wrong business is still the wrong worksheet.

Common questions about negative-keyword tests

How many negatives should a small business use?

There is no useful target count in this method. Start with justified exclusions and keep only the breadth needed to implement them. The published platform ceilings do not tell you how many rules your business needs. A shorter, understandable set can be easier to review than an inherited list whose reasons have been lost.

Is phrase or exact always safer than broad?

No match type removes the need for valid-demand tests. Narrow wording can still conflict with an important offer, and it may fail to cover the intended request. Compare the proposed implementation against both sides of the decision: what should be excluded and what must remain unaffected by this candidate.

Can a shared list be reviewed once?

Its initial review applies to a particular version and membership. A changed offer, new campaign attachment or revised entry can invalidate that reasoning. Retain the protected fixtures so the team can reassess the relevant change without rebuilding the entire review from memory.

Does a passing row mean an ad will show or stop showing?

A passing row means the specified worksheet expectation is consistent with the bounded test. “Not blocked by candidate” is not “ad will show”. Cases needing platform evidence remain unresolved, and commercial outcomes require their own evidence. Keep those distinctions in every handoff.

For help reviewing exclusion scope and valid-demand risks, discuss your Google Ads account with Canada Create.