A negative keyword can sit in your list, spelled the way you meant it, match type set, and still never block the query you added it for. The query keeps appearing in the search terms report, keeps taking clicks, and keeps costing money — and because the negative is visibly there, it is the last thing anyone suspects. This is a different failure from the ones the rest of this cluster covers: it is not a negative blocking a keyword you wanted, and it is not a list that has hit its size limit. It is an individual negative that looks correct and does nothing. The causes are mechanical and knowable, and every one of them is checkable in your own account in a couple of minutes.
The biggest cause: negatives do not match close variants
The single most common reason a negated query keeps showing is that the live query is a close variant of your negative rather than an exact string match, and negative keywords do not match close variants. A positive keyword expands to catch plurals, misspellings, abbreviations and reorderings; a negative keyword does the opposite — it blocks only forms it literally contains. Negate “free” and the query “freee” still gets through; negate “jobs” and “job” is a separate word you have not blocked. This is deliberate on Google's part, so that a careless negative cannot wipe out a swathe of legitimate traffic, but it means your negatives leak unless you add each variant you actually see.
The practical consequence is that you cannot negate a concept once and move on. You negate the specific strings that appear in your search terms report, and you keep adding forms as new variants surface. The full behaviour — plurals, misspellings, and how punctuation on the negative sets its match type — is covered in the companion post on negative keyword match types and the plurals trap. For the rest of this post, assume the word is right and the problem is somewhere else: the length of the negative, or a symbol inside it.
The 80-character, 10-word cap that truncates long negatives
Each negative keyword is limited to 80 characters and 10 words, per Google's negative keywords documentation. Go over either limit and the entry does not quietly match a long query — it errors or is rejected. This trips people who try to kill a long junk search by pasting the whole thing in as a negative: a fourteen-word “how to do X for Y in Z without paying for A” review query simply will not save as one negative. If it does fit under the cap but is still long, a negative broad match of eight or nine words is almost as useless, because negative broad requires every one of those words to appear in a query before it blocks — and a real search rarely contains all nine in some order.
The fix is to stop negating whole queries and start negating the distinctive fragment that only the junk searches share. If “free,” “salary,” “course” or a competitor's brand is the word that marks a query as waste, that short negative catches the whole family of long queries built around it. Long verbatim negatives are both fragile and narrow; a two or three word fragment is what actually scales. This is the same reasoning behind grouping search terms into patterns rather than negating each one individually.
Accents and ampersands: two spellings, two separate negatives
Google treats an accented word and its unaccented form as two different negative keywords. Its own example is that “sidewalk cafe” and “sidewalk café” are distinct, which means a negative for one does nothing to the other. If your product or category has accented terms — and plenty of place names, loanwords and brand names do — a negative built from the unaccented spelling will keep letting the accented query through, and the search terms report will keep showing it. When both forms appear in the report, you need both as negatives.
The ampersand behaves the same way: “socks & shoes” and “socks and shoes” are different negatives, so blocking the symbol version leaves the spelled-out version live. Along with the accent case, this is a reminder that negatives match the characters you saved, not the meaning you intended — two strings a human reads as identical can be two separate entries to Google, and you have only blocked the one you typed.
Periods, plus signs and operators Google quietly rewrites
Some symbols are not matched literally at all — they are ignored or stripped when you save the negative, so the entry Google stores is not the one you typed. Periods are ignored: “Fifth Ave.” and “Fifth Ave” are the same negative. Plus signs are usually ignored too, so “blue+car” is read as “blue car.” And the site: operator (and search operators generally) is removed, so a negative you paste as [site:example.com dark chocolate] is saved as just [dark chocolate] — which blocks a great deal more than you intended, or nothing, depending on the rest of your account.
None of these throw an error, which is exactly why they are dangerous: the negative saves, looks right in the list, and matches a different string than the one you can see. If you build negatives programmatically, from a URL, or by copying operators out of a search box, assume the stored form has been rewritten and check what actually landed. The safe habit is to type negatives as plain words and let the match-type punctuation — quotes for phrase, brackets for exact — be the only symbols you rely on.
The symbols that make the negative fail to save at all
A further set of symbols is rejected outright. Commas, exclamation marks, @, %, ^, parentheses, equals signs, braces, semicolons, tildes, backticks, angle brackets, question marks, backslashes and pipes will each trigger an error rather than saving the negative. This sounds harmless — an error is at least visible — but the failure mode is a bulk paste. When you paste a block of candidate negatives and one line contains an illegal character, the whole paste can fail, or that line is silently dropped while the rest go in, and you walk away believing a term is blocked when it was never added.
After any bulk add, the discipline is to reconcile: the number of negatives you intended to add should equal the number now in the list. If a query you “added” keeps appearing, the first thing to check is whether it ever saved. This is the quiet cousin of over-building a list — the opposite problem to over-negating and throttling good traffic, where the negatives are all present and doing too much. Here they are absent and doing nothing, and the symptom looks the same from the search terms report: money going to a query you thought you had handled.
How to find your silently-failing negatives
Work backwards from the symptom rather than auditing the whole list. Open the search terms report, find a junk query that is still costing money and that you believe you negated, and copy its exact text. Then open your negative keyword lists, search for the term you added, and compare the two character by character. Is your negative a plural or accented variant of the live query? Is it phrase or exact match when the query does not contain that exact word sequence? Is it longer than ten words? Does it contain a period, a plus sign or an operator that changed how it was stored? One of those questions almost always explains the leak.
The fix in every case is the same: re-add the negative in the exact form the live query actually takes, in the least specific match type that still isolates the junk. Doing this across a whole account — matching every leaking query back to the negative that should have caught it — is slow by hand, which is the reason hidden wasted spend persists even in accounts with long negative lists: the list looks comprehensive, and the gaps are invisible until you line each query up against the negative that was supposed to block it. A negative keyword you never verified is a negative keyword you cannot assume is working.
Related reading
For how punctuation sets a negative's match type and why plurals leak, see negative keyword match types and the plurals trap. For the opposite failure — negatives that are present and blocking too much — see over-negating and throttling good traffic. And for why waste survives in accounts that already have long lists, see finding hidden wasted spend in the search terms report.