Поле ключових слів — це 100 байтів, не символів
Павло Рубановський
July 10, 2026 · 6 хв читання
Ліміт, який майже ніхто не описує правильно
App Store Connect дає одне поле ключових слів на локалізацію і повідомляє, що обмеження — 100. Майже кожен ASO-гайд читає це як 100 символів. Це 100 байтів у кодуванні UTF-8, і для всіх, хто випускається не англійською, ця різниця вирішує, чи існує половина ваших ключових слів.
Ми дізналися про це так, як більшість студій: метадані, що виглядали нормально у формі, у живому лістингу виявилися коротшими.
Скільки коштує символ
UTF-8 має змінну ширину. Ціна символу залежить від абетки:
| Текст | Байтів на символ | Що дають 100 байтів |
|---|---|---|
Латиниця — puzzle | 1 | ~100 символів |
Кирилиця — головоломка | 2 | ~50 символів |
Більшість CJK — パズル | 3 | ~33 символи |
Емодзі — 🧩 | 4 | 25 символів |
Український або грецький лістинг має вдвічі менше місця під ключові слова, ніж англійський. Японський — утричі. Форма не попереджає: вона приймає введене, а стор обрізає пізніше, посеред слова, там де випав 101-й байт.
Чому наївна перевірка не працює
Перевірка, яку пишуть найчастіше, — саме та, що не працює:
`dart // Неправильно: рахує кодові одиниці UTF-16 у Dart, символи деінде. if (keywords.length > 100) { … }
// Правильно: міряти закодовану форму. if (utf8.encode(keywords).length > 100) { … } `
З усім, що поза базовою багатомовною площиною, пастка ще глибша. Емодзі — це один видимий гліф, часто дві кодові одиниці UTF-16 і чотири байти UTF-8. Три різні числа для одного символа, і лише останнє з них стор реально перевіряє.
Як планувати це поле
Що спрацювало на наших власних восьми лістингах:
1. Міряйте в байтах з першого чернетки, а не перед сабмітом. Вартість у байтах — це обмеження для копірайтингу, тож йому місце на етапі написання. 2. Приберіть пробіли після ком. Роздільник — кома; кожен збережений пробіл це байт, витрачений ні на що. На всьому полі це часто ціле зайве ключове слово. 3. Не повторюйте слова з назви застосунку та підзаголовка. Apple індексує і ці поля. Повтор коштує байтів і не додає охоплення. 4. Плануйте бюджет для кожної вітрини окремо, не глобально. Той самий набір коштує по-різному кожною мовою, тож набір, що вліз англійською, може переповнити німецьку.
Google Play рахує інакше — і це теж ловить
У Play немає поля ключових слів. Видимість читається з назви, короткого опису й повного опису, тобто обмеження не зникає, а переїжджає:
| Поле | Ліміт | Рахується в |
|---|---|---|
| Назва | 30 | символах |
| Короткий опис | 80 | символах |
| Повний опис | 4000 | символах |
| Поле ключових слів Apple | 100 | байтах |
Play рахує символи, тож кирилиця й CJK коштують там стільки ж, скільки латиниця. Пастка протилежна: команди, які навчились рахувати байти для Apple, переносять звичку і недозаповнюють поля Play — або пишуть один опис на обидва стори й втрачають щільність ключових слів, яку Play насправді індексує.
Два стори, дві моделі. Єдине безпечне припущення — що жодне поле не поводиться як інше.
Що з цим робити сьогодні
До чого це веде
Ми натикалися на це на власних застосунках досить часто, щоб зробити інструмент. Larko рахує байти точно під час набору, паралельно аудитує лістинги в різних вітринах і показує ризики відхилення — включно з Apple Guideline 2.3.10, іншим тихим убивцею метаданих, — ще до сабміту.
Він існує тому, що був нам потрібен. Байтовий ліміт — дрібниця, а на дрібницях сабміти і помирають.