Why Isn’t My App Ranking? An ASO Diagnostic

Before you touch a single keyword, confirm the app is published, out of review, and distributed to the country whose store you are searching — a large share of "we do not rank" reports are availability problems wearing an ASO costume. This branch costs ten minutes to rule out and it is the only one where the fix is a checkbox.

Three things break here, and none of them look like a search problem from the outside.

If the app appears when you search its exact package name or full title from a clean account in the target country, availability is fine and you can move down the tree. If it does not, stop here — nothing further in this article applies until it does.

Search your exact app name first: if you do not appear for that, you have an indexing or naming problem, not a ranking problem, and no amount of keyword work will help. This is the diagnostic that separates the two failure modes that get lumped together as "not ranking".

Apple is explicit that the app name is one of the text-relevance inputs to search. Its App Store search guidance states that search results are based on a number of factors, including text relevance — matches for your app's title, subtitle, keywords and primary category — as well as user behaviour such as downloads, ratings and reviews. If your own title does not retrieve you, the text-relevance side is not doing what it should.

Three causes account for nearly all of it:

• The name is a generic phrase. If your app is called "Budget Planner", you are not searching a brand — you are searching a category with hundreds of competitors, and you are ranked among them like anyone else. Nothing is broken; the name simply carries no distinguishing signal.
• The name you are searching is not the name you shipped. Teams routinely search the marketing name while the store carries the legal one, or the other way round. Open the live listing and copy the string from it.
• The change has not propagated. On iOS the name is not a free-text field you edit at will. Apple's App Store Connect reference sets the name at a minimum of 2 and a maximum of 30 characters, and states it can be edited until you submit the app to App Review — after that you change it when you create a new version, or when the version's status permits editing. A name change you made in a draft that was never submitted is not live.

If you do rank for your own name and nothing else, the tree branches cleanly: indexing works, and you have a metadata or competition problem. That is the far more common case, and it is the rest of this article. Our breakdown of how the two store algorithms differ covers why the same app can pass this test on one store and fail it on the other.

Most apps that "cannot rank" have simply never told the store what they are for — the fields that carry text relevance are short, few, and usually filled with brand poetry instead of the words people type. Open your listing and audit the fields as fields, not as copy.

The character budget you are working with is small enough to write out in full, and every number below is quoted from platform documentation rather than estimated:

Apple's keyword field has rules that quietly waste half of it if you do not know them. Apple advises not repeating any words already included in your app name, subtitle or category, and — to maximise the number of words that fit — avoiding plurals of words you have already included, since "climbs" and "climb" are considered duplicates; generic terms that are too broad for your app or category, such as "app" or "game"; filler words like "the" and "to", as these do not add any additional value; and special characters such as # or @ unless they are part of your brand identity.

The practical test is blunt. Write down the ten phrases a stranger would type to find an app like yours, then check how many appear anywhere in your name, subtitle, keyword field or Play title and short description. If the answer is one or two, you have found your problem and it is not the algorithm. Our guide to ranking inside a store category works through how to choose those ten phrases.

Both stores publish rules that make certain metadata a liability rather than an asset, and the penalties run from rejection to reduced distribution — several of the "growth hacks" still circulating are explicitly prohibited. Check this branch before you write new metadata, not after.

Google's metadata policy is direct: it does not allow apps with misleading, improperly formatted, non-descriptive, irrelevant, excessive or inappropriate metadata. It also rules out emojis, emoticons and repeated special characters in elements such as the app title, icon and developer name, and prohibits text or images in those elements that indicate store performance ("App of the year"), price or promotion ("10% off"), or programme status such as "Editor's choice".

Apple's position on the keyword field is equally plain. It notes that improper use of keywords is a common reason for App Store rejections, and says not to include unauthorised use of trademarked terms, celebrity names or other protected words and phrases; terms that are not relevant to the app; competing app names; or inappropriate, offensive or objectionable terms.

Two softer failures belong here too. Keyword repetition across your title, subtitle and keyword field spends the budget twice on the same term — Apple explicitly tells you not to repeat words already in the name, subtitle or category. And a title padded with category words to the 30-character limit reads as spam to a human even where it passes policy, which trades ranking for conversion. The listing has to survive both the algorithm and the person who taps it.

If your app is indexed, correctly named and honestly described, and still invisible, the most likely explanation is that you chose head terms owned by apps with vastly more of the behavioural signals both stores use. This is not a fixable defect. It is a targeting decision, and the fix is to change the target.

Apple names the two halves of the ranking input without weighting them: text relevance on one side, and user behaviour — downloads, ratings and reviews, and more — on the other. That second half is the part you cannot write your way past. A new app with a few hundred installs and a handful of ratings is not going to outrank an incumbent on a term like "photo editor", however well the keyword field is packed.

The workable move is to compete where the behavioural gap matters less:

