App Store cross-localisatie: de gratis zoekwoordruimte die de meeste apps verspillen
Er is een trucje met het zoekwoordveld dat gewoon in App Store Connect zit, niets kost en dat de meeste apps onaangeroerd laten. Het is geen achterpoortje en het is niet tegen de regels. Het punt is alleen dat Apple per winkel meer dan één taal indexeert, en bijna niemand vult die tweede in.
Zo werkt het. Elk App Store-territorium heeft een primaire taal — de standaardtaal voor die markt — en één of meer secundaire talen die Apple's zoekalgoritme ook doorzoekt. Zoekwoorden in de metadata van beide talen kunnen je in dat land laten ranken. De Amerikaanse winkel leest dus niet alleen je Engelse (VS) velden; hij leest ook je Spaanse (Mexico) velden. Vul beide met verschillende termen en je geeft Apple twee zoekwoordensets om op te ranken in plaats van één.
Waarom dit gratis ruimte is
Eén taal geeft je drie geïndexeerde velden: een appnaam van 30 tekens, een subtitel van 30 tekens en een zoekwoordveld van 100 tekens. Dat is 160 geïndexeerde tekens per taal. De beschrijving wordt niet geïndexeerd voor zoeken op de App Store, dus die 160 tekens zijn het hele verhaal.
Een secundaire taal is een tweede set van diezelfde drie velden, die dezelfde winkelranking voedt. Vul het es-MX-zoekwoordveld voor een Amerikaanse app en je gaat van 100 tekens verborgen zoekwoorden naar ongeveer 200 — plus een tweede subtitel van 30 tekens die Apple ook indexeert. Zelfde publiek, zelfde winkel, ruwweg dubbel zoveel oppervlak. Je betaalt er niets voor, je hebt geen Spaanstalige gebruikers nodig om er profijt van te hebben, en je hebt geen aparte vermelding nodig — je stopt gewoon met het veld leeg te laten.
De reden dat het als "verspilde" ruimte telt, is dat het veld bijna altijd leeg is of, erger, gevuld met een kopie van de primaire taal. Beide gooien de kans weg.
De referentietabel: welke talen elke winkel indexeert
Dit is de kaart die het waard is om te bewaren. Voor elke winkel staat de primaire taal die Apple indexeert en de secundaire taal/talen die ook worden doorzocht. Koppelingen zoals gedocumenteerd door ASO-tooling in 2026 — Apple past deze na verloop van tijd aan, dus controleer je belangrijkste markten in App Store Connect of je ASO-tool voordat je gaat schrijven:
| Japan | Japans — ja | Engels (VS) — en-US |
*De Amerikaanse winkel is de uitzondering: naast es-MX indexeert deze ook Frans, Vereenvoudigd Chinees, Traditioneel Chinees, Koreaans, Portugees (Brazilië), Russisch, Arabisch en Vietnamees — negen secundaire talen in totaal.
Uit de tabel vallen twee patronen te destilleren. Ten eerste is Engels (VK) het werkpaard onder de secundaire talen — het wordt in de grote meerderheid van niet-Engelse winkels als reservetaal geïndexeerd, wat een en-GB-veld het meest waardevolle veld maakt om in te vullen als je wereldwijd verkoopt. Ten tweede is de VS ongewoon gul met negen secundaire talen, wat verklaart waarom er zoveel over de es-MX-zet wordt geschreven.
De valkuil: alleen andere termen
De verdubbeling gebeurt alleen als de tweede taal woorden bevat die de eerste niet heeft. Twee Apple-regels maken dit exact, en beide werken tegen de luie aanpak in:
- Elk woord wordt één keer geïndexeerd. Als een term in zowel het primaire als het secundaire zoekwoordveld voorkomt, doet het duplicaat niets. Plak je en-US-zoekwoordenlijst in es-MX en je hebt het tweede veld verbrand voor nul extra bereik.
- Woorden worden niet over talen heen gecombineerd. Apple vormt meerwoordzinnen binnen één lokalisatie, nooit over twee heen. Zet "budget" in en-US en "presupuesto" in es-MX en je kunt voor elk woord apart ranken — maar je zult niet ranken voor een zin die het ene aan het andere naait.
De juiste zet is dus niet om je primaire zoekwoorden te vertalen naar het secundaire veld. Het is om er een compleet andere set losse woorden in te zetten — de termen die niet in de eerste 100 tekens pasten, synoniemen, aanpalende toepassingen, long-tail-varianten. Het tweede veld is overloopruimte, geen spiegel.
Dit is ook waarom een naïeve "vertaal gewoon alles"-aanpak het probleem erger maakt, niet beter. Machinaal vertalen van je Engelse zoekwoordveld naar het Spaans levert dezelfde concepten op in een andere taal, wat voor een gedeelde winkel nog steeds duplicatie in betekenis is en vaak ook in Apple's matching. De waarde zit in het diversifiëren van het tweede veld, niet in het woord-voor-woord lokaliseren van het eerste.
Hoe je het tweede veld echt besteedt
Een uitgewerkt voorbeeld voor een Amerikaanse budgetteringsapp. De primaire en-US-velden dragen al de voor de hand liggende termen — zeg dat de naam Ledger: Budget & Money is en de subtitel Track spending and savings, met het en-US-zoekwoordveld gevuld met expense,bills,debt,invoice,net worth,cash flow,receipt,tax,loan,credit.
Het es-MX-zoekwoordveld is dan vrij om een compleet aparte zak losse woorden te dragen — geen enkele herhaling uit de naam, subtitel of het en-US-veld — bijvoorbeeld subscription,paycheck,allowance,envelope,forecast,split,reimburse,wallet,goal,statement. Dat is een tweede veld van 100 tekens dat dezelfde Amerikaanse ranking voedt, gevuld met termen die Apple daarvoor niet kon zien. Voeg een aparte es-MX-subtitel toe en je hebt ook het naam-plus-subtitel-signaal uitgebreid.
Dezelfde logica schaalt door de hele tabel heen. Een Duitse app vult en-GB met Engelse overloop-termen. Een Canadese app vult fr-CA. Een Braziliaanse app vult en-GB. In elk geval is het tweede veld andere termen, geen vertaling, en elke term beschrijft de app nog steeds eerlijk — waardoor je binnen Apple's richtlijn 2.3.7 over irrelevante of merkgebonden zoekwoorden blijft.
Waarom dit een onderzoeksklus is, geen vertaalklus
De reden dat de meeste apps deze ruimte verspillen, is dat het goed vullen ervan echt werk is. Je hebt een zoekwoordenset nodig voor de primaire taal, dan een tweede, niet-overlappende set voor de secundaire taal, en dat voor elke winkel die je belangrijk vindt. Vermenigvuldig dat met de 50 metadata-talen van de App Store, en het aantal secundaire velden dat je uit elkaar moet houden loopt snel op. Het is makkelijk te begrijpen waarom teams het secundaire veld overslaan of het primaire erin plakken en verdergaan.
Mokbi is waar het opstellen en de boekhouding samenkomen. Het is een volwaardige store-listing-publisher, geen simpele screenshot-editor: de flow loopt Screenshots → Feature graphic → Store text → Vertalen → Publiceren, en het stelt de vermeldingstekst op — naam, subtitel, zoekwoordveld, beschrijving — en beheert een zoekwoordenset per taal over 50 talen zodat je naast elkaar kunt zien wat in elk veld staat en waar je jezelf per ongeluk herhaalt.
Wees duidelijk over wat het hier wel en niet doet: de tool zal niet magisch zelf aparte secundaire zoekwoorden verzinnen, en één vertaalronde zou je termen dupliceren in plaats van diversifiëren. Cross-localisatie is een strategie die jij uitvoert — beslis welke secundaire talen je target, schrijf voor elk een aparte woordenset en zorg dat ze niet overlappen. Mokbi geeft je de velden per taal om dat op één plek op te stellen en te organiseren in plaats van in een spreadsheet, en exporteert daarna de vermelding zodat jij die zelf kunt beoordelen en publiceren in App Store Connect.
De versie in één alinea
Zoek op welke secundaire taal je grootste winkels indexeren — de tabel hierboven dekt de grote, je ASO-tool dekt de rest. Vul de naam, subtitel en het zoekwoordveld van die secundaire taal met andere termen die niet in de primaire pasten. Herhaal nooit een woord over de twee heen, en verwacht nooit dat Apple er een zin van maakt. Goed gedaan is het de goedkoopste zoekwoorduitbreiding op de App Store, en hij zit al in een veld dat je al hebt.
Wat je hierna kunt lezen
- Het App Store-zoekwoordveld: hoe je alle 100 tekens benut
- Naar welke talen je je App Store-vermelding moet lokaliseren
- De 50 metadata-talen van App Store Connect in 2026
Bronnen: Apple's documentatie over App Store-lokalisaties en Review Guidelines (2.3.7); aso.dev over cross-localisatie; en MobileAction over zoekwoordindexering op territoriumniveau.