US | ASO | 2026-08-16

App Store Optimization for Small Business Apps

A field-by-field breakdown of what each store indexes, what it ignores, and which levers a business with no ASO budget can actually pull.

For a dental practice or a three-location gym, most app installs come from people who already know the business: a link on the website, a QR code at the front desk, a line in a booking confirmation email. That makes the store listing a conversion page first and a search channel second. The complication is that the fields which persuade a warm visitor and the fields the stores index for search are mostly different fields, and confusing the two wastes a very small budget of characters.

What each store actually indexes

Apple and Google disagree about which text feeds search. On iOS, searchable metadata is the app name, the subtitle, the 100-character keyword field, your developer name, and in-app purchase names. The description is not indexed at all. Neither is promotional text. On Google Play, the title, the short description, and the full description all feed search.

One operational difference matters more than any keyword theory. Play Store listing text can be edited and published on its own, with no new build. Apple binds the name, subtitle, and keyword field to a version submission, so every iOS keyword change costs a review cycle. Review is usually under 48 hours, but it is not zero, so iOS keyword changes should ride along with releases you were already shipping.

Writing the iOS keyword field without wasting characters

One hundred characters goes fast, and the common mistakes each cost real terms:

• Separate keywords with commas and no spaces. A space after each comma in a ten-term list burns ten characters, which is one more keyword you did not get.
• Never repeat a word already in the app name or subtitle. Apple combines terms across all indexed fields, so an app named "Barkley: Mobile Dog Grooming" gains nothing from putting "grooming" in the keyword field.
• Skip your category name and your country. Both are indexed automatically.
• Skip "app", "free", and "best". They add no reach, and superiority words invite trouble in review.
• Pick singular or plural, not both. Apple handles most stemming.
• Store single words, not phrases. Apple assembles phrases by combining atoms across fields, so "mobile,groomer,pet,wash,van,appointment,nails" ranks for pairings you never explicitly wrote.

To find terms without paying for a tool, open the Apple Search Ads campaign builder and look at keyword suggestions. Each term shows a popularity score from 5 to 100, and you can read that screen without launching a campaign or spending anything. Terms below roughly 20 get almost no traffic. Terms above 60 in a broad category are contested by apps with dedicated budgets. For a local or niche business, the useful band sits in the middle, and long tail terms with a city or a specific job attached convert far better than the category head term.

Play's 80-character field does the heavy lifting

The short description is both a strong ranking input and the line a visitor reads above the fold. Write it as a sentence a person would actually read, with the primary term used once. "Book mobile dog grooming, track your van, and pay from your phone" is 65 characters and indexes cleanly.

The 4,000-character full description is indexed, which tempts people into stuffing. Google's policy on repetitive or irrelevant keywords is enforced, and a suppressed listing costs more than the ranking was worth. Mentioning your primary term three to five times across the whole description is plenty. Structure matters more than density anyway: Play truncates after roughly three lines before the "read more" cut, so the first 180 characters need to state what the app does for the customer, not who your company is.

Screenshots and the honest limits of testing at low volume

iOS search results display the first three portrait screenshots inline, so for anyone who never taps into the product page, those three images are the entire pitch. Put a short benefit line across the top of each, sized to be legible at thumbnail scale, and show the actual booking, tracking, or payment screen rather than a marketing collage.

Both stores give you free testing tools: Play Console store listing experiments, and Apple's Product Page Optimization, which runs up to three treatments against the original. Both need traffic to be worth anything. Moving conversion from 30% to 33% requires thousands of impressions per arm before the result separates from noise, and an app with 300 monthly product page views will not get there inside a quarter. If that is your volume, stop calling it an experiment. Make a judgment call, ship it, and spend the attention elsewhere.

Custom Product Pages on iOS are more useful at small scale. You get up to 35, each with its own URL and its own screenshot set, and each reports conversion separately. Give your email list one page and your Instagram bio another, and you learn which audience converts without needing statistical significance on a split test.

Ratings, review velocity, and when to ask

Rating feeds ranking on both stores, but the display effect is larger than the ranking effect. The gap between a 4.6 and a 3.9 in a search result changes whether people tap at all. Recent review volume matters too, which is why an app with 40 reviews from last month often outperforms one with 400 from three years ago.

Ask inside the app, and ask at the right moment. Apple's SKStoreReviewController caps at three prompts per user per 365 days and Apple decides whether the sheet actually appears. Android's In-App Review API has its own undisclosed quota and can silently do nothing. Neither belongs on app launch. Trigger after a completed job: a second successful booking, a finished payment, a delivered order. Do not gate the prompt behind a "are you enjoying the app?" question that routes unhappy users to a private form. Both stores prohibit that pattern.

Apple lets you reset the summary rating when releasing a new version. It cannot be undone, so use it once, after a version that genuinely fixed what people complained about. And reply to reviews. On Play a reply notifies the reviewer, and users update ratings after a fix ships more often than you would expect.

Localization, cadence, and owning the accounts

Localization is the cheapest keyword expansion available on iOS, because each localization gets its own name, subtitle, and 100-character keyword field. The US storefront indexes both English (U.S.) and Spanish (Mexico) metadata, so adding a Spanish (Mexico) localization effectively hands a US-only app a second keyword field. The Canadian storefront treats English (Canada) and French (Canada) the same way. The catch is real: only do this if the app and your support can handle the language, because a translated listing on an untranslated app produces one-star reviews faster than it produces installs.

For cadence, change one variable per release so you can attribute the result. App Store Connect reports impressions, product page views, and conversion rate; Play Console additionally reports the actual search terms people used, which Apple only exposes through Search Ads. Give any change three to four weeks before judging it.

One last thing that is not really ASO but determines whether you can do any of it: the Apple Developer and Play Console accounts should be registered to your business, not to your development agency, and you should hold the source code. Metadata you cannot edit is metadata you cannot optimize, and a developer account someone else owns is an app you cannot move.