Wordstat через API: он больше не в Директе, и упирается не в деньги

Проверено в сентябре 2026 года по документации — цены и квоты меняются, так что перед работой сверьтесь с актуальной версией.

Он переехал

Русская и английская версии документации расходятся, и это сбивает с толку. Английская описывает четыре шага, включая форму заявки и обращение в поддержку Директа с логином и ClientId. Это старый путь.

Актуальный Wordstat API живёт в Yandex Cloud, в составе Search API:

POST https://searchapi.api.cloud.yandex.net/v2/wordstat/topRequests
Authorization: Bearer <IAM-токен>

Аутентификация — обычный сервисный аккаунт Yandex Cloud с ролью search-api.webSearch.user. Никакого OAuth-приложения с кодом подтверждения при облачном пути не нужно вообще.

Быстрее всего вопрос решается практикой: выдать роль, взять токен, сделать один запрос. Если ответ пришёл — никакая заявка не требуется.

Методы

Метод	Что даёт	Тарифицируется
GetTop	топ запросов, содержащих ваши слова, за 30 дней	да
GetDynamics	частота по месяцам, неделям, дням	да
GetRegionsDistribution	распределение по регионам	да, дороже
GetRegionsTree	коды регионов	нет

Запрос GetTop принимает фразу до 400 символов и до 40 слов, число результатов, список регионов и типы устройств. В ответе — общее количество, массив результатов и похожие запросы.

Сколько это стоит

Двадцать рублей за тысячу запросов для GetTop и GetDynamics, пятьдесят — для распределения по регионам. Бесплатного объёма у Search API нет: нужен платёжный аккаунт с положительным балансом.

Прикинем реальную работу. Тринадцать тематических групп, полсотни исходных фраз:

Что	Запросов	Стоимость
GetTop по всем фразам	~50	1 ₽
GetDynamics по выжившим группам	~13	0,3 ₽
GetRegionsTree	1	0 ₽

Три рубля. Даже программа на порядок шире — тысяча запросов Wordstat плюс тысяча запросов к выдаче — обойдётся примерно в пятьдесят рублей. Пополнять баланс надо, но сумма символическая.

Вывод: цена — не ограничение. Ограничение другое.

Настоящее ограничение — квота

GetTop разрешает десять запросов в секунду, но всего сто запросов в час.

Это полностью определяет, как должен быть устроен сборщик:

• Ограничитель скорости обязателен. Не потому, что вас забанят, а потому что упереться в потолок легко на ровном месте.
• Возобновляемость важнее скорости. Упасть на восьмидесятом запросе и начать сначала стоит часа ожидания. Значит, состояние надо сохранять после каждого ответа, а не в конце прогона.
• Пакетность. Один GetTop с большим числом результатов разворачивает целую группу — до двух тысяч реальных формулировок со своими частотами плюс похожие запросы. Поэтому исходных фраз должно быть мало и они должны быть удачными. Схема «одна фраза — один запрос» сжигает квоту зря.

Те же три требования — ограничение скорости, сохранение состояния, пакетность — я закладывал в сборщик заказов с бирж, который каждый день обходит площадки и телеграм-каналы: в одной выгрузке с крупнейшей площадки набирается больше четырёхсот проектов. И в сборе тендерных публикаций, где данные копятся в локальную базу по расписанию. Задача одна и та же: внешний источник с лимитами и необходимость не потерять прогресс.

Есть ещё расхождение в документации: в справке по лимитам указан максимум 250 результатов, тогда как в описании метода допускается до 2000. Проверять эмпирически.

По какому числу приоритизировать

Ответ содержит два разных числа, и путать их дорого.

• totalCount — сколько всего запросов содержат эти слова. Это широкий потолок. Приоритизировать по нему — та же ошибка, что оценивать спрос по широкому соответствию в веб-интерфейсе.
• results[].count — частота конкретной формулировки, как её действительно набирают люди. Приоритизировать надо по ней.

Второе лучше операторной арифметики: вместо оценки вы получаете фактическое распределение реальных запросов.

Про операторы

Операторы Wordstat — кавычки, восклицательный знак, квадратные скобки, плюс — в документации API не описаны. Метод, который на них опирается, стоит на песке.

А вот веб-интерфейс wordstat.yandex.ru бесплатен и операторы поддерживает. Отсюда неожиданный вывод: на первой волне API может быть просто не нужен. Полсотни фраз руками — это пара часов работы, ноль рублей и операторная точность, которой у API нет.

Ценность API не в данных, а в автоматизации и повторяемости. Она начинает окупаться, когда сбор становится регулярным процессом, а не разовой задачей. Если вы собираете семантику один раз для одного сайта — идите в веб-интерфейс.

Что делать с собранными частотами

Сами по себе числа бесполезны. Дальше нужны две вещи.

Реестр. База «группа запросов → адрес страницы → статус». Именно он не даёт написать вторую страницу под тот же интент — самая частая и самая дорогая ошибка, потому что лечится она удалением URL. Правило простое: одна группа запросов — один адрес.

Оценка расстояния до денег. Частота без этого обманывает. Запрос может быть высокочастотным и при этом никогда не приводить к оплаченной работе. Я оцениваю каждую группу по шкале «сколько шагов от запроса до заказа» и всё, что дальше трёх шагов, не пишу вообще — независимо от частоты.

Потом собранные группы превращаются в структуру сайта: страницы под сочетания услуг и городов, разделы, статьи. Как это устроено технически — в отдельном разборе, на примере каталога из двухсот страниц.

Отдельно, для тех, кто планирует делать из этого продукт: условия использования ограничивают хранение и перепродажу данных Wordstat. Смотреть это надо до первых клиентов, а не после.