App Store cross-localization: free keyword space

There's a keyword-field trick that sits right in App Store Connect, costs nothing, and most apps leave untouched. It isn't a loophole and it isn't against the rules. It's just that Apple indexes more than one language per storefront, and almost nobody fills the second one.

Here's the mechanic. Each App Store territory has a primary locale — the default language for that market — and one or more secondary locales that Apple's search algorithm also crawls. Keywords in either locale's metadata can rank you in that country. So the US store doesn't only read your English (U.S.) fields; it also reads your Spanish (Mexico) fields. Fill both with different terms and you've handed Apple two keyword sets to rank on instead of one.

Why this is free space

A single locale gives you three indexed fields: a 30-character app name, a 30-character subtitle, and a 100-character keyword field. That's 160 indexed characters per locale. The description is not indexed for search on the App Store, so those 160 characters are the whole game.

A secondary locale is a second set of the same three fields, feeding the same storefront's rankings. Fill the es-MX keyword field for a US app and you go from 100 characters of hidden keywords to about 200 — plus a second 30-character subtitle Apple will also index. Same audience, same store, roughly twice the surface. You don't pay for it, you don't need Spanish-speaking users to benefit, and you don't need a separate listing — you just stop leaving the field blank.

The reason it counts as "wasted" space is that the field is almost always empty or, worse, filled with a copy of the primary locale. Both throw the opportunity away.

The reference table: which locales each storefront indexes

This is the map worth bookmarking. For each storefront it lists the primary locale Apple indexes and the secondary locale(s) it also crawls. Mappings as documented by ASO tooling in 2026 — Apple adjusts these over time, so confirm your key markets in App Store Connect or your ASO tool before you write:

*The US storefront is the outlier: alongside es-MX it also indexes French, Simplified Chinese, Traditional Chinese, Korean, Portuguese (Brazil), Russian, Arabic, and Vietnamese — nine secondary locales in total.

Two patterns fall out of the table. First, English (U.K.) is the workhorse secondary — it's indexed as the backup locale across the large majority of non-English storefronts, which makes an en-GB field the single most valuable one to fill if you sell globally. Second, the US is unusually generous with nine secondary locales, which is why the es-MX move gets written about the most.

The catch: distinct terms only

The doubling only happens if the second locale holds words the first one doesn't. Two Apple rules make this exact, and both cut against the lazy approach:

• Each word is indexed once. If a term appears in both the primary and secondary keyword fields, the duplicate does nothing. Copy your en-US keyword list into es-MX and you've burned the second field for zero extra reach.
• Words are not combined across locales. Apple forms multi-word phrases within a single localization, never across two. Put "budget" in en-US and "presupuesto" in es-MX and you can rank for each word on its own — but you will not rank for a phrase that stitches one to the other.

So the correct move is not to translate your primary keywords into the secondary field. It's to put a completely different set of single words in there — the terms that didn't fit the first 100 characters, synonyms, adjacent use cases, long-tail variants. The second field is overflow space, not a mirror.

This is also why a naive "just translate everything" pass makes the problem worse, not better. Machine- translating your English keyword field into Spanish produces the same concepts in another language, which for a shared storefront is still duplication in meaning and often in Apple's matching. The value is in diversifying the second field, not localizing the first one word for word.

How to actually spend the second field

A worked shape for a US budgeting app. The primary en-US fields already carry the obvious terms — say the name is Ledger: Budget & Money and the subtitle is Track spending and savings, with the en-US keyword field holding expense,bills,debt,invoice,net worth,cash flow,receipt,tax,loan,credit.

The es-MX keyword field is then free to carry an entirely separate bag of single words — none repeating the name, subtitle, or en-US field — for example subscription,paycheck,allowance,envelope,forecast,split,reimburse,wallet,goal,statement. That's a second 100-character field feeding the same US rankings, filled with terms Apple couldn't see before. Add a distinct es-MX subtitle and you've extended the name-plus-subtitle signal too.

The same logic scales down the table. A German app fills en-GB with English overflow terms. A Canadian app fills fr-CA. A Brazilian app fills en-GB. In each case the second field is distinct terms, not a translation, and each term still honestly describes the app — which keeps you clear of Apple's guideline 2.3.7 on irrelevant or trademarked keywords.

Why this is a research job, not a translation job

The reason most apps waste this space is that filling it properly is real work. You need a keyword set for the primary locale, then a second, non-overlapping set for the secondary locale, and you need that for every storefront you care about. Multiply by the App Store's 50 metadata languages and the number of secondary fields to keep distinct gets large fast. It's easy to see why teams either skip the secondary field or paste the primary one in and move on.

Mokbi is where the drafting and the bookkeeping live. It's a full store-listing publisher, not just a screenshot editor: the flow runs Screenshots → Feature graphic → Store text → Translate → Publish, and it drafts the listing text — name, subtitle, keyword field, description — and manages a per-locale keyword set across 50 languages so you can see, side by side, what's in each field and where you're accidentally repeating yourself.

Be clear about what it does and doesn't do here: the tool won't magically invent distinct secondary keywords on its own, and a one-round translation would duplicate your terms rather than diversify them. Cross-localization is a strategy you run — decide which secondary locales to target, write a separate word set for each, and keep them from overlapping. Mokbi gives you the per-locale fields to draft and organize that in one place instead of a spreadsheet, then exports the listing for you to review and publish in App Store Connect yourself.

The one-paragraph version

Look up which secondary locale your top storefronts index — the table above covers the big ones, your ASO tool covers the rest. Fill that secondary locale's name, subtitle, and keyword field with distinct terms you couldn't fit in the primary. Never duplicate a word across the two, and never expect Apple to build a phrase across them. Done right, it's the cheapest keyword expansion on the App Store, and it's sitting in a field you already have.

What to read next

• The App Store keyword field: how to use all 100 characters
• Which languages to localize your App Store listing into
• App Store Connect's 50 metadata languages in 2026

Sources: Apple's App Store localizations and Review Guidelines (2.3.7) docs; aso.dev on cross-localization; and MobileAction on territory-level keyword indexation.

Draft and manage your per-locale keywords →