App Store gives 100 characters in a hidden keyword field (not visible to users, only indexed). Google Play has no equivalent — Play indexes from the long description instead. Common mistakes: spaces between keywords (wasted), plurals (Apple already handles), duplication with title/subtitle. The fix is comma-separated efficiency. See title and subtitle guides for the visible fields.
Format: comma-separated, no spaces
"crm,lead,sales,pipeline,deal,tracker,manager"
Apple algorithm:
- Single-word indexing (combines title + subtitle + keyword field words)
- Plurals auto-handled (don't add both "lead" and "leads")
- Stop words stripped ("a", "and", "the" wasted)
- Synonyms NOT auto-handled (add "manager" AND "tool" if both relevant)
What NOT to waste characters on:
- Spaces between keywords (use commas only)
- Plurals (Apple stems)
- Words already in title or subtitle
- Your brand name (always indexed)
- Category name (auto-indexed via category)
Pick words that: - Have search volume in your category - Aren't already covered in title + subtitle - Match user intent (informational, transactional) - Combine well with title words for multi-word queries Example: Title: "Acme: CRM & Lead Tracker" Subtitle: "Sales pipeline manager" Already covered: acme, crm, lead, tracker, sales, pipeline, manager Keyword field (100c): "deal,prospect,contact,follow,task,reminder,team,small,business,b2b,saas" → New coverage: deal, prospect, contact, follow, task, reminder, etc. → Combined with title: "small business CRM", "B2B sales tool", "deal tracker"
Each App Store locale has its OWN 100-character keyword field. You're not limited to 100c global — you have 100c × number of locales. UK English, US English, German, Spanish, French each independent.
Aggressive ASO: research keywords per locale, fill all 100c per locale This can 3-5x your keyword footprint across markets.
Play has no keyword field. Instead Play indexes the long description (4000c). Best practice: use target keywords 2-3 times in long description, in natural prose. Don’t keyword stuff — but not because of a density figure: Google Play publishes no keyword-density threshold, and the 3–4% number is imported from web-SEO folklore where it was never true either. The real risks are concrete: Play’s policies prohibit repetitive or irrelevant keywords in metadata and that is enforced by review, and a long description written for an algorithm reads badly to the person deciding whether to install.
Monthly: - Check rank for each target keyword - Identify keywords where you're 50+ position (probably won't rank) - Replace with higher-potential keywords - Track 12-month rank trends Long-tail keywords often outperform popular ones: "small business CRM" (rank 5, decent traffic) beats "CRM" (rank 80, no traffic)
Most people arrive at app store optimisation carrying habits from web SEO, and one of them inverts completely. It is worth being explicit, because getting it backwards is expensive in both directions.
On the web - Keyword density is not a ranking factor - Stuffing is mostly just ineffective - The cost is a worse page, not a sanction On the App Store and Google Play - Both have explicit metadata policies - Repetitive, irrelevant or misleading keywords are reviewable - The cost is a rejected submission or a pulled listing - The feedback is immediate and it is a human decision
So the density figures you will see quoted for Play — 3%, 4%, some other confident number — are folklore twice over: imported from a web context where they were never true, and applied to a platform that has never published one.
What Play does have is a policy, and policies are enforced by review rather than by decay. That is a sharper constraint than any density target, and a simpler one to satisfy: write the long description for the person reading it, mention what the app does in the words they would use, and do not repeat a phrase because you are trying to reach a number.
Teams spend days agonising over the 100 characters, and it is the wrong shape of effort. The field is a hypothesis, not a configuration — and it is cheap to change.
You cannot know in advance which words will rank. Search volume estimates for app stores are inferred from third-party panels rather than published by Apple, competition shifts between releases, and the combinatorial matching that pairs your field words with your title words produces results nobody can predict on paper.
What you can do is measure. Ship a set, track rank for each term, and read the outcome honestly:
After one release cycle: - Ranking top 10 → keep, it is working - Ranking 10-50 → keep and watch; may improve with installs - Ranking 50+ → almost certainly unwinnable; the characters are wasted - Not ranking at all → the word is not being matched; drop it
Then reallocate. The characters freed from an unwinnable head term buy you three specific long-tail ones, and long-tail terms in app stores convert unusually well — somebody searching for a narrow, exact phrase has already decided what they want and is looking for the thing that says it.
The field decides which searches you appear in. It does not decide whether anybody installs, and that distinction is where most ASO effort is misallocated.
An app that surfaces for a query and converts at 2% is outperformed comprehensively by one that surfaces for the same query and converts at 8%, and the difference is almost never the keywords. It is the screenshots, the first two lines of the description, the rating, and whether the title makes it obvious in a second what the thing is.
This matters more than it sounds because store ranking is partly driven by conversion: an app that people tap and install after searching a term tends to rise for that term. So the visible assets do not merely capture the traffic the keyword field earns — they compound it.
Section 3 mentions it in passing and it deserves more weight, because it is the only item here with multiplicative rather than incremental returns.
Every App Store locale carries its own independent 100-character field. That is not a translation exercise — it is a fresh keyword surface per locale, and the words that win in one are frequently not the translations of the words that win in another. People search for what they call the thing, and what they call the thing is a local fact rather than a linguistic one.
What teams do: - Translate the English keyword list - Ship it to every locale - Wonder why the German field underperforms What works: - Research keywords natively, per locale - Ask what people in that market actually type - Fill all 100 characters, per locale, with local terms - Accept that some locales want words with no English equivalent
The under-used trick within this: several English-speaking locales are separate fields. A listing can carry a UK English keyword set and a US English one, and the vocabulary genuinely differs — the words people reach for are not the same on both sides of the Atlantic. Two fields, two sets, and the second one costs an afternoon.
The single most common waste in the 100-character field is duplication with the title and subtitle, and it is worth restating because it is invisible unless you check.
Apple indexes words across all three fields and combines them freely to match multi-word queries. So a word already present in your title is already indexed, and repeating it in the keyword field buys you nothing at all — it simply removes those characters from a field that could have been introducing a term you do not yet cover.
The audit takes two minutes:
1. Write out every distinct word in your title 2. Write out every distinct word in your subtitle 3. Write out every word in your keyword field 4. Delete from (3) anything appearing in (1) or (2) 5. Delete plurals of words you already have — Apple stems them 6. Delete stop words and your brand name — both are free 7. Refill the recovered characters with terms you do not cover
On a listing that has never had this done, it routinely recovers twenty to thirty characters — a quarter of the field, given away to words that were already working.
Commas only. Spaces are wasted characters Apple doesn't need. 'crm,lead,deal' uses 11c; 'crm, lead, deal' uses 13c.
Not in the keyword field specifically (it's hidden, intended for keywords). Apple reviews titles and subtitles for stuffing. Don't worry about density in the keyword field; do worry in the visible fields.
No. Apple rejects keywords that are trademarked terms of other companies. Use category words instead.
Play uses the long description as keyword indexing surface. Include target keywords naturally 2-3 times in the long description prose. Don't keyword stuff — Play penalises density above 3-4%.
No. Google Play publishes no density threshold, and the 3–4% figure that circulates is imported from web SEO, where it was never a real ranking factor either. What Play does have is a policy against repetitive, irrelevant or misleading keywords in store listings, and that is enforced by human and automated review — an actual rejection, not a gradual ranking decay. So the constraint is real and it is a review constraint, not a maths one. Write the long description for the person deciding whether to install, and the policy takes care of itself.
Yes, and this is one of the few places where the old web advice inverts. On the web, keyword stuffing is mostly just ineffective. On the App Store and Google Play it is a reviewable offence: both operators have explicit metadata policies against repetitive or irrelevant keywords, and the outcome is a rejected submission or a pulled listing rather than a quiet ranking loss. The stakes are higher and the feedback is immediate — which, on balance, is easier to work with.
By tracking rank for each target term and treating the field as a hypothesis to be tested rather than a configuration to be perfected. If you sit past position 50 for a keyword after a full release cycle, that word is almost certainly not winnable and it is occupying characters that could be doing something. The field is cheap to change and changes ship with a release, so it rewards iteration far more than agonising — and the words that pay are usually the specific long-tail ones, not the obvious head terms every competitor also targeted.
Check title + subtitle + keyword field for overlap and gaps.
Run App Audit →aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.