Cross-localizzazione sull'App Store: lo spazio keyword gratuito che quasi tutti sprecano
Esiste un trucco sul campo keyword che sta proprio dentro App Store Connect, non costa nulla, e la maggior parte delle app lo lascia intatto. Non è una scappatoia e non viola le regole. È solo che Apple indicizza più di una lingua per ogni store, e quasi nessuno riempie la seconda.
Ecco il meccanismo. Ogni territorio dell'App Store ha una lingua primaria — la lingua predefinita per quel mercato — e una o più lingue secondarie che l'algoritmo di ricerca di Apple analizza a sua volta. Le keyword nei metadata di entrambe le lingue possono farti posizionare in quel paese. Quindi lo store USA non legge solo i tuoi campi in inglese (Stati Uniti); legge anche i tuoi campi in spagnolo (Messico). Riempili entrambi con termini diversi e hai dato ad Apple due set di keyword su cui posizionarti invece di uno.
Perché è spazio gratuito
Una singola lingua ti dà tre campi indicizzati: un nome app di 30 caratteri, un sottotitolo di 30 caratteri e un campo keyword di 100 caratteri. Sono 160 caratteri indicizzati per lingua. La descrizione non è indicizzata per la ricerca sull'App Store, quindi quei 160 caratteri sono tutta la partita.
Una lingua secondaria è un secondo set degli stessi tre campi, che alimenta il posizionamento dello stesso store. Riempi il campo keyword es-MX per un'app USA e passi da 100 caratteri di keyword nascoste a circa 200 — più un secondo sottotitolo di 30 caratteri che Apple indicizzerà anch'esso. Stesso pubblico, stesso store, superficie all'incirca doppia. Non paghi nulla, non ti servono utenti di lingua spagnola per trarne beneficio, e non ti serve una scheda separata — devi solo smettere di lasciare il campo vuoto.
Il motivo per cui questo spazio viene considerato "sprecato" è che il campo è quasi sempre vuoto oppure, peggio, riempito con una copia della lingua primaria. In entrambi i casi getti via l'opportunità.
La tabella di riferimento: quali lingue indicizza ogni store
Questa è la mappa da salvare tra i preferiti. Per ogni store elenca la lingua primaria indicizzata da Apple e la lingua secondaria (o le lingue secondarie) che analizza anche lei. Mapping documentati dagli strumenti ASO nel 2026 — Apple li aggiusta nel tempo, quindi verifica i tuoi mercati chiave in App Store Connect o nel tuo strumento ASO prima di scrivere:
| Giappone | Giapponese — ja | Inglese (Stati Uniti) — en-US |
*Lo store USA è il caso anomalo: oltre a es-MX indicizza anche francese, cinese semplificato, cinese tradizionale, coreano, portoghese (Brasile), russo, arabo e vietnamita — nove lingue secondarie in totale.
Dalla tabella emergono due schemi. Primo, l'inglese (Regno Unito) è la lingua secondaria di riferimento — è indicizzata come lingua di riserva nella grande maggioranza degli store non anglofoni, il che rende un campo en-GB il più prezioso da riempire se vendi a livello globale. Secondo, gli USA sono insolitamente generosi con nove lingue secondarie, motivo per cui la mossa es-MX è quella di cui si parla di più.
Il tranello: solo termini distinti
Il raddoppio avviene solo se la seconda lingua contiene parole assenti nella prima. Due regole di Apple lo rendono preciso, ed entrambe penalizzano l'approccio pigro:
- Ogni parola viene indicizzata una sola volta. Se un termine compare sia nel campo keyword primario sia in quello secondario, il duplicato non serve a nulla. Copia la tua lista keyword en-US in es-MX e hai bruciato il secondo campo senza guadagnare portata.
- Le parole non vengono combinate tra lingue diverse. Apple forma le frasi multi-parola solo all'interno di un'unica localizzazione, mai tra due. Metti "budget" in en-US e "presupuesto" in es-MX e puoi posizionarti per ciascuna parola singolarmente — ma non ti posizionerai per una frase che le unisce.
Quindi la mossa corretta non è tradurre le tue keyword primarie nel campo secondario. È mettere lì un set di parole singole completamente diverso — i termini che non entravano nei primi 100 caratteri, sinonimi, casi d'uso adiacenti, varianti long-tail. Il secondo campo è spazio di overflow, non uno specchio.
Questo è anche il motivo per cui un ingenuo "traduci tutto e basta" peggiora il problema invece di risolverlo. Tradurre automaticamente il tuo campo keyword in inglese verso lo spagnolo produce gli stessi concetti in un'altra lingua, il che per uno store condiviso resta una duplicazione di significato, e spesso anche nel matching di Apple. Il valore sta nel diversificare il secondo campo, non nel localizzare il primo parola per parola.
Come spendere davvero il secondo campo
Un esempio concreto per un'app di budgeting USA. I campi primari en-US già coprono i termini ovvi — diciamo che il nome è Ledger: Budget & Money e il sottotitolo è Track spending and savings, con il campo keyword en-US che contiene expense,bills,debt,invoice,net worth,cash flow,receipt,tax,loan,credit.
Il campo keyword es-MX è quindi libero di contenere un insieme completamente separato di parole singole — nessuna che ripeta nome, sottotitolo o campo en-US — per esempio subscription,paycheck,allowance,envelope,forecast,split,reimburse,wallet,goal,statement. È un secondo campo da 100 caratteri che alimenta lo stesso posizionamento USA, riempito con termini che Apple prima non poteva vedere. Aggiungi un sottotitolo es-MX distinto e avrai esteso anche il segnale nome-più-sottotitolo.
La stessa logica si applica a scala ridotta lungo la tabella. Un'app tedesca riempie en-GB con termini in inglese di overflow. Un'app canadese riempie fr-CA. Un'app brasiliana riempie en-GB. In ogni caso il secondo campo contiene termini distinti, non una traduzione, e ogni termine descrive comunque onestamente l'app — il che ti tiene lontano dalla linea guida 2.3.7 di Apple su keyword irrilevanti o registrate.
Perché è un lavoro di ricerca, non di traduzione
Il motivo per cui la maggior parte delle app spreca questo spazio è che riempirlo correttamente è vero lavoro. Ti serve un set di keyword per la lingua primaria, poi un secondo set, senza sovrapposizioni, per la lingua secondaria, e ti serve per ogni store a cui tieni. Moltiplica per le 50 lingue di metadata dell'App Store e il numero di campi secondari da mantenere distinti cresce in fretta. È facile capire perché i team o saltano il campo secondario o incollano il primario e passano oltre.
Mokbi è il posto dove vivono la stesura e la gestione. È un publisher completo per la scheda dello store, non solo un editor di screenshot: il flusso va Screenshot → Feature graphic → Testo dello store → Traduci → Pubblica, e redige il testo della scheda — nome, sottotitolo, campo keyword, descrizione — e gestisce un set di keyword per lingua su 50 lingue, così puoi vedere, fianco a fianco, cosa c'è in ogni campo e dove ti stai ripetendo per sbaglio.
Sii chiaro su cosa fa e cosa non fa: lo strumento non inventerà magicamente keyword secondarie distinte da solo, e una traduzione a giro unico duplicherebbe i tuoi termini invece di diversificarli. La cross-localizzazione è una strategia che gestisci tu — decidi quali lingue secondarie puntare, scrivi un set di parole separato per ciascuna, ed evita che si sovrappongano. Mokbi ti dà i campi per lingua per redigere e organizzare tutto questo in un unico posto invece che in un foglio di calcolo, poi esporta la scheda perché tu la riveda e la pubblichi su App Store Connect.
La versione in un paragrafo
Verifica quale lingua secondaria indicizzano i tuoi store principali — la tabella qui sopra copre i più grandi, il tuo strumento ASO copre il resto. Riempi nome, sottotitolo e campo keyword di quella lingua secondaria con termini distinti che non entravano nel campo primario. Non duplicare mai una parola tra i due, e non aspettarti mai che Apple costruisca una frase tra loro. Fatto bene, è l'espansione keyword più economica sull'App Store, e sta in un campo che hai già.
Cosa leggere adesso
- Il campo keyword dell'App Store: come usare tutti i 100 caratteri
- In quali lingue localizzare la scheda del tuo App Store
- Le 50 lingue di metadata di App Store Connect nel 2026
Fonti: documentazione Apple su App Store localizations e Review Guidelines (2.3.7); aso.dev sulla cross-localizzazione; e MobileAction sull'indicizzazione keyword a livello territoriale.