GOOGLE ADS KEYWORD CHARACTER LIMIT: THE IMPORT ERRORS I KEEP HITTING

Almost every rejected bulk upload I've dealt with in five years came down to the same handful of causes, and the google ads keyword character limit was rarely the actual culprit — it just got the blame because it's the first thing anyone checks.

The real pattern is this: a sheet of 8,000 generated keywords fails on 340 rows, the error message is vague, and the person who built the sheet spends an afternoon trimming long terms when the problem was three commas and a trailing space. I've done exactly that. Twice.

So this article is the checklist I wish someone had handed me: what the limits actually are, which errors I hit most often, and the validation pass that has removed almost all of this pain from my workflow.

The two ceilings behind the keyword character limit google ads enforces

A keyword has to satisfy two separate constraints, and people usually know one of them.

Characters. A single keyword tops out at 80 characters. In English Search work this is almost never binding — the longest genuinely useful long-tail term I've built ran to about 55 characters. Where it does bite is in languages with longer compounds, in accented markets where encoding inflates the count, and in programmatic generation where a template concatenates four fields without checking the result.

Words. Ten words maximum per keyword. This is the one that catches people, and it's the one that appears in Google's own guidance on building a keyword list alongside the symbol rules. A term can sit comfortably at 60 characters and still be rejected for having eleven words, which is why "shorten it" is bad debugging advice: you need to know which ceiling you crossed.

My inference after years of watching this: the word cap is the more meaningful signal. Eighty characters is a storage constraint. Ten words is Google telling you the term is no longer a query anyone types — and in a broad-match world, a ten-word keyword is doing nothing that a four-word one wouldn't do better.

The four import errors I run into most

Ranked by how often they've cost me time, not by how serious they sound.

1. Invalid characters that a spreadsheet inserted for you

This is number one by a wide margin. Commas, question marks, exclamation points, parentheses, brackets outside their match-type role, percent signs, pipes — all rejected. Nobody types these deliberately. They arrive because the keyword was built by concatenating a product title ("Bosch Drill 18V (2 batteries)") or because a CSV export left a stray comma in a field. The error message points at the row, not at the character, so you're left squinting.

2. Smart quotes and em dashes from Word or Google Docs

Curly quotation marks are the most insidious version of this. Phrase match needs straight double quotes; autocorrect silently converts them, the sheet looks identical to the eye, and the upload fails or — worse — imports the term as broad match with visible punctuation. Any keyword list that passed through a word processor gets a paste-as-plain-text pass before I touch it.

3. Trailing and double spaces

Invisible, and they count. A trailing space can push a borderline term over the character ceiling and it inflates word counts in some parsers. It also creates duplicates that don't look like duplicates, which is its own problem — I've covered the cleanup side in my write-up on finding duplicate keywords across an account, and whitespace is a recurring cause there too.

4. Unclosed or mismatched match-type syntax

An opening bracket with no closing one, or a quotation mark that lost its pair during a find-and-replace. The row imports as something you didn't intend, or fails outright. This is the error most likely to appear after a bulk edit rather than at initial build — worth re-validating whenever you've done a mass rewrite of an existing list rather than only on first upload. If you're changing syntax at scale, do it deliberately rather than with a blind replace, the same way you would when planning capacity in a large account instead of pushing until something breaks.

The failures that don't throw an error

These are worse than rejections, because a rejection tells you something. A silent acceptance doesn't.

Ignored symbols. Periods and plus signs are accepted but disregarded when Google compares keywords, so "Fifth Ave." and "Fifth Ave" collapse into the same keyword. If your feed generates both, you've just built a duplicate without any warning.

The minus sign. A hyphen between two words is ignored, but a minus in front of a term causes that term to be dropped from matching entirely. A generated keyword like "office chairs -leather" is not the keyword you think it is. This one has burned me on a feed where product titles legitimately contained hyphens with inconsistent spacing.

Operators stripped out. Site and search operators get removed silently. Rare, but it happens when a term was scraped from a search-terms export rather than typed.

Truncation you didn't authorise. Some third-party tools trim to fit rather than reject. You end up with a live keyword that's a fragment of what you intended, and it looks perfectly normal in the interface.

The common thread: everything above produces a keyword that exists and spends money while meaning something other than what you specified. That's why I validate before upload rather than reviewing after — post-upload review catches rejections, not distortions.

My pre-upload validation pass

Five minutes on the sheet, in this order. It's saved me far more time than it costs.

Step 1 — Trim and collapse whitespace

Run TRIM on the whole keyword column first, before any counting. Every subsequent check is wrong if you skip this, because trailing spaces distort both length and word counts.

Step 2 — Flag length and word count separately

Two helper columns: LEN over 80, and word count over 10. Separately, not combined — because the fix differs. A long-but-valid term needs shortening; an eleven-word term usually needs deleting, since it isn't a real query.

Step 3 — Scan for invalid characters

A single regex flag for the full invalid set catches commas, brackets, parentheses, percent signs, pipes and the rest in one pass. I keep this formula in a template sheet and reuse it rather than rebuilding it each time.

Step 4 — Normalise quotes and dashes

Find-and-replace curly quotes with straight ones and em dashes with hyphens. Always after step 3, so you can see what changed.

Step 5 — Cap at the source for generated lists

For programmatic builds I put the constraints in the generator: truncate the template inputs before concatenation, enforce a word ceiling, and drop anything that trips the invalid-character filter. Reviewing 8,000 generated rows after the fact never actually happens. Constraining the generator does.

Step 6 — Upload a 50-row sample first

The cheapest step on this list. If 50 representative rows import clean, the remaining thousands almost certainly will. If they don't, you've found the pattern on a sheet small enough to read.

One adjacent note: exclusion lists have their own separate character and formatting rules, and asterisks are permitted there but not on the positive side. If you're building exclusions at scale alongside your keyword upload, the negative keyword fundamentals are worth reading before you validate that sheet the same way.

What a character limit rejection actually tells you

Here's the read I'd emphasise over any number. In every account where I've seen the google ads keyword character limit trigger at volume, the limit wasn't the problem — it was the first place an upstream problem surfaced.

Terms that are too long are almost always machine-generated from templates that concatenate without checking. Terms with invalid characters are almost always inherited from product titles or scraped exports that were never cleaned. Terms with eleven words are almost always the tail end of a generation script producing combinations nobody would search. In each case the rejected rows are a sample, and the accepted rows from the same batch carry the same defect in a milder form.

So when a sheet fails on 4% of rows, I don't fix the 4%. I look at what produced them, because the other 96% came from the same place. That reframing is the single most useful thing I've learned about this — and it's why the validation lives in the generator now rather than in the review step.

The practical takeaway

Eighty characters, ten words. Know which one you crossed before you start editing, because the fixes are different. Trim whitespace before you count anything, normalise quotes after a scan rather than before, and test 50 rows before you commit 8,000.

And when a batch fails, treat the rejections as a diagnostic on the process that generated them. Fixing the sheet gets you through today's upload. Fixing the generator means you stop having this conversation.