Which store listing fields are actually searchable

Six fields carry search weight. Everything else on your product page is sales copy.

Field	App Store	Google Play
App name / title	Indexed	Indexed
Subtitle	Indexed	n/a
Keyword field (100 chars, hidden)	Indexed	n/a
Short description	n/a	Indexed
Full description	Not indexed	Indexed
Promotional text	Not indexed	n/a
Release notes / What's New	Not indexed	Not indexed

Read the two columns against each other and the whole cross-store strategy falls out of it. Apple gives you 160 searchable characters (30 + 30 + 100) and ignores your 4,000-character description. Play gives you 4,110 searchable characters and no hidden field.

That is not a small difference in emphasis. It is two different games played with the same app.

Neither store publishes its search index, and neither ever will. The lists above are the working consensus from years of practitioner testing plus what each store's own documentation implies. Anyone telling you they know Apple's ranking weights is selling something.

The App Store side: one bag of words

Apple treats your app name, subtitle and keyword field as a single pool. Three consequences, all of them useful:

Order does not matter. "Habit Tracker" in the name and "daily,streak" in the keyword field can combine to match a search for "daily habit tracker". The words do not need to sit next to each other, or in that sequence, or in the same field.

Duplication earns nothing. A word already in your app name gains you nothing by also appearing in your keyword field. That is 100 characters you can spend on something else, and it is the single biggest waste in most keyword fields.

Plurals are largely handled. Apple matches "tracker" and "trackers" without you spending characters on both. Not perfectly and not in every language, but reliably enough that paying eight characters for a plural is a bad trade.

So the useful mental model is a 160-character budget, spent once, across three boxes. Not three separate fields to fill.

The description is genuinely outside this. Writing keywords into an App Store description does nothing for search. It is not penalised, it is just inert, and it costs you the readable opening paragraph that does the actual convincing.

The Play side: everything you can see

Play has no hidden field, so every keyword has to live in text a person reads. Your title, your 80-character short description, and your full description are all indexed.

The short description does disproportionate work here. It is 80 characters, it is indexed, and it is the only body copy shown before someone taps "read more". A short description that says "The simple, beautiful way to build better days" is spending all eighty of its searchable characters on nothing.

The full description being indexed is why Play listings drift towards repetitive keyword-stuffed prose, and why Play's Metadata policy explicitly prohibits that. The line to hold is that a term should appear where it reads naturally. Two or three natural mentions across 4,000 characters is a real signal; twenty is a policy risk.

Where a given keyword belongs

A decision procedure that works on both stores:

1. Is it the single term you most want to win? It goes in the name or title, if it fits alongside the brand in 30 characters. The name outranks everything else you control.
2. Is it your second or third term? App Store: the subtitle, phrased as a readable line rather than a keyword list. Play: the short description, as one sentence.
3. Is it a long-tail or awkward term? App Store: the keyword field, where nobody will ever read it. Play: worked into the full description, because there is nowhere to hide it.
4. Is it already in a field above? Then stop. On Apple it needs no repetition at all. On Play, one more natural mention is the ceiling.
5. Is it a category name, a competitor, or your own brand repeated? Leave it out. See the keyword field guide for why each one is a waste.

The unglamorous check that follows from this: take a keyword you care about, split it into words, and ask whether every word appears somewhere in your indexed fields. If one word is missing, you are not competing for that phrase at all.

The failures are usually near-misses rather than gaps. "Time blocking app" reads as uncovered when your subtitle says "Time blocking and focus planner", purely because the word "app" appears nowhere. That is a three-character fix, not a listing rewrite, and knowing which word is missing is the difference between the two.

The fields that are not indexed, and what they are for instead

App Store description, 4,000 characters. Conversion, not discovery. Apple shows roughly the first three lines before a "more" link, so the opening sentence carries nearly all the weight and the rest persuades people who already tapped.

Promotional text, 170 characters. Not indexed, and the only App Store field you can change without shipping a version. That makes it the right home for anything time-bound: a sale, an event, a fix that just landed.

Release notes on both stores. Not indexed. Written for existing users, who are the people most likely to read them and the only people who will notice you naming the bug they reported.

Screenshots and captions. Not indexed as text, as far as anyone can establish. They matter enormously for conversion and not at all for matching a query.

Developer name, category and bundle ID. These influence discovery in ways neither store details. Category placement clearly affects charts and browse. Whether the developer name is indexed for keyword search is not something anyone can demonstrate cleanly.

What to do with this

Two concrete moves.

Audit what you have. List your target keywords. For each, check every word against the three indexed fields for that store. Fix the near-misses first, they are cheap.

Look at who is beating you. Take the app name of whoever holds the top slot for your term and pull out the words it uses that appear nowhere in your indexed fields. That is a list of gaps you can close in a text box, it needs no tooling, and their app name is sitting in every search result you have already looked at.

AppSubmit does that word-by-word coverage check across the indexed fields and names the field each word was found in, which is the only part that is tedious by hand. The rules above are the whole method.