The Chrome Web Store checklist we wish we had had

Ten things that each cost us a review cycle, a wait, or a rewrite. Not general advice — every one of them is something we walked into ourselves while getting two extensions onto one publisher account this year, and each one says which time.

9 September 2026 · two extensions, one account · no signup needed to read items 1, 4 and 6 below

1. A new publisher account has a hard cap on published items, and the increase can be refused — in full below
2. Budget the review as a day and a half, and know that it is not a queue you can jump
3. Submitting a new version while one is in review replaces it and restarts the clock
4. While a version is in review, the store listing text is read-only — in full below
5. "Typed into the field" is not "saved" — reload and read it back
6. setUninstallURL is frozen into the version you publish, so that page has to be live first — in full below
7. The privacy disclosure has to match what the code does, line by line
8. Rolling back discards any pending submission — know that before you need it
9. There is no metrics API. Whatever you want to A/B, you have to measure on your own pages
10. Ask the API whether it is live. Do not ask the dashboard, and do not ask yourself

The three marked above are printed in full on this page, so you can judge whether the other seven are worth an email address before you give one.

We found this the way everyone finds it: by trying to publish the third thing. The cap is on your account, not the item. We asked for an increase and were refused, and the reason given was the account's registration age and activity — not anything about the extension.

Do this before you build the third one: publish something small and real early, so the account has age on it by the time you need the slot. The request window is monthly; the clock you are waiting on started the day the account was created, not the day you asked.

We tested this in both directions, because "it looks greyed out" is not a finding: in review ⇒ the Description field cannot be edited; review finishes ⇒ it can; submit again ⇒ it is locked again.

So the listing copy and the code are one atomic decision, not two. If the copy is wrong, you find out during the review you cannot interrupt, and you fix it after.

chrome.runtime.setUninstallURL('https://example.com/goodbye');

That string ships inside the extension. There is no dashboard field for it. If the page is not live when the version goes live, everyone who removes your extension gets a 404 on your own domain, at the exact moment they decided you were not worth keeping — and changing it costs a full review.

Make it a gate you can run, not a note you agree with:

curl -s -o /dev/null -w '%{http_code}' https://example.com/goodbye

Cheap way to actually exercise it: load the unpacked extension, then remove it from chrome://extensions. Chrome opens the URL for an unpacked extension too, so you see the 404 before your users do.

They are on the next page, immediately. There is no email to wait for — we do not have a mailing list and we are not going to pretend we do. The address is how we reach you if we ever have something worth reaching you about, and that is the only reason we ask for it.

We store the address and the date. Nothing else, and it is not shared, and there is no tracker on this page. Reply to anything you ever get from us and we delete it.

Written while shipping Keyboard Shortcuts and Highlight Reader.