Localization for ASO: each locale is a fresh set of indexed metadata
The single highest-leverage move in iOS App Store Optimization is also the most misunderstood: every localization you add is a brand-new set of indexed metadata: a fresh app name (30 characters), subtitle (30 characters), and keyword field (100 bytes). That multiplies the terms you can rank for across markets. The catch is twofold. First, localizing metadata for ASO is not the same as translating your app: the metadata is indexed independently of whether your UI ships in that language. Second, a handful of storefronts index more than one locale at once, so picking locales blindly leaves real keyword budget on the table. Think of localizations less as translations and more as additional indexed surfaces: each one carries the same weight order Apple applies everywhere: App Name first, then Subtitle, then the hidden Keyword field, then your categories. Fill ten localizations well and you have ten times the app-name relevance, ten times the subtitle weight, and roughly ten 100-byte keyword fields working in parallel. Most apps stop at one or two. This guide shows how to treat localization as the genuine ceiling on keyword reach, which locales actually compound, and the byte-budget and duplication traps that quietly waste fields.
Why is each localization a keyword multiplier?
Apple indexes the app name, subtitle, and keyword field separately for every localization you fill in. Add an English (U.S.) and a Spanish (Mexico) localization and you do not get one keyword field; you get two, each with its own 30-character name, 30-character subtitle, and 100-byte keyword field. That roughly doubles the terms you can rank for in the storefronts those locales serve. The work scales linearly with locales you fill, which is why localization, not cramming one field, is the real ceiling on how many keywords you can target. Concretely: a single English field gives you maybe 12-18 usable keyword tokens after you strip stop words, plurals, and terms already in your name and subtitle. Adding a second indexed locale to the same storefront effectively doubles that ceiling without touching your existing fields. Because App Name carries the highest text-relevance weight and Subtitle the second, the multiplier is not just about the hidden keyword field: every localization is also a fresh shot at the two heaviest-weighted surfaces. A term you could not fit in your en-US name might own the name slot in another indexed locale, ranking far stronger than the same word buried in a keyword list.
What is the en-US + es-MX (extra-locale) trick?
Some storefronts pull keywords from more than one localization at once. In the U.S. App Store, Apple indexes both English (U.S.) and Spanish (Mexico) metadata for the same listing, so adding an es-MX localization gives you a second 100-byte keyword field that ranks IN the U.S. store, even for users browsing in English. The practical move: do not duplicate your en-US terms in es-MX; fill it with a fresh, non-overlapping set. Treat it as 100 more bytes of U.S. keyword budget, not a translation. The same pattern appears in other markets: for example, English (U.K.) commonly rides alongside English (U.S.) style metadata in several English-speaking storefronts, and additional language localizations are indexed in storefronts with large second-language populations. Audit your priority storefronts to learn which secondary locales they index, then claim those fields. Because the es-MX field ranks in English-search results in the U.S., you can legitimately pack it with more English-adjacent or bilingual terms that did not fit your primary field, rather than pure Spanish; what matters is that the bytes are distinct and target searches real U.S. users actually run. This is the closest thing to free keyword budget the platform offers.
Localizing metadata is not translating the app
You can localize the App Store metadata (name, subtitle, keywords, screenshots) without translating the app's UI itself. For ASO, the metadata is what's indexed, so a market-by-market keyword strategy delivers ranking value even if the app ships in English. The reverse trap is just as common: machine-translating your keyword field word-for-word produces terms no native speaker searches. Localize to how people in that market actually search (research the local terms) rather than running your en-US set through a translator. Real examples make the gap obvious: German users compound nouns (a literal split of a phrase ranks for nothing), French speakers search both accented and unaccented forms, and many non-English markets search in a mix of the local language and English loanwords. A translator hands you the dictionary word; search data hands you the word people type. There is a UX caveat, though: localizing only the metadata while the app interior stays English can disappoint users in that market and hurt conversion and retention, which feed back into rankings. So treat metadata-only localization as a deliberate ASO experiment for high-value markets, and pair it with at least partial app translation where the install volume justifies the effort.
How do you research the local terms for each market?
Translation gives you words; ASO needs the words real users search, and the two diverge constantly. Build the per-locale keyword set from sanctioned signals rather than guesswork. Use Apple's own autocomplete and the App Store's localized search suggestions in each storefront, the visible category and ranking lists for that market, and Apple Search Popularity treated as a relative 0-100 index within that single storefront, never as a fabricated 'searches per month' number, since Apple does not publish volume and the popularity backend grew noisy in late 2025. Pull localized terms from the iTunes Search and Lookup endpoints and from competitor metadata in that storefront to see which native phrasings established apps already target. Watch for false friends and register: the formal dictionary term may be outranked by colloquial or transliterated forms, and English loanwords frequently beat their native equivalents (users in many markets search 'fitness' or 'workout' even when a native word exists). Validate candidate terms against local results to confirm they return relevant apps. Keep a per-locale keyword sheet so you can see, market by market, which distinct terms each field owns; that sheet is what prevents the accidental overlap covered below and makes the multiplier real instead of theoretical.
Mind the byte budget: it shrinks fast in non-Latin scripts
The keyword field is 100 bytes of UTF-8, not 100 characters, and the difference is enormous across scripts. Plain ASCII (a-z, 0-9, comma) costs 1 byte per character, so an English field holds the full 100 characters. Accented Latin characters (é, ñ, ü) cost about 2 bytes each, so French, Spanish, or Vietnamese fields hold fewer terms than they appear to. CJK characters (Chinese, Japanese, Korean) cost 3 bytes each, and some emoji and rarer glyphs run 4 bytes. A Japanese keyword field therefore holds roughly 30-33 characters, not 100: a fraction of the English ceiling. Validate every localization by UTF-8 byte length (Buffer.byteLength(s,'utf8')), not string length, or you will silently truncate or over-budget fields. Practical consequences: in CJK locales, every wasted byte hurts more, so duplicate or filler terms are far costlier; prefer short, high-popularity tokens; and remember the comma separators count too. Because CJK languages often do not use spaces, segmentation matters: Apple indexes the comma-separated tokens you provide, so choosing the right multi-character units is part of the budget decision. Build your field validator on byte length as a configurable constant, since Apple has changed field limits before and may again.
Which markets should I prioritize?
Prioritize by where your install base and revenue concentrate, then by the cheap wins. Start with the storefronts you already get downloads from, add the extra-locale fields that ride inside stores you already serve (like es-MX for the U.S.), and weigh effort against market size. Mind byte budgets per language: in UTF-8, accented Latin terms cost ~2 bytes per character and CJK 3-4, so a 100-byte field holds far fewer Japanese or Korean keywords than English; validate each localization's field by UTF-8 byte length, not character count. A workable sequence for most apps: (1) lock the primary storefront's name, subtitle, and keyword field; (2) claim the free secondary indexed locales in storefronts you already serve, since they add budget with near-zero new-market risk; (3) localize fully for your top one or two revenue markets, metadata plus UI; (4) expand into large markets where the byte budget and competition still favor you. De-prioritize tiny storefronts where Apple Search Popularity signal is thin and the long tail returns 'insufficient data.' Revisit the priority list quarterly: install mix shifts, and a locale that was marginal can become a top-three market after a featuring or a seasonal spike, at which point its fields deserve the same care as your primary.
Don't repeat terms across your localizations either
The no-duplicates rule applies within and across the metadata Apple indexes together. If en-US and es-MX both rank in the U.S. store, a word in both fields is indexed once and the second copy is wasted budget. Keep the sets disjoint: put English terms in one, Spanish terms in the other, and reserve each field for words that aren't already in the name or subtitle of any localization indexed in that storefront. The goal across every locale is maximum distinct coverage, never overlap. Extend the discipline to the other no-repeat rules: do not add the plural of a word already present (Apple matches both forms), do not restate a term that lives in your app name or subtitle since those are indexed and counted once, and skip category names, your own brand, and filler words, all of which Apple handles separately and which waste bytes if duplicated. The cleanest mental model is a single deduplicated keyword universe per storefront: across the name, subtitle, and every keyword field indexed in that store, each meaningful term should appear exactly once. Your per-locale sheet is what enforces this: sort the combined token list, flag any repeat, and reclaim those bytes for a term you do not yet cover.
Coordinate localization with screenshots, CPPs, and conversion
Indexed metadata wins the search; the rest of the localized listing wins the install. Localizing keywords without localizing the visible storefront assets undercuts the gain, because conversion rate feeds back into rankings: Apple rewards listings that convert the traffic they receive. Localize screenshots and their captions per market: the caption text is a strong conversion lever even though it is not indexed for search, and culturally appropriate imagery, currency, and value propositions lift tap-through and install rates in that storefront. Custom Product Pages (CPPs) layer on top: each CPP can be localized too, and CPPs rank organically when you map keyword combinations to them, so coordinate your CPP keyword assignments with your per-locale keyword fields and run a conflict check: each keyword combo should map to exactly one page to avoid cannibalization. Remember the indexing boundary: promotional text and the description are not indexed for search in any locale, so do not spend keyword strategy there; use them for conversion messaging and timely notes. The end state is a per-locale listing where the indexed fields are deduplicated and byte-validated, the visible assets are genuinely localized for conversion, and CPPs extend the keyword reach without colliding with the base listing.
FAQ
Does adding a localization give me a new keyword field?
Yes. Each localization has its own app name, subtitle, and 100-byte keyword field, all indexed separately. Adding locales is how you increase the total number of terms you can rank for. Because App Name carries the highest text-relevance weight and Subtitle the second, every new localization is also a fresh shot at the two heaviest-weighted surfaces, not just the hidden keyword list. The multiplier scales roughly linearly with the locales you actually fill, which is why it is the real ceiling on keyword reach.
Do I have to translate my whole app to localize for ASO?
No. You can localize the App Store metadata (name, subtitle, keywords, screenshots) without translating the app's UI, and that indexed metadata is what drives search rankings. There is a caveat: if users in that market install and find an English-only interior, conversion and retention can suffer, and those signals feed back into rankings. So treat metadata-only localization as a deliberate ASO move for high-value markets, and pair it with at least partial app translation where install volume justifies the effort.
What is the es-MX trick for the US App Store?
The U.S. storefront indexes both English (U.S.) and Spanish (Mexico) metadata for your listing. Filling es-MX with a non-overlapping keyword set effectively adds a second 100-byte keyword field that ranks in the U.S. store, even for users searching in English. Do not duplicate your en-US terms there; a word in both fields is indexed once and the copy is wasted. Treat es-MX as 100 extra bytes of distinct U.S. keyword budget. Other storefronts index secondary locales too, so audit each priority market for the same free field.
Should I machine-translate my keyword field for each locale?
No. Search the terms native speakers actually use in that market. A literal translation of your English keywords often produces phrases nobody searches, wasting the field. Build each locale's set from Apple's localized autocomplete, competitor metadata in that storefront, and Apple Search Popularity as a relative index, never a fabricated search-volume number. Watch for English loanwords that outrank native equivalents, colloquial forms that beat dictionary words, and German-style compound nouns that a translator splits incorrectly.
How many bytes does a non-English keyword field hold?
It is always 100 bytes of UTF-8, but characters cost differently: ASCII is 1 byte, accented Latin about 2, and CJK 3 (some emoji 4). So a Japanese or Korean field holds only about 30-33 characters, while English holds the full 100. Validate by UTF-8 byte length (Buffer.byteLength), never string length, or you will truncate or overspend silently. In CJK locales every wasted byte hurts more, so duplicate, plural, or filler terms are especially costly; favor short, high-popularity tokens.
Which locales should I add first?
Start with storefronts that already generate your downloads and revenue, then claim the free secondary indexed locales inside stores you already serve (like es-MX in the U.S.). Next, fully localize (metadata and UI) your top one or two revenue markets, then expand into large markets where byte budget and competition still favor you. De-prioritize tiny storefronts where Apple Search Popularity signal is thin and the long tail returns insufficient data. Revisit quarterly, since install mix shifts and a marginal locale can jump into your top tier after a featuring.
appusula puts these checks in one self-hosted dashboard: keyword ranks, metadata validation, competitor tracking, and AI visibility.
Get started