Если открыть статистику по запросу modx, первое впечатление довольно приятное: частотность — 8 011. Для довольно нишевой CMS выглядит солидно. Можно быстро сделать вывод: вот он, большой массив интереса к MODX. Остаётся посмотреть, что именно люди ищут, разбить запросы по темам и работать дальше. Проблема обнаруживается после раскрытия списка:
Я просмотрел 324 строки, которые Wordstat показал внутри этого запроса. 56 из них явно относились к Yamaha и музыкальному оборудованию. Ещё 71 формулировка оказалась неоднозначной. То есть ещё до анализа собственно CMS значительная часть исходных данных уже требовала ручной проверки. И это хороший пример более общей проблемы: большая цифра рядом с названием технологии ещё не означает, что вся стоящая за ней статистика относится именно к этой технологии.
Как CMS встретилась с синтезатором
У слова MODX есть неприятное для анализа свойство: оно обозначает не только систему управления сайтом. Yamaha выпускает линейку музыкальных рабочих станций MODX. Поэтому рядом с веб‑разработкой в одной и той же выдаче появляются синтезаторы, редакторы для музыкального оборудования, модели устройств и запросы о покупке. Например, среди результатов встречались:
yamaha modx;
modx синтезатор;
yamaha modx editor.
Для человека разница очевидна. Для механического сбора данных — нет. Во всех трёх строках присутствует modx. Если просто выгрузить результаты и начать считать всё подряд, данные о CMS и музыкальных инструментах окажутся в одной таблице. Но даже удалить строки с yamaha и синтезатор недостаточно. Кроме 56 явно музыкальных запросов, ещё 71 строку пришлось оставить неоднозначной. Это были короткие названия моделей, версий, товарные формулировки и запросы, смысл которых нельзя было надёжно определить по одной строке. И здесь возникает важный вопрос: что делать со всем остальным? Самая опасная идея — взять калькулятор. 324 строки минус 56 музыкальных минус 71 неоднозначная. Получится 197. Можно было бы объявить: «Вот 197 запросов про MODX CMS». Только данные этого не подтверждают. Оставшаяся строка не становится запросом про CMS просто потому, что два других класса уже удалены. Среди остатка всё ещё могут быть брендовые, товарные, служебные или просто непонятные формулировки. Поэтому остаток я автоматически релевантным не считал.
Лучше недоклассифицировать, чем придумать смысл
При ручной очистке подобных данных есть соблазн дать каждой строке аккуратную метку. CMS. Музыка. Ошибка. Перенос. Настройка. Разработка. Таблица сразу становится красивой. Но если формулировка допускает несколько трактовок, такая классификация начинает описывать уже не исходные данные, а предположения исследователя. Я использовал более скучный подход: если смысл строки нельзя определить достаточно уверенно, она остаётся неоднозначной. Это особенно важно для коротких технических запросов. Название продукта, номер версии или одно слово без контекста могут относиться к документации, покупке, ошибке, обновлению или совсем другому продукту с таким же названием. Неопределённость здесь — не недостаток данных, который обязательно нужно устранить. Иногда это наиболее точное описание того, что действительно известно.
Что осталось после очистки
Когда явно нерелевантные значения отделены, внутри MODX начинают проявляться уже вполне понятные технические направления. В сохранённых данных были, например:
Запрос | Частотность |
ошибка modx | 45 |
modx php error | 19 |
modx fatal error | 14 |
перенос modx | 32 |
modx перенос сайта | 23 |
modx cookie | 27 |
Сами по себе эти числа ещё мало что решают. Интереснее то, что происходит при раскрытии отдельных веток. У запроса:ошибка modx — 45, нашлась более конкретная формулировка ‑при вызове formit modx выходит 500 ошибка — 5. Теперь передо мной уже не абстрактная «ошибка MODX», а конкретный сценарий: вызов FormIt приводит к HTTP 500. То же произошло с переносом:перенос modx — 32, → modx перенос сайта — 23. Верхний запрос обозначает направление, следующий уточняет задачу. Но здесь легко попасть в другую ловушку.
Более конкретный запрос не обязательно лучше
Когда появляется длинная и точная формулировка, возникает ощущение, что именно она и есть самый ценный результат. Например:при вызове formit modx выходит 500 ошибка — 5, выглядит гораздо содержательнее, чем:ошибка modx — 45. Это действительно более точное описание проблемы. Но из этого не следует, что запрос с частотностью 5 «лучше» запроса с частотностью 45. Частотность не измеряет качество проблемы. Она не показывает коммерческую ценность. И тем более не равна количеству уникальных пользователей. Более глубокая ветка полезна потому, что помогает увидеть смысл задачи, а не потому, что длинный запрос автоматически предпочтительнее короткого. При принятии решения всё равно нужны контекст, поисковая выдача, существующее покрытие темы и понимание того, действительно ли речь идёт об отдельной проблеме.
Почему нельзя складывать ветку
Есть ещё одна распространённая ошибка. Допустим, есть:ошибка modx — 45, и внутри неё:при вызове formit modx выходит 500 ошибка — 5. Очень хочется получить 50. Но такая арифметика не работает. Дочерние запросы находятся внутри структуры более широкого спроса и могут пересекаться с ним. Wordstat не говорит, что перед нами две полностью независимые группы людей. Поэтому частотности разных уровней дерева я не складывал. Та же проблема хорошо видна на другом примере — Telegram. В одном из исследований ветка выглядела так:телеграм бот — 107 753 → телеграм бот заявки — 185 → бот принимает заявки телеграм — 38→ бот который принимает заявки в телеграм канал — 13. Если сложить эти четыре числа, получившийся результат не будет означать практически ничего. Зато сама структура говорит довольно много. На верхнем уровне находится огромная и смешанная тема Telegram‑ботов. Ниже появляется конкретная область — заявки. Ещё ниже становится понятно, что речь идёт о боте, принимающем заявки. Затем возникает конкретный сценарий передачи заявки в канал.То есть дерево полезно прежде всего как способ переходить от общего названия технологии к конкретной задаче.
А если запрос показал ноль?
Обратная ситуация тоже интересна. Некоторые технически совершенно нормальные формулировки в отдельных проверках показывали 0.
Например:
• telegram callback не работает;
• tilda webhook ошибка;
• битрикс24 webhook не работает;
• woocommerce не приходят письма.
Из этого нельзя заключить, что callback никогда не ломается, webhook всегда работает, а WooCommerce исправно отправляет все письма. Ноль относится к конкретной формулировке в конкретном измерении. Пользователь может описывать ту же проблему совершенно другими словами. Поэтому отсутствие частотности — хороший повод не строить теорию вокруг конкретной фразы, но плохое доказательство отсутствия самой технической проблемы.
Шесть ошибок, которые особенно легко сделать
При работе с такими данными несколько ловушек повторяются особенно часто.
1. Принимать широкий запрос за одну тему. modx оказался одновременно CMS, Yamaha и набором неоднозначных значений.
2. Автоматически относить остаток к нужной категории. Если удалить явный музыкальный шум, всё оставшееся ещё не станет CMS.
3. Додумывать смысл короткой строки. Если запрос неоднозначен, честнее оставить его таким.
4. Складывать родительские и дочерние частотности. Структура дерева не является набором независимых аудиторий.
5. Считать ноль доказательством отсутствия проблемы. Ноль относится к формулировке, а не ко всему пользовательскому сценарию.
6. Считать большую частотность признаком хорошей темы. Большая цифра может означать шум, другой продукт или совершенно другое намерение.
Все эти ошибки происходят по одной причине: число выглядит объективнее текста. Но без разбора смысла строки цифра часто создаёт только иллюзию точности.
Причём здесь разработчики
На первый взгляд, всё это похоже исключительно на задачу SEO‑специалиста. На практике разница между инженерной и пользовательской формулировкой полезна гораздо шире. Пользователь редко приходит с диагнозом. Он не обязан знать, что у него проблема с PHP‑FPM, SMTP, правами файлов, callback или webhook. Он описывает наблюдаемое поведение: «не отправляется форма»; «бот не принимает заявку»; «после переноса сайт не работает»; «ошибка 500»; «не приходит письмо». Для разработчика или технической поддержки это исходные симптомы, которые ещё нужно связать с технической причиной.
Анализ реальных формулировок помогает понять, какими словами люди описывают эти симптомы. Это можно использовать не только при создании контента. Те же данные пригодятся при проектировании документации, FAQ, поиска по базе знаний, названий разделов поддержки и даже текстов сообщений об ошибках. Инженеру удобно написать в документации «Webhook callback error». Пользователь может искать «бот не получает ответ после оплаты». Оба говорят об одной системе, но используют разные словари. Если документация содержит только первый, второй человек может до неё просто не добраться.
Что в итоге показал MODX
Самый интересный результат оказался довольно простым. Частотность modx — 8 011 — сама по себе почти ничего не говорит о размере интереса к MODX CMS. Чтобы получить из неё полезные данные, пришлось:
• открыть 324 строки;
• отделить 56 явно музыкальных запросов;
• не пытаться насильно классифицировать ещё 71 неоднозначный;
• найти действительно CMS‑релевантные направления;
• и только после этого раскрывать отдельные ветки дальше.
Большой исходный запрос оказался не ответом, а только точкой входа. И, пожалуй, в этом главный вывод. Когда одно слово обозначает несколько продуктов, технологий или смыслов, статистика не очищает их автоматически. Чем шире запрос, тем осторожнее стоит относиться к большой цифре рядом с ним. Иногда самое полезное действие при анализе данных — не посчитать ещё что‑нибудь, а честно написать напротив строки: «Недостаточно информации, чтобы классифицировать».
Откуда данные
Примеры в статье взяты из моего исследования поисковых формулировок по CMS и веб‑сервисам, проведённого в августе‑сентябре 2026 года. В исходных материалах отдельно фиксировались периоды измерений, структура веток, нулевые значения и неоднозначные формулировки.
Полная методика, ограничения исследования и дополнительные примеры опубликованы в исследовании WebFixer24.