• Longer, more specific phrases. Fewer searchers, far fewer credible competitors, and an intent match that converts better when they arrive.
• Your actual differentiator, in words users would type. If you are the expense tracker that handles UPI autopay, that phrase has an audience the head term does not reach.
• Language and market. A term with brutal competition in English may be barely contested in a regional language, which is one of the strongest levers available in India specifically. Our piece on store localisation strategy covers how far that goes.
• Category choice. Apple lists primary category among the text-relevance factors, so the category is a ranking input and not merely a shelf label.

Set the expectation honestly with whoever asked the question. Head terms are won with sustained install volume and rating quality, not with metadata edits, and a plan that pretends otherwise fails on a schedule.

On Google Play this branch is documented in unusually blunt terms: exceeding a bad-behaviour threshold makes your app less discoverable, and Play may steer users on affected device models away from your title entirely. If your crash or ANR rate is over the line, no metadata work will restore the visibility you have lost.

Google's Android vitals documentation publishes the overall bad-behaviour thresholds directly. A user-perceived ANR rate counts as overall bad behaviour when at least 0.47% of daily active users experience a user-perceived ANR across all device models; the user-perceived crash rate threshold is at least 1.09% of daily users experiencing a user-perceived crash across all device models. The consequence is stated plainly: if your app exceeds these thresholds, it is likely to be less discoverable on Google Play. Where the problem is device-specific, Google Play will steer users on those devices away from these titles and towards others that are more suitable for them, and in some cases a warning could be shown on your app's store listing.

The Android vitals overview repeats the mechanism from the developer side — your app's core vitals affect your app's visibility on Google Play, and if your app or game exceeds a bad behaviour threshold, Play may reduce the visibility of your title. It also notes that Play uses the last 28 days of data to assess your app's quality, and flags that apps exceeding the thresholds for memory usage, bitmap memory usage or code optimisation may see store visibility impact starting from February 2027.

Apple does not publish an equivalent threshold table, and we are not going to invent one. What it does publish is that ratings and reviews are among the user-behaviour inputs to search — and crashes reliably produce bad ratings, so the path from instability to lost visibility exists on both platforms even where only one of them documents the numbers. We cover the commercial cost of that in why bad vitals act as a tax on acquisition, and the thresholds themselves in the vitals thresholds that decide distribution.

Both stores use behavioural signals that a week-old app has not had the chance to generate, so a new app ranking nowhere is the expected state rather than a fault. The mistake is treating a normal cold start as a defect and rewriting metadata every few days in response to noise.

Look again at what Apple names as inputs: text relevance and user behaviour, with downloads, ratings and reviews given as examples of the latter. A new app has the first half and none of the second. It is not being penalised; it has simply not produced the evidence the second half is made of.

Neither Apple nor Google publishes how long that takes, or how the two halves trade off, and any specific number you read on the subject is someone's inference presented as fact. What we can say from the documentation is the direction, and from experience the shape:

The related trap is a listing rewritten so often that no version ever accumulates enough data to be judged. If you change the title, subtitle and keywords together every fortnight, you will never learn which change did anything. A structured approach to that is worth setting up early — our ASO testing framework covers running one variable at a time properly.

A meaningful share of "we are not ranking" cases are conversion problems: the app appears, people see it, and nobody taps — which then suppresses the behavioural signals that would have improved the ranking. The two failures look identical in an install chart and need opposite fixes.

Check the store analytics before you accept the premise. If store listing visitors are healthy and installs are not, you have a conversion problem. If visitors are near zero, you have a visibility problem and the rest of this fault tree applies. Guessing between the two wastes whichever quarter you guess wrong in.

The two branches diverge completely from there:

There is a compounding effect worth naming. Apple lists downloads and ratings among the user-behaviour inputs to search. A listing that converts badly generates fewer of both, which weakens the half of the ranking equation you cannot write, which reduces impressions further. Conversion is therefore not a separate discipline from ranking — it is an input to it, and on a new app it is usually the faster lever. Our guide to store listing conversion covers the elements in order of impact.

Strictly top-down, because each branch invalidates the ones below it — diagnosing keyword competition on an app that is still in review is wasted work, and it is the most common way teams spend a month. The order below is the whole method.

One discipline holds the whole thing together: never change two branches at once. If you rewrite the metadata and ship a stability fix in the same week, you will not know which one moved the numbers, and the next diagnosis starts from scratch.

The reason to be this literal about order is that the branches have wildly different costs. Availability is a checkbox. Metadata is an afternoon. Competition realism is a strategy conversation. Technical quality is engineering time. Age is patience. Teams that skip to the expensive branches usually do so because those feel like real work, and that instinct is what turns a ten-minute answer into a quarter.

If you have worked the tree and cannot place your app on it, that is usually a short diagnosis for someone who has seen the pattern before — tell us what the store analytics show, or see how we approach a listing end to end in our ASO work.