Localized keywords: why translated ASO keywords don't rank

Translating your app store keywords gives you words nobody searches. How to find the localized keywords people in each market actually use, and where they go on Google Play and the App Store.

By GetLocalised4 min read

Ask a translator for the French for "voice journal" and you'll get a correct answer. Whether it's the phrase French users type into an app store is a different question, and only that second answer gets you installs.

Keyword localization means finding, for each market, the words people there use for what your app does. It's research, not translation.

Why translated keywords miss

Search queries aren't dictionary entries. People search the way they talk: with local slang, borrowed English words, abbreviations, and phrasing that changes from one country to the next even within a language. A word-for-word translation of your keyword list usually produces three kinds of miss:

  • Terms nobody uses. Grammatical, but not how anyone describes the need.
  • The wrong register. Too formal for a casual category, or too casual for finance and health.
  • The wrong region. Spanish in Mexico and in Spain, or Portuguese in Brazil and Portugal, use different everyday words. Both stores keep separate listing languages for them for that reason.

The same goes for the copy around the keywords. Here's a line from SpeakDiary's screenshots, translated literally and then written for French readers:

English caption

Find the words when they feel far.

Trouvez les mots quand ils se sentent loin.

Grammatical, but it says the words themselves feel distant.

A real caption from SpeakDiary's French deck. The literal version is correct French that says the wrong thing.

Where localized keywords come from

The strongest evidence is what real people did, so rank your sources by how direct they are:

  1. Your console's search data. Play Console reports the search terms that brought visitors to your listing in each country, which is measured demand on the store itself. On the App Store, Apple Ads shows a popularity indicator for the search terms you consider.
  2. Web search data. Search volume from Google's own tools shows what people look for on the web. Useful as a signal, but it isn't app store search volume, so label it as such.
  3. Native speakers. Ask people in the market how they'd describe your app to a friend, then check those phrases against the evidence above.
  4. Competitors' listings. Read the names, subtitles and short descriptions of the apps ranking in that market. They show which phrases the category has settled on.
  5. AI suggestions. Useful for generating ideas, but an idea isn't demand. Treat AI-suggested terms as things to test, never as measured data.

Be honest about what nobody knows. Neither store publishes official keyword competition data. Any tool that gives you an exact difficulty score for a store keyword is estimating it.

Score each term before you use it

For every candidate term in a market, ask four questions:

  • Evidence: where does this come from, and do independent sources agree?
  • Relevance: would someone searching this want your app?
  • Placement: does it fit a short field (30 characters for a name or subtitle, 80 for Play's short description)? Does it read as something people search in a store ("voice journal") or something they'd search on the web ("how to start journaling")?
  • Risk: is it a competitor's trademark, a superlative, or a health or finance claim you can't make?

Terms that pass all four go in your shortest, strongest fields. Good terms with less evidence go further down. Informational phrases are worth a page on your website instead, not your listing.

Put them where each store looks

The two stores read different fields:

  • Google Play has no keyword field. The order of weight is the app name, then the short description, then the full description. Use your strongest local term in the name next to your brand, the second in the short description, and work the rest into the description where they read naturally.
  • The App Store gives you the name, the subtitle and a hidden keyword field of 100 bytes. Apple says your app is already searchable by its name and company name, so don't repeat those in the keyword field, and other apps' names aren't allowed.

That 100-byte limit is where localization bites. It counts bytes, not characters: most Latin letters take one byte, accented letters two, and Chinese, Japanese and Korean characters three. Your Japanese keyword field holds about a third as many characters as your English one, so choose its terms even more carefully.

Write the copy around the keywords natively too. Google Play's metadata policy and Apple's guidelines both rule out stuffing, and a listing stuffed with keywords converts worse even when it ranks.

Re-check them every few months

Search behaviour shifts: new competitors, new terms, seasonal phrasing. Re-run the research for your important markets now and then, and compare your console's search data with what you're targeting. Drop terms that bring no visitors and promote the ones that do.

For the full workflow around the keywords, from choosing markets to publishing, see how to localize your app store listing for every market.

GetLocalised builds this research per market: it gathers evidence, labels what's measured and what's an AI idea, scores every term, and writes the winners into each field within its limit. It works with Google Play today, and App Store support is on the way.

Questions

Can I just translate my English keywords?
You can use them as a starting point, but check each one against evidence from that market. Translated keywords are often correct words that people there don't search.
Which stores have a keyword field?
The App Store has a hidden keyword field of 100 bytes for each localization. Google Play has none: it reads your app name, short description and full description, so the keywords have to live in that copy.
Why does my Japanese keyword field fill up so fast?
Apple limits the keyword field to 100 bytes, not 100 characters. Japanese, Chinese and Korean characters take three bytes each, so the field holds about 33 of them.

[ Keep reading ]