GEO: Продвижение в искусственном интеллекте. Полное руководство от новичка до профессионала от платформы GeoAist

Коммерческий директор «КонтурСклада» заметил странную деталь на встречах с потенциальными клиентами. Одни приходили с ожиданием полностью автоматических закупок. Другие считали продукт обычной складской системой. Третьи спрашивали, правда ли внедрение занимает полгода. На сайте было написано иначе, но собеседники ссылались на ответы AI-сервисов.

Маркетолог повторил несколько таких запросов. В одних ответах компания не появлялась, в других её описывали по старому отраслевому каталогу. Ошибка не сводилась к отсутствию ссылки. Покупатель получал неверное объяснение того, что именно продаёт компания.

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

Для бизнеса меняется точка первого впечатления. Она всё чаще находится вне собственного сайта.

Три разных результата

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

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

Таблица 1 Что означает присутствие в ответе

Ситуация в ответе: Назван бренд

Что она показывает: Компания присутствует в тексте

Чего из неё ещё нельзя заключить: Что рекомендация положительна или уместна

Ситуация в ответе: Продукт предложен под задачу

Что она показывает: Сервис считает его вариантом для этого сценария

Чего из неё ещё нельзя заключить: Что пользователь выбрал его и что описание верно

Ситуация в ответе: Есть ссылка на собственный сайт

Что она показывает: Страница показана как источник или путь для перехода

Чего из неё ещё нельзя заключить: Что весь ответ основан на ней

Ситуация в ответе: Есть переход и обращение

Что она показывает: Зафиксировано действие посетителя

Чего из неё ещё нельзя заключить: Что на решение повлиял только AI-сервис

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

Что входит в GEO

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

Термин получил исследовательское оформление в работе GEO: Generative Engine Optimization, опубликованной авторами из академической и прикладной среды и представленной на KDD 2024. В ней изучали, как изменения содержания влияют на видимость источников в экспериментальной среде. Это важная постановка задачи, но результаты отдельного исследования нельзя переносить в виде гарантированного процента роста на любой коммерческий сайт и любой AI-сервис.[1]

Граница с SEO условна. Поисковые системы и AI-сервисы могут использовать общие страницы, индексы и сигналы качества. Google прямо связывает оптимизацию своих генеративных поисковых функций с обычной работой над поиском. В других продуктах отличаются источники, интерфейсы и способы получения данных.[3, 4] Разумнее объединять работу специалистов вокруг пути покупателя, чем спорить, как назвать каждую задачу в смете.

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

На что команда может влиять

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

Из этого не следует, что нельзя ставить численные цели. Можно запланировать рост доли корректных рекомендаций на выбранной панели вопросов, снижение числа фактических ошибок или увеличение обращений из AI-каналов. Нужно лишь заранее определить метод измерения и признавать, что результат зависит не только от внесённых изменений.

Удобно разделять обязательства команды и ожидаемый эффект. Выпустить проверенную страницу интеграции к определённой дате можно обещать. Добиться конкретного ответа во всех сервисах к той же дате нельзя гарантировать. Руководителю нужны обе части: что будет сделано и по каким наблюдениям он оценит пользу.

Где начинается полезная работа

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

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

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

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

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

Знания модели и сведения из источников

Во время обучения модель усваивает статистические закономерности из большого объёма данных. Получив вопрос, она строит ответ с учётом этих закономерностей и текущего контекста. Это не обычный поиск по хранилищу цитат: модель способна соединять сведения и ошибаться в конкретных деталях. Уверенный тон сам по себе ничего не говорит о достоверности.

Если сервис добавляет к вопросу найденные материалы, у модели появляется дополнительная опора. Такой подход часто описывают термином RAG, retrieval-augmented generation. В исследовании Lewis и соавторов он объединял параметрическую модель с извлечением сведений из внешнего массива документов.[2] В прикладных системах состав источников и способ поиска могут существенно различаться.

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

Рисунок 1 Ответ с дополнительными источниками и без них

Концептуальная схема. Она показывает различие подходов, а не внутреннее устройство конкретного сервиса.

Что происходит со страницей

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

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

Таблица 2 Наблюдения и их пределы

Наблюдение: В журнале сервера есть визит робота

Что удалось установить: Ресурс был запрошен

Следующая проверка: Что вернул сервер и доступен ли основной текст

Наблюдение: Страница обнаруживается в поиске

Что удалось установить: Она представлена в наблюдаемой выдаче

Следующая проверка: По каким задачам она полезна и актуальна

Наблюдение: URL показан в AI-ответе

Что удалось установить: Сервис включил ссылку в этот ответ

Следующая проверка: Подтверждает ли страница соседнее утверждение

Наблюдение: Компания описана без ссылки

Что удалось установить: Название и свойства появились в тексте

Следующая проверка: Верны ли они; источник может остаться неизвестным

Отсюда следует практическое ограничение. Если после правки статьи ответ изменился, это ещё не доказывает, что причиной стала именно правка. Между проверками мог обновиться индекс, модель, внешний обзор или контекст запроса. Наблюдение полезно, но причинный вывод требует более аккуратного сравнения.

Почему ответы расходятся

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

Запрос «системы управления запасами» допускает много трактовок. В ответ могут попасть учётные продукты, WMS, решения для прогнозирования или ERP. Уточнение «нужно рассчитывать закупочные рекомендации для дистрибьютора по истории продаж» уменьшает неоднозначность. Это не хитрость для получения желаемого названия, а различие между широкой категорией и реальным сценарием покупателя.

Но если добавить «расскажи, почему стоит выбрать КонтурСклад», тест изменится принципиально. Он будет проверять ответ на вопрос с уже указанным брендом, а не способность сервиса самостоятельно предложить компанию. Оба типа вопросов нужны, но в разных наборах.

Можно ли научить модель своему бренду

Многократное упоминание компании в обычном диалоге не является подтверждённым способом изменить базовую модель или её ответы другим пользователям. В текущем разговоре название окажется в контексте и повлияет на последующие реплики. Из этого не следует эффект продвижения.

Похожая путаница возникает с файлами для роботов. Разрешить доступ поисковому обходчику и разрешить использование материалов для обучения означает принять разные решения. Например, OpenAI описывает OAI-SearchBot как робота для поиска, GPTBot как робота, связанного с обучением, а ChatGPT-User как механизм отдельных посещений по действию пользователя. Настройки этих механизмов нельзя считать взаимозаменяемыми.[5]

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

Что делать с неполной прозрачностью

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

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

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

В начале проекта маркетолог «КонтурСклада» принёс список из двухсот запросов. Большинство представляло собой вариации фразы «лучшая система управления запасами». Список выглядел внушительно, но почти ничего не рассказывал о покупке. Не было вопросов о качестве исходных данных, частоте пересчёта, ручном согласовании заказа и проверке экономического результата.

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

Хорошая карта вопросов начинается с решения человека.

Как искать реальные формулировки

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

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

Из интервью желательно сохранять короткую исходную формулировку с контекстом, убрав персональные и закрытые сведения. Затем редактор может сделать из неё удобный тестовый вопрос. Источник и редакционная версия должны оставаться различимыми. Иначе через месяц команда перестанет понимать, какой запрос действительно звучал у клиента, а какой придумала сама.

От темы к сценарию

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

Таблица 3 Участники выбора и нужные сведения

Участник выбора: Финансовый директор

Вопрос в рабочей формулировке: Как проверить, окупается ли проект планирования закупок

Что должно помочь ему ответить: Методика пилота, состав затрат и ограничения расчёта

Участник выбора: Руководитель закупок

Вопрос в рабочей формулировке: Что делать с сезонностью и редкими продажами

Что должно помочь ему ответить: Разбор метода, требования к данным, примеры исключений

Участник выбора: ИТ-специалист

Вопрос в рабочей формулировке: Какие данные передаются в систему и обратно

Что должно помочь ему ответить: Документация интеграции, версии, права и порядок обмена

Участник выбора: Руководитель проекта

Вопрос в рабочей формулировке: Когда пилот готов к расширению

Что должно помочь ему ответить: Критерии завершения, результаты и оставшиеся риски

Такой разбор не требует отдельной страницы на каждый вопрос. Близкие вопросы могут хорошо раскрываться в одном материале. Разделять их стоит тогда, когда меняются задача, адресат, объём необходимого объяснения или способ поддержки информации. Правило «один URL на одну формулировку» быстро создаёт множество почти одинаковых страниц.

Какие вопросы включать в измерения

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

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

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

Как расставлять приоритеты

Универсальной формулы для приоритета нет. Команда сопоставляет значение вопроса для покупки, частоту его появления в доступных источниках, цену ошибки и собственную способность дать хороший ответ. Можно выставлять баллы, но это внутренний способ договориться о работе, а не обнаруженный закон AI-поиска.

В «КонтурСкладе» вопрос о полной автоматизации закупок получает высокий приоритет: неверный ответ создаёт ложные ожидания уже на первой встрече. Узкий вопрос об экспорте редкого отчёта остаётся в документации, хотя по нему проще добиться точного совпадения текста. Доступность результата не должна подменять его ценность.

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

Как поддерживать карту

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

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

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

На первой проверке «КонтурСклада» обнаружились четыре разные проблемы. Документация интеграции была доступна только после входа. На главной странице продукт назывался платформой управления запасами, а в каталоге стоял в категории WMS. Срок «две недели» относился к подготовленному пилоту, но в рекламной статье выглядел сроком любого внедрения. В ответах AI-сервисов встречались обе версии.