Кросс-локализация в App Store: бесплатное место для ключевых слов, которое зря пустует у большинства приложений
В App Store Connect есть трюк с полем ключевых слов, который ничего не стоит, а большинство приложений его не трогают. Это не лазейка и не нарушение правил. Просто Apple индексирует больше одного языка на витрину, и почти никто не заполняет второй.
Механика такая. У каждой территории App Store есть основная локаль — язык по умолчанию для этого рынка — и одна или несколько дополнительных локалей, которые тоже сканирует поисковый алгоритм Apple. Ключевые слова в метаданных любой из этих локалей могут ранжировать тебя в этой стране. То есть витрина США читает не только твои поля на английском (США) — она также читает поля на испанском (Мексика). Заполни оба разными терминами — и у Apple появятся два набора ключевых слов для ранжирования вместо одного.
Почему это бесплатное место
Одна локаль даёт тебе три индексируемых поля: название приложения на 30 символов, подзаголовок на 30 символов и поле ключевых слов на 100 символов. Это 160 индексируемых символов на локаль. Описание не индексируется для поиска в App Store, так что вся игра — в этих 160 символах.
Дополнительная локаль — это второй набор тех же трёх полей, влияющий на ранжирование в той же витрине. Заполни поле ключевых слов es-MX для приложения из США — и вместо 100 скрытых символов у тебя будет около 200, плюс второй подзаголовок на 30 символов, который Apple тоже проиндексирует. Та же аудитория, та же витрина, площадь почти вдвое больше. Ты не платишь за это, тебе не нужны испаноязычные пользователи, чтобы получить выгоду, и не нужен отдельный листинг — просто перестань оставлять поле пустым.
Это место называют «потраченным впустую» потому, что поле почти всегда пустое или, что хуже, заполнено копией основной локали. И то, и другое — упущенная возможность.
Справочная таблица: какие локали индексирует каждая витрина
Эту карту стоит сохранить. Для каждой витрины она показывает основную локаль, которую индексирует Apple, и дополнительную локаль (или локали), которые она также сканирует. Данные приведены по документации ASO-инструментов 2026 года — Apple со временем их меняет, поэтому проверь свои ключевые рынки в App Store Connect или в своём ASO-инструменте, прежде чем писать:
| Япония | японский — ja | английский (США) — en-US |
*Витрина США — исключение: помимо es-MX она также индексирует французский, упрощённый китайский, традиционный китайский, корейский, португальский (Бразилия), русский, арабский и вьетнамский — всего девять дополнительных локалей.
Из таблицы видны два паттерна. Во-первых, английский (Великобритания) — рабочая лошадка среди дополнительных локалей: он индексируется как резервная локаль на подавляющем большинстве неанглоязычных витрин, из-за чего поле en-GB становится самым ценным для заполнения, если ты продаёшь глобально. Во-вторых, США необычно щедры — девять дополнительных локалей, и именно поэтому про приём с es-MX пишут чаще всего.
Подвох: только отдельные термины
Удвоение происходит, только если вторая локаль содержит слова, которых нет в первой. Два правила Apple делают это точным, и оба идут против ленивого подхода:
- Каждое слово индексируется один раз. Если термин встречается и в основном, и в дополнительном поле ключевых слов, дубликат ничего не даёт. Скопируй свой список ключевых слов en-US в es-MX — и ты потратил второе поле впустую, без дополнительного охвата.
- Слова не объединяются между локалями. Apple формирует многословные фразы внутри одной локализации, но никогда между двумя. Поставь «budget» в en-US и «presupuesto» в es-MX — и ты сможешь ранжироваться по каждому слову отдельно, но не по фразе, склеенной из обоих.
Так что правильный ход — не переводить свои основные ключевые слова в дополнительное поле. Нужно поместить туда совершенно другой набор отдельных слов — термины, которые не поместились в первые 100 символов, синонимы, смежные сценарии использования, длиннохвостые варианты. Второе поле — это резервное пространство, а не зеркало.
Именно поэтому наивный проход «просто перевести всё» только усугубляет проблему. Машинный перевод твоего поля ключевых слов на испанский даёт те же концепции на другом языке, а для общей витрины это по-прежнему дублирование по смыслу и часто в сопоставлении Apple. Ценность — в разнообразии второго поля, а не в дословной локализации первого.
Как на самом деле использовать второе поле
Пример для американского приложения-бюджетника. Основные поля en-US уже несут очевидные термины — допустим, название Ledger: Budget & Money, подзаголовок Track spending and savings, а поле ключевых слов en-US содержит expense,bills,debt,invoice,net worth,cash flow,receipt,tax,loan,credit.
Поле ключевых слов es-MX тогда свободно для совершенно другого набора отдельных слов — ни одно не повторяет название, подзаголовок или поле en-US — например, subscription,paycheck,allowance,envelope,forecast,split,reimburse,wallet,goal,statement. Это второе поле на 100 символов, влияющее на те же рейтинги в США, заполненное терминами, которых Apple раньше не видел. Добавь отдельный подзаголовок es-MX — и ты расширишь ещё и сигнал «название + подзаголовок».
Та же логика масштабируется вниз по таблице. Немецкое приложение заполняет en-GB переполнением на английском. Канадское приложение заполняет fr-CA. Бразильское приложение заполняет en-GB. В каждом случае второе поле — это отдельные термины, а не перевод, и каждый термин всё так же честно описывает приложение — что удерживает тебя в рамках правила Apple 2.3.7 о нерелевантных или защищённых товарным знаком ключевых словах.
Почему это работа над исследованием, а не переводом
Причина, по которой большинство приложений не используют это пространство, в том, что заполнить его правильно — реальная работа. Нужен набор ключевых слов для основной локали, затем второй, не пересекающийся набор для дополнительной локали — и так для каждой важной для тебя витрины. Умножь это на 50 языков метаданных App Store, и число дополнительных полей, которые нужно держать различными, быстро растёт. Понятно, почему команды либо пропускают дополнительное поле, либо вставляют туда основное и идут дальше.
Mokbi — это место, где живут и черновики, и учёт. Это полноценный издатель листинга магазина, а не просто редактор скриншотов: поток идёт Скриншоты → Feature graphic → Текст листинга → Перевод → Публикация, и сервис составляет черновик текста листинга — название, подзаголовок, поле ключевых слов, описание — и ведёт набор ключевых слов для каждой локали среди 50 языков, так что ты видишь бок о бок, что в каждом поле и где ты случайно повторяешься.
Важно понимать, что инструмент делает и чего не делает: он не придумает отдельные дополнительные ключевые слова сам по себе, а перевод в один проход продублировал бы твои термины вместо того, чтобы разнообразить их. Кросс-локализация — это стратегия, которую ведёшь ты: решаешь, на какие дополнительные локали ориентироваться, пишешь отдельный набор слов для каждой и следишь, чтобы они не пересекались. Mokbi даёт тебе поля для каждой локали, чтобы составить и организовать это в одном месте вместо таблицы, а затем экспортирует листинг, чтобы ты сам проверил и опубликовал его в App Store Connect.
Версия в один абзац
Узнай, какую дополнительную локаль индексируют твои главные витрины — таблица выше охватывает крупнейшие, твой ASO-инструмент покроет остальные. Заполни название, подзаголовок и поле ключевых слов этой дополнительной локали отдельными терминами, которые не поместились в основной. Никогда не дублируй слово между ними и никогда не жди, что Apple составит из них фразу. Сделано правильно, это самое дешёвое расширение ключевых слов в App Store — и оно лежит в поле, которое у тебя уже есть.
Что почитать дальше
- Поле ключевых слов App Store: как использовать все 100 символов
- На какие языки локализовать листинг App Store
- 50 языков метаданных App Store Connect в 2026 году
Источники: документация Apple App Store localizations и Review Guidelines (2.3.7); aso.dev о кросс-локализации; и MobileAction об индексации ключевых слов на уровне территорий.