Cross-localization indexing: the App Store's hidden extra keyword budget
A storefront can index metadata from more than one localization into the same search pool. Used deliberately, that is up to 160 extra characters per storefront — the least-known lever in App Store metadata.
The mechanism
Every storefront (country) has a primary localization, and many index at least one more. Words from all indexed localizations join one combined pool for that storefront — the same pool the title, subtitle, and keyword field feed. Provide Spanish (Mexico) metadata and its title, subtitle, and keyword field can rank in United States searches: 30 + 30 + 100 additional characters on top of the English (U.S.) budgets.
Well-attested pairs
Apple publishes no official table, and pairings have shifted over the years — treat any pair you have not verified as a hypothesis. These are the widely reproduced ones:
| storefront | primary localization | also indexed |
|---|---|---|
| United States | English (U.S.) | Spanish (Mexico) |
| Canada | English (Canada) | French (Canada) |
| Japan | Japanese | English (U.S.) |
| Korea | Korean | English (U.S.) |
Community tables also report English (U.K.) or English (U.S.) as a secondary in several European and Asian storefronts. The pattern is real; the specific rows drift — which is why the verification probe below matters more than any table.
Verifying a pair empirically
Put a distinctive word only in the candidate localization's keyword field, ship it, and search the target storefront once the release has indexed:
{ "keyword": "fotocalc", "storefronts": [ { "country": "US", "appName": "PhotoCalc", "rank": 4, "totalResults": 11, "prev": null, "change": "new" } ] }
Ranking in the US for a word that exists only in Spanish (Mexico) metadata is the mechanism demonstrated, not inferred. One rank call per candidate pair settles what forum threads argue about.
Using the extra budget well
- Treat the secondary localization as overflow for the primary storefront: the keywords that did not fit the first 100 characters, minus anything already in the pool — coverage accounting applies across the combined pool the same way.
- Keep the visible fields honest in their own language. Localizations are real listings: a Spanish-language device in the US is shown the Spanish (Mexico) title and subtitle if you provide them, so a keyword-stuffed fake localization is user-visible damage, not a free field.
- Localize demand, not just supply: the words worth ranking for differ by storefront, so research with suggest and volume per country before copying a keyword set across markets.
FAQ
Is there an official Apple list of which localizations each storefront indexes?
No. Apple documents that storefronts support multiple localizations but has never published the indexing table. The community-maintained pairs are reverse-engineered and drift over time — verify a pair with a rank probe before spending budget on it.
Will adding a Spanish (Mexico) localization change what US users see?
Only for users whose device language matches it: a Spanish-language device in the US sees the Spanish (Mexico) listing. English-device users still see English (U.S.). That is why the secondary localization has to work as a real listing, not a keyword dump.
Does cross-localization indexing exist on Google Play?
Google Play indexes differently (including the long description) and openaso does not cover it. Do not transplant App Store localization tactics there unverified.
Terms
- storefront — One country's App Store, with its own search index, rankings, charts, and set of indexed localizations.
- localization — One language variant of an app's listing — title, subtitle, keyword field, description — submitted per locale code such as en-US or es-MX.
- cross-localization indexing — A storefront indexing the metadata of additional localizations into the same search pool as its primary one.
markdown mirror: /reference/cross-localization-indexing.md · full corpus: /llms-full.txt