Chrome Web Store rejected my extension in 10 minutes — the line that caused it

I had spent two weeks on a browser extension. The package passed the validation, the screenshots were ready, the privacy policy was written. I hit submit at 9 pm and went to make tea.

Ten minutes later the email arrived: rejected — "keyword spam in the description".

Not a code problem. Not a permissions problem. A copywriting problem, caught by an automated reviewer before any human ever looked at it.

Here is exactly what I did wrong, because it is a mistake almost every indie extension developer makes, and the fix takes five minutes.

What the rejected description looked like

The extension is a cookie-banner tool. I wanted the listing to be searchable, so I wrote a description that listed every consent platform the extension supports:

Automatically rejects cookie banners on OneTrust, Cookiebot, Quantcast, Didomi, Usercentrics, Iubenda, Sourcepoint, TrustArc and more...

Eight product names in a single sentence. It reads like a feature list. To a search engine it looks like keyword stuffing. To the reviewer's classifier it looks like exactly what it was: an attempt to rank for other companies' brand names.

The rejection reason was not vague either. It did not say "your extension may violate policy." It named the section and the violation type: keyword spam in the description. And it happened in under ten minutes, which tells you the first pass is purely automated — embedding similarity against known spam patterns, plus a brand-name frequency check.

Why this is such an easy mistake

Because listing integrations feels honest and useful. If your tool works with twelve platforms, saying so is not a lie. And in a README, listing dependencies is normal practice.

But the store listing is not documentation. It is an ad, and the ad has a search index behind it. When your description contains eight well-known competitor-ish brand names, you are not describing compatibility — you are bidding on their traffic, and the store knows it.

There is a second-order problem nobody talks about: the brand names do not help you anyway. Someone searching "OneTrust cookie banner" wants OneTrust's documentation. Someone searching "auto reject cookie banners" is your actual buyer, and that phrase is nowhere in the list of brand names.

The rewrite

I deleted every brand name and described the capability instead:

CookieGuard recognises the consent platforms most sites run on rather than a list of individual domains, plus a text-matching fallback that reads the banner in 35 languages.

Same information about coverage. Zero third-party trademarks. It passed on resubmission.

Note what changed structurally: the original sentence was a list of nouns, and the rewrite is a description of behaviour. That is the pattern worth remembering — describe what the software does, not who it interoperates with.

If you genuinely need to name a third party, say "works with major consent platforms" and put the specifics in your own documentation, where no store classifier is reading them.

Three more rejection triggers I hit later

The keyword-spam one was the most expensive, but not the only one. While shipping the rest of the portfolio, the same automated reviewer and the package validator produced three more:

1. extDescription has a hard 132-character limit in the package manifest. Not the store listing — the manifest field, which gets validated at upload. I had a description at 148 characters in six locales and it failed with a message about a field "conversion being too long" in a locale I was not even looking at. Fix: count characters per locale, not per language, and remember that accents and non-Latin scripts count as one character each in the JSON but may render differently.

2. Naming another browser in a localized description triggers a warning. When you submit to Microsoft Edge, writing "works in Chrome" in a German or Japanese description gets flagged as referencing a competing browser. I had to rewrite eight locales to say "the browser's built-in model" instead of naming anything. It is a fair rule and it is easy to trip if you translate from an English original that mentions Chrome naturally.

3. Search terms have a hard cap, and it is per locale. Seven terms per language, twenty-one unique terms total across the whole listing. I exceeded it by two words in Russian and one in French and the form simply refused to save. Nobody tells you this in the UI until you hit it.

What I would do differently

If I were starting the listing today, the checklist would be four lines:

1. Write the description with zero third-party proper nouns. If you catch yourself typing a brand name, replace it with what it does for the user.
2. Count the manifest description per locale before packaging. 132 characters, hard limit, validated at upload.
3. Never name another browser in a localized field. Say "your browser" and move on.
4. Budget your search terms before writing them. They are a scarce resource, not a wishlist.

The uncomfortable part is that all four are copywriting constraints, not engineering ones. I had unit tests for the rejection logic and none for the listing text, because I thought of the listing as packaging rather than as part of the product. Store reviewers disagreed.

The thing that still surprises me

The rejection was, in the end, a good outcome. The rewritten description converts better than the original, because it explains the tool instead of name-dropping. The version that tried hardest to be found for other companies' keywords was also the version that told the fewest people what the product actually does.

If you are waiting on a review right now and you listed a bunch of platform names in your description — that is probably why. You can edit the copy without resubmitting the package, and the fix is usually a five-minute rewrite.

I build small privacy-first extensions at GlenKit. The cookie tool mentioned above is CookieGuard — the description in this post is the one that finally shipped.