App Store Keyword Field Strategy: How to Use All 100 Characters Without Wasting Them
A practical App Store keyword research and metadata workflow: map search intent, allocate the 100-character keyword field, localize deliberately, and measure changes without guessing at Apple's algorithm.
The App Store keyword field looks like a small form input. It is actually a compact search-intent model for your product.
You get 100 characters in Apple's public guidance—and the App Store Connect reference describes the storage limit as 100 bytes. There is no room for a brainstorm dump, a competitor list, or six ways to say the same thing. Every term should earn its place by connecting a real customer problem to a capability your app actually delivers.
This is a production workflow for doing that work deliberately. It covers the app name, subtitle, hidden keyword field, localization, and the newer ability to route approved keywords to Custom Product Pages. It does not pretend to reverse-engineer Apple's ranking algorithm. Apple does not publish term weights, exact reindexing times, or search-volume figures.
The three metadata jobs are different
Before choosing keywords, separate the jobs of the three primary fields.
| Field | Limit | Visible to customers | Primary job | | --- | ---: | --- | --- | | App name | 30 characters | Yes | Identify the product and communicate its clearest category or purpose | | Subtitle | 30 characters | Yes | Add a concise value proposition or secondary use case | | Keyword field | 100 characters / up to 100 bytes | No | Supply relevant discovery vocabulary not already covered visibly |
Apple's App Store search guidance says not to repeat words already present in the app name, subtitle, or category. It also advises against duplicate plurals, overly broad terms such as “app,” filler words, special characters without brand meaning, irrelevant terms, competitor names, and unauthorized trademarks.
That gives us the first rule:
Visible metadata should persuade a human. Hidden metadata should expand relevant query coverage. Neither should repeat the other.
The description has a different role. Apple's App Store Connect reference says it can be used for web-engine search results after release, while Apple explicitly says promotional text does not affect App Store search ranking. Write both for clarity and conversion; do not treat either as a place to stuff the hidden keyword list.
Start with search intent, not an ASO tool score
An estimated volume score is not a customer problem. Begin by mapping the moments in which someone would search for the app.
For a private receipt organizer, the first draft might look like this:
| Intent | What the person wants | Candidate vocabulary | | --- | --- | --- | | Task | Save a purchase record | receipt, purchase, record, scan | | Outcome | Find proof later | warranty, return, claim, history | | Object | Track a household item | appliance, device, equipment | | Constraint | Avoid an account or cloud upload | private, offline, local | | Audience | Manage a home or small workshop | household, homeowner, workshop |
This matrix prevents a common ASO failure: filling the field with category synonyms while ignoring the actions and outcomes behind the search.
Build the candidate list from evidence
Use several inputs, because each reveals a different part of the language:
- Support messages and review text. Record the words customers use before your team rewrites them into product terminology.
- App Store search suggestions. Treat autocomplete as query-language evidence, not as a published volume ranking.
- Competitor positioning. Study the problems their visible metadata addresses. Do not copy their names or protected terms.
- Your product's navigation and feature labels. A term is useful only if the app satisfies the expectation it creates.
- Apple Ads search-term data, if you run campaigns. Separate broad campaign discovery from terms that generated meaningful taps or downloads.
- Web Search Console data for your product pages. Web queries often expose long-tail problem language that can improve App Store copy, even though Google and App Store search are different systems.
Keep source and date next to every candidate. A spreadsheet with term, intent, source, locale, relevance, and current field is more useful than an untraceable list of “high-volume” keywords.
Score candidates without inventing precision
Do not reduce the decision to a mysterious third-party difficulty number. Use a simple, auditable scorecard.
Rate each candidate from 0 to 3 on:
- Product relevance: Does the current app clearly deliver what this term promises?
- Intent clarity: Does the term express a task, outcome, object, constraint, or audience?
- Evidence: Did it appear in customer language, search suggestions, campaign data, or organic queries?
- Distinct coverage: Does it add vocabulary not already present in the name, subtitle, category, or selected terms?
- Conversion fit: Would the first screenshots immediately confirm the searcher's expectation?
Then apply hard exclusions:
- competitor app or company names;
- unauthorized trademarks or celebrity names;
- irrelevant seasonal or trending terms;
- claims the product cannot substantiate;
- duplicates, redundant plurals, and generic filler.
The result is not an algorithm forecast. It is a defensible editorial decision.
Allocate the 100-character field
Work from a budget, not from a finished comma-separated string.
Step 1: reserve the visible fields
Draft the app name and subtitle first. Those fields must still read naturally in search results and on the product page. Do not turn the brand into a list of nouns.
Example:
- Name:
Keepsake — Receipt Vault - Subtitle:
Track warranties privately
The hidden field should not repeat keepsake, receipt, vault, track, warranties, or privately.
Step 2: create intent clusters
Group the remaining terms by customer intent:
- purchase evidence:
purchase,invoice,proof - household inventory:
appliance,equipment,household - lifecycle events:
repair,service,return,claim - privacy constraint:
offline,local
This makes trade-offs visible. If 70% of the field describes the same receipt-scanning action, the field is not covering the product's broader value.
Step 3: assemble a candidate field
Apple says to separate terms with commas and no spaces after the commas. Spaces can be used within a phrase when needed; Apple's example is Real Estate.
One candidate field might be:
purchase,invoice,proof,appliance,equipment,repair,service,return,claim,offline,household
Count the exact submitted string, including commas and any spaces inside phrases. For non-ASCII localizations, App Store Connect is the final authority because its reference specifies a byte limit.
Step 4: run four checks
Before saving:
- Duplicate check: no word already appears in the name, subtitle, or category.
- Policy check: no competitor names, unauthorized trademarks, or irrelevant terms.
- Promise check: the product and screenshots clearly support every material term.
- Coverage check: the field spans more than one meaningful intent cluster.
When to use a phrase instead of separate words
Apple recommends commas rather than spaces to maximize the field, while allowing spaces inside a phrase. That does not mean every two-word query should be entered as a phrase.
Use a phrase when the combined expression carries a distinct meaning that its parts do not express cleanly on their own. Real Estate is the canonical Apple example. For combinations such as receipt scanner, first ask whether receipt and scanner are useful independently and whether other selected terms could form relevant combinations.
Because Apple does not document every combination rule or ranking weight, avoid presenting permutations as guaranteed indexed queries. Record the hypothesis, publish compliant metadata, and measure the outcome.
Localization is a new intent map, not a translation task
Apple recommends localizing keywords so people can find the app in their preferred language. The mistake is translating the English list word for word.
A good localization pass asks:
- What does the audience call this task locally?
- Does the English product category exist as a natural search phrase?
- Are compound words, inflections, or abbreviations different?
- Does the local screenshot caption confirm the same promise?
- Does the localized product actually support the expectation?
Give each locale its own research sheet and owner. Machine translation can generate candidates; a fluent reviewer should decide what ships.
Also distinguish language from market. The same language can have different purchase vocabulary, regulatory expectations, and familiar product labels across regions.
Use Custom Product Page keywords for intent-specific experiences
Apple now allows approved keywords to be assigned to a Custom Product Page. A Custom Product Page can use different screenshots, app previews, and promotional text, has a unique URL, and can optionally deep-link into the app on supported OS versions.
This changes the ASO architecture. One default page no longer has to explain every use case equally.
For example, a document app might create separate pages for:
- scanning and organizing receipts;
- keeping home-maintenance records;
- storing warranty documents;
- managing workshop equipment.
Each page should receive a unique, relevant keyword combination. Apple specifically advises developers to match keywords to the page's intent and avoid assigning the same combination to multiple pages.
Do not create dozens of near-identical pages. Create a page when the query deserves a meaningfully different visual story or in-app destination.
Measure metadata changes as releases, not vibes
A keyword change is a product experiment even when App Store Connect does not provide a randomized keyword test.
Maintain a change log with:
- version and release date;
- locale;
- old and new app name, subtitle, and keyword field;
- terms added and removed;
- intent hypothesis;
- screenshot or Custom Product Page changes made at the same time;
- external campaign changes;
- relevant seasonality or featuring events.
Then watch the closest available signals in App Analytics and your rank-tracking workflow:
- App Store impressions;
- product page views;
- first-time downloads;
- conversion rate;
- source type;
- territory;
- Custom Product Page performance;
- search-term or rank observations from the same tool and methodology.
Do not change metadata, screenshots, price, and paid acquisition simultaneously if your goal is to understand the keyword decision. You will not know which change moved the outcome.
A practical review cadence
Use a consistent window rather than reacting to daily noise:
- Capture a baseline before the release.
- Log the exact metadata submitted and the date it became available.
- Check for implementation errors after release.
- Review a complete comparable period when enough traffic has accumulated.
- Keep, revise, or revert based on the intended query cluster and downstream conversion—not impressions alone.
There is no universal “wait exactly seven days” rule. Low-volume apps need longer observation windows than high-volume apps, and seasonal demand can invalidate a simple before-and-after comparison.
The 100-character worksheet
Use this before every metadata release:
| Check | Question | | --- | --- | | Customer intent | Which task, outcome, object, constraint, or audience does each term represent? | | Product truth | Can the current app satisfy the promise without explanation? | | Visible duplication | Is the word already in the name, subtitle, or category? | | Redundancy | Is it a duplicate plural, filler word, or generic category term? | | Policy | Is it relevant, permitted, and free of unauthorized protected names? | | Conversion continuity | Do the first screenshots confirm the same intent? | | Locale quality | Was the term researched and reviewed in that language and market? | | Measurement | Is the hypothesis recorded with a clean baseline and change date? |
If a term cannot pass the worksheet, it does not deserve a character.
How this fits into a complete ASO system
Keyword metadata earns a chance to appear. It does not complete the conversion.
The next layer is the product-page experience: icon, screenshots, previews, promise, and audience continuity. Use the companion guide on Product Page Optimization versus Custom Product Pages to decide whether you need a randomized asset test or a persistent page for a particular intent.
For the broader system, read the complete iOS App Store Optimization guide. Before a release, use the App Store submission checklist so a metadata improvement is not delayed by an avoidable review or configuration problem.
Frequently Asked Questions
How long is the App Store keyword field?
Apple's public search guidance describes a 100-character limit, while the App Store Connect field reference specifies up to 100 bytes. For plain ASCII those are effectively the same; validate non-Latin metadata in App Store Connect.
Should I repeat a keyword from the app name or subtitle?
No. Apple explicitly advises against repeating words already used in the app name, subtitle, or category. Use the hidden field to add relevant vocabulary.
Should App Store keywords include spaces?
Separate entries with commas and no spaces after the commas. Spaces are appropriate inside a phrase only when the words need to function as a phrase.
Can I use competitor names in App Store keywords?
No. Apple prohibits competing app names and unauthorized trademarked terms. Target the problem, task, audience, and supported feature instead.
Do Custom Product Pages have their own keywords?
You can assign approved keywords to a Custom Product Page. Match them to that page's intent and keep combinations unique so the most relevant page can appear.
Need a product and release review that connects App Store positioning to what the app actually ships? Start with the 3NSOFTS Apple-platform diagnostic.