Как выбирать небрендовые темы, когда у сайта всего 22 клика

Дмитрий Лукашов

Эксперт Русской школы управления по искусственному интеллекту, основатель школы прикладного ИИ

Разберем другой способ: выбрать конкретный вопрос читателя, проверить, какой ответ можно доказать, и только потом решать, нужен ли отдельный материал. На выходе получится короткая очередь тем с основаниями и условиями проверки. Она не обещает рост трафика.

Что действительно известно из маленького отчета

Исходный пример – мой собственный сайт, не клиентский проект. В сохраненном срезе Google Search Console от 23 сентября 2026 года за 22 июня–21 сентября было 22 клика и 285 показов, CTR 7,7%, средняя позиция 5,7. Тип поиска – Web. Это историческая точка отсчета; результаты более поздних публикаций в нее не входят.

В таблице страниц главная получила 19 кликов, страница об авторе – 2, еще одна страница – 1. В видимой таблице запросов выделялось имя автора. Этого достаточно, чтобы заметить зависимость видимого спроса от знакомства с автором. Но недостаточно, чтобы назвать все остальные клики небрендовыми или вычислить точную долю такого спроса.

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

Полезная первая таблица выглядит так:

С таким отчетом можно выбирать следующий проверяемый шаг. Ранжировать десятки будущих статей по ожидаемым заявкам пока не на чем.

Шаг 1. Составить список вопросов, которые требуют действия

Начните с небольшого списка рабочих ситуаций. Источниками могут быть разрешенные для анализа обращения, вопросы на встречах, обращения в поддержку, собственные наблюдения. Для каждой записи сохраните источник и дату. Если ситуация придумана для упражнения, так и подпишите.

Вместо «ИИ в продажах» нужна формулировка вроде «Как понять, что в выгрузке обращений потерян ответственный?». В первом случае непонятно, какой результат получит читатель. Во втором можно показать входную таблицу, способ проверки и список строк, требующих внимания.

Разделяйте три вещи: слова человека, свое объяснение и вопрос, который еще надо проверить. Фраза одного собеседника не становится доказанным массовым спросом после того, как ее переписали профессиональными терминами.

Шаг 2. Проверить предполагаемое намерение в поиске

Для двух-трех наиболее понятных вопросов откройте обычную поисковую выдачу. Посмотрите, что предлагают заметные результаты: инструкцию, сравнение, каталог, документ или услугу. Запишите дату, регион и формулировку запроса. Это наблюдение конкретной выдачи, а не универсальный рейтинг.

Задайте себе два вопроса. Какое действие человек, вероятно, хочет выполнить? Есть ли у нас материал, который поможет это сделать? Если выдача по широкому запросу состоит из каталогов, длинная авторская колонка может отвечать другому намерению. Не обязательно отказываться от темы: можно уточнить вопрос и повторно проверить уже его.

Не приписывайте запросу частотность, если не измеряли ее. «Нашли похожие результаты» и «многие люди ищут это каждый месяц» – разные утверждения.

Шаг 3. Выбирать тему по доступной фактуре

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

Ниже – полностью учебный пример. Эти вопросы не взяты из клиентских разговоров, а приоритет не рассчитан по частотности.

Такой отбор защищает от публикаций, которые выглядят законченными, но не дают читателю проверить результат. Это редакционный метод, а не формула ранжирования Google.

Можно использовать три простых признака: есть конкретный вопрос; есть материал для доказательства; есть понятный результат для читателя. Если хотя бы один отсутствует, следующая задача – добыть недостающую фактуру. Не стоит компенсировать ее длинным введением.

Шаг 4. Решить, нужен ли новый URL

Сравните вопрос с уже существующими страницами. Если на сайте есть инструкция с тем же результатом для читателя, возможно, достаточно добавить в нее проверенный пример и исправить пробел. Новая статья с почти тем же ответом усложнит выбор и читателю, и редактору.

Отдельная страница оправдана, когда работа действительно другая. Например, объяснить структуру регламента и разобрать конфликт двух версий – разные задачи, если каждая раскрыта самостоятельно.

Запишите решение в очереди: вопрос → существующая страница или новый адрес → конкретное дополнение → основание. Адрес в плане пока обозначает будущую работу. Он не означает, что страница уже выпущена или попала в поиск.

Шаг 5. Дать ИИ ограниченную роль

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

Копируемый запрос:

«Ниже список вопросов с источниками, даты наблюдений, перечень существующих страниц и материалы, которые разрешено использовать. Составь таблицу: вопрос читателя; предполагаемое намерение; чем подтверждается вопрос; что можно показать в статье; существующий URL или необходимость нового; чего не хватает; следующий шаг. Разделяй наблюдения и гипотезы. Не придумывай частотность, позиции, цитаты, кейсы и результаты. Если оснований нет, напиши “нет данных”. Выбери не более двух кандидатов, которые можно подготовить с имеющейся фактурой. Объясни выбор. Не оценивай вероятность роста трафика».

Проверьте ответ на заведомо слабом пункте. Добавьте в список тему с обещанием роста продаж, но без измерений. Если модель предлагает убедительную историю успеха, такой результат нужно вернуть на исправление. Отказ от неподтвержденной темы – полезный результат работы.

Шаг 6. Заранее определить, что наблюдать после публикации

У каждого материала должна быть дата выпуска и короткая карточка наблюдения:

1. Страница опубликована и открывается по нужному адресу.
2. Поисковик обнаружил и проиндексировал конкретный URL – если это удалось проверить.
3. У страницы появились показы и клики за указанный период и тип поиска.
4. Есть доступные сведения о посещениях страницы и действиях читателей.
5. Есть принятые нетестовые обращения, квалифицированные запросы и оплаты – каждое событие отдельно.

Принятый sitemap не заменяет второй пункт. В давно действующей рекомендации Google, обновленной 18 декабря 2025 года, прямо указано: карта помогает обнаружению страниц, но не гарантирует их сканирование и индексирование. Это старое правило, повторно проверенное для статьи, а не новость сентября.

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

Если данных о платежах нет, пишите «неизвестно». Если в системе есть тестовая заявка, не считайте ее интересом читателя. Если запрос пришел без установленного источника, не приписывайте его последней статье только потому, что она опубликована недавно.

Что получится вместо списка из пятидесяти тем

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

Двадцать два клика не мешают начать работу. Они задают ее масштаб: меньше уверенных прогнозов, больше конкретных вопросов и материалов, результат которых можно проверить.

Числа исходного примера: сохраненный авторский срез Search Console от 23.09.2026 за 22.06–21.09.2026, Web. Таблица кандидатов и отрицательный тест – учебные конструкции, не результаты клиентского проекта.