Rejected for Keyword Spam, Not for the Code

I assumed a Chrome Web Store review looked at the code and the permissions. What came back was a rejection about the description. The reason given was keyword spam: the listing text read as a pile of search terms.

I had listed the services it works with

The listing was for Safe Privacy Mask, an extension that masks strings that look like personal or confidential information before you send them into an AI chat or a web form.

To make it concrete, the description named the places you could use it: ChatGPT, Claude, Gemini, Copilot, and a number of others.

In my head this was scope, not marketing. Where does this thing actually run? Is the service I use every day covered? It seemed more helpful to answer that up front than to let someone install it and find out.

I was not trying to rank for anything.

Intent does not travel with the text

But what a reader receives is the list itself, not the reason it exists.

When a dozen product names run together, there is no way from the outside to tell which of them are load-bearing explanation and which were dropped in for search.

"Describing the supported scope" and "stuffing keywords" look identical unless you are the person who wrote them. That was the part that stayed with me. My intention lived outside the listing, and it never reached anyone reading it.

What the published guidance actually says

Afterwards I read the Chrome Web Store spam FAQ.

It says that when you list supported websites or brands in a description you should not name more than five, and that longer lists belong in a link or in the promotional screenshots. It also suggests keeping any single keyword under five occurrences.

I had not expected a number. My listing was well past it.

The rejection and the rewrite are things that happened to me; the five-item guidance is something I confirmed in the public documentation. What follows is what I took from it.

What I changed

I dropped the enumeration and rebuilt the description around what the tool does and when you would reach for it.

Only a couple of representative service names stayed near the top. The supported-sites section became this:

After installation, it works out of the box on major AI chat services. You can check the list of supported services on the extension's settings page.

Moving the list into the settings screen was not about hiding it. Supported sites change, and a list that lives inside the extension stays accurate in a way that store copy does not. That turned out to be the better place for it, which I only noticed after the rewrite.

I did hesitate. Remove the names and it gets harder for someone to tell whether their own service is covered. Trimming an explanation to satisfy a reviewer felt like a step backwards.

I resubmitted with the rewritten listing and it went through. Which of the changes actually mattered, I have no way of knowing from my side.

A store listing is not a search document

Reading the old version again, the supported-services list had become the centre of it. What the tool actually does had been pushed behind the names.

Three things matter more to me now: what the tool does, when you would use it, and how it handles your data and permissions.

More service names did not make the tool easier to understand. In my case, cutting them made the description easier to read.

Review is part of building the thing

I am not going to write this up as a way to pass review. One rejection does not qualify me to describe a general standard, and I do not want to argue with the decision either.

What I take from it is that working code is not the finish line. The name, the description, the permission prompts, the screenshots, the privacy disclosures — all of that is part of how the tool reads to someone encountering it for the first time.

Looking at the page as a stranger would, rather than as its author, made it much clearer what needed to change.