Как покупатель спрашивает про товар теперь
Формулировка изменилась за пару лет. Раньше в поисковую строку уходило «кофемашина DeLonghi ECAM 22.110» - название, найденное заранее в обзоре или подсказанное продавцом. Теперь в чат уходит полтора предложения:
«Нужна кофемашина домой, пьем вдвоем, утром капучино. Кухня маленькая, ниша под технику 25 сантиметров. Бюджет до 250 тысяч тенге, хочется автоматический капучинатор и чтобы чистка не отнимала полчаса.»
Дальше система разбирает фразу на условия: ширина корпуса, автоматический капучинатор, обслуживание без разборки, потолок по цене, сценарий на двоих. К исходному вопросу она добавляет собственные уточнения: про шум, про материал корпуса, про то, сколько зерна уходит на чашку. И ищет товары, у которых эти признаки есть в полях: габариты, тип капучинатора, объем резервуара, цена, наличие. Рекламное описание в отбор не идет.
В такой фразе почти нет слов, под которые собиралась семантика магазина. Ни «купить», ни «недорого». Зато есть то, чего в семантике нет вообще: ширина ниши, число людей в семье, привычка пить капучино по утрам. Совпадение идет по признакам товара, а фраза целиком нигде не встречается.
Товар с артикулом в названии и описанием из трех строк в такой отбор не попадает. Система не догадывается, что модель CM-25 - это узкая автоматическая кофемашина для двоих. Догадаться не из чего.
Диалог занимает несколько реплик. Система уточняет бюджет, покупатель отвечает, список сужается до трех моделей, потом до одной. На каждом шаге товары отсеиваются по признакам, которые у половины каталога в данных не заполнены.
Подсказки в товарных диалогах тянут разговор в деньги: почти половина уточняющих вопросов от системы касается бюджета и скидок. Сумма называется на второй-третьей реплике. Позиции без внятной цены и статуса наличия выпадают из подборки на этом же шаге - рекомендовать товар, который может оказаться недоступным, система не станет.
Откуда брать формулировки покупателей и как собирать их в рабочий список, разобрано отдельно в статье про промпты вместо ключевых слов. Общая механика отбора источников описана в материале что такое GEO.
Если товара нет в наборе, из которого собирается ответ, для этого покупателя магазина не существует. Человек не дойдет до выдачи, где вы на первой строке, и цену не сравнит. Выбор к тому моменту уже сделан, осталось найти, где купить названную модель.
Обвала трафика нет, но выбор уходит в диалог до поиска
Две цифры про AI-сводки ходят рядом и пугают владельцев магазинов сильнее, чем стоило бы.
Первая: доля товарных запросов, над которыми Google показывает AI-сводку, держится около 3%. В темах здоровья и науки - около 43%. Разрыв объясним, коммерческий запрос системе выгоднее отдать в товарную выдачу, где есть цены и продавцы.
Вторая: там, где сводка появилась, кликабельность органики падает примерно на 61%.
Вместе они читаются как приговор. Только над каталогом сводка почти не появляется, значит прямой урон вашей выдаче ограничен.
Сравнение переехало в диалог, а он происходит до поиска. Покупатель приходит в Google или Яндекс уже со списком из двух-трех моделей, полученным в чате. Поиск закрывает последний шаг - где купить и за сколько. Американский замер разговорного режима Google показывает, что около 93% сессий не заканчиваются переходом на сайт. Цифра американская, на Казахстан, Узбекистан или Россию ее переносить нельзя. Направление она показывает.
Есть и региональная поправка, которую в западных отчетах не найти. Часть спроса ушла на маркетплейсы задолго до нейросетей: в России - на Ozon и Wildberries, где дешевле и проще возврат. Падение трафика магазина складывается из нескольких причин, и приписывать его целиком нейросетям неверно.
Объем товарных ответов при этом растет. Агентство Precis оценивает продуктовые карусели в европейской выдаче в 136 миллионов показов в месяц.
В отчетах сдвиг виден не там, где его ищут. Переходов из чатов мало, реферальный трафик от ChatGPT или Perplexity в Яндекс Метрике измеряется десятками визитов в месяц, и по нему выводов не сделать. Полезнее смотреть на другое: долю брендовых запросов в Search Console, долю прямых заходов, число сессий до покупки. Когда выбор сделан в диалоге, человек приходит по названию модели или сразу на сайт, и аналитика запишет это в брендовый спрос.
Западные замеры покрывают Google и ChatGPT, а покупатель в регионе ходит еще и в Алису, Нейро, GigaChat, DeepSeek. Как эти системы отвечают на товарные запросы вашей категории, из отчетов не узнать - там таких данных нет. Проверяется руками за час: задайте десяток запросов со сценарием и бюджетом в пяти системах и отметьте, чьи товары они назвали. Результат по бытовой технике и по стройматериалам отличается сильно, и общая цифра тут бесполезна.
Вывод скучный: паниковать рано, менять надо данные о товарах. Тексты про надежность и сервис на главной странице эту задачу не решают.
Карточка товара: что в ней должно быть и в каком порядке
Аудит каталога идет по карточкам, а не по сайту. Метатеги, скорость и структура разделов - обычная гигиена. Она нужна, но товар выпадает из ответа не поэтому.
Полнота атрибутов проверяется списком. Для каждой позиции: тип товара, назначение, для кого и для какой задачи, совместимость, габариты со всеми тремя размерами, вес, материал, комплектация, гарантия, страна производства, сценарий использования. Выгрузите каталог в таблицу, поставьте поля колонками и посчитайте пропуски. Картина повторяется из проекта в проект: габариты заполнены у части позиций, назначение почти нигде. Поля под сценарий в каталоге нет вообще.
Набор полей отличается по категориям, универсального списка нет. Технике нужны габариты, потребление, совместимость и порядок обслуживания. Одежде - состав ткани, посадка, размерная сетка с мерками в сантиметрах, уход. У мебели свой набор: размеры в собранном и разобранном виде, материал каркаса, допустимая нагрузка, время сборки. А расходникам и запчастям важнее всего совместимость со списком моделей - в товарных диалогах про нее спрашивают чаще, чем про цену.
Дальше порядок. Характеристики и назначение должны стоять в начале страницы: выше отзывов, выше блока «с этим товаром покупают» и маркетингового описания. Система читает страницу сверху вниз и берет то, что нашла первым. Спецификация, спрятанная во вкладку под отзывами, лежит для системы слишком глубоко. Про то, как устроен извлекаемый фрагмент внутри абзаца, есть отдельный разбор про чанки; здесь речь о месте блоков на странице.
С названием товара история отдельная и почти всегда запущенная. В каталоге стоит «Кофемашина CM-25-BLK», в фиде «CM25 черн.», в заголовке страницы третий вариант. Название - первое поле, которое читает система. По нему она понимает, что за товар перед ней. Рабочая формула: тип товара, бренд и модель, главное отличие, для кого. Собранное по ней «Кофемашина автоматическая DeLonghi Magnifica S, узкий корпус, съемный заварочный блок» закрывает сразу несколько условий запроса до того, как система дошла до характеристик. Артикул в названии нужен складу. Покупателю и системе он не говорит ничего.
Еще одно слабое место - описание от поставщика. Его копируют без изменений сотни магазинов, и текст в карточке слово в слово совпадает с тем, что стоит у конкурентов. Причины выбрать вас у системы в этом случае нет: она возьмет источник, у которого больше подтверждений вокруг - отзывы в коде, полная спецификация, свежая цена. Переписывать текст ради уникальности тут бесполезно. Помогает добавленная фактура, которой у поставщика не было.
Строка описания собирается из четырех частей: характеристика, что она дает покупателю, чем подтверждается, кому подходит.
Разверну на кофемашине:
- характеристика: съемный заварочный блок
- что дает: промывается под краном за минуту, без разборки корпуса
- чем подтверждается: блок вынимается без инструмента, производитель заявляет ресурс в 5000 циклов
- кому подходит: тем, кто варит несколько чашек в день и не готов возиться со специальной химией
В карточке это превращается в два предложения обычным языком. Заварочный блок снимается без инструмента, моется под краном, разбирать корпус и покупать чистящие таблетки не придется. Производитель заявляет ресурс блока в 5000 циклов, для двоих кофеманов это примерно семь лет.
Такая строка отвечает сразу на несколько вопросов покупателя и цитируется целиком. Строка «удобная и надежная кофемашина для дома» не отвечает ни на один.
С изображениями правило одно: все, что нарисовано на инфографике, дублируется словами в тексте карточки. Размеры с указателями на картинке помогают покупателю, а для системы этой информации не существует. Тот же набор цифр в характеристиках закрывает вопрос про габариты, а картинка остается работать на человека.
Блок вопросов и ответов на карточке недооценен сильнее прочего. Покупатели спрашивают одно и то же: поместится ли, шумит ли, что в комплекте, подойдет ли к такой-то модели. Ответы менеджера в личной переписке пропадают бесследно. А вот на странице они превращаются в готовые фрагменты под такие вопросы.
Без размеченной цены и наличия товар выпадает из подборки
Разметка переводит содержимое карточки в поля, которые читаются без разбора верстки. Для товара работает связка из трех блоков: Product с названием, артикулом и брендом, Offer с ценой, валютой и статусом наличия, AggregateRating со средним баллом и числом оценок.
Сильнее всего разметка работает на длинных запросах: по ним страницы с Product попадают в сводку значительно чаще, чем страницы, где те же данные лежат только в верстке.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Кофемашина автоматическая, ширина 25 см",
"sku": "CM-25-BLK",
"brand": {"@type": "Brand", "name": "Пример"},
"offers": {"@type": "Offer", "price": "249000",
"priceCurrency": "KZT", "availability": "https://schema.org/InStock"},
"aggregateRating": {"@type": "AggregateRating",
"ratingValue": "4.6", "reviewCount": "312"}
}
Рассинхрон - главная беда этой части. В разметке стоит 189 000 тенге, на странице покупатель видит 210 000. Обе цифры теряют вес: система не знает, какой верить, и товар уходит из подборки целиком. То же с наличием. Статус InStock остается с прошлого сезона на позиции, которую давно сняли с продажи. Обходится это дороже, чем отсутствие разметки. Стоит системе один раз порекомендовать недоступный товар, и дальше она возьмет чужой.
Поэтому спрашивать надо с процесса, а не с разработчика. Цена и остаток подтягиваются в разметку из учетной системы тем же способом и с той же периодичностью, что и на страницу. Ручные правки в шаблоне держатся до первой акции.
В Offer помещаются еще условия доставки и возврата. Поля shippingDetails и hasMerchantReturnPolicy заполняют редко, а при сравнении двух похожих предложений они работают как отличие: одинаковая цена товара перестает быть одинаковой, когда у одного продавца доставка бесплатная, а возврат в течение месяца.
Валюта указывается по рынку продажи. Для казахстанского магазина - KZT, для узбекского - UZS, для российского - RUB. Цена в тенге с валютой USD в разметке разбирается с ошибкой в сотни раз, и позиция вылетает из сравнения как аномально дорогая.
Шаблон тут проверять бесполезно, смотреть надо сами страницы, выборкой. Валидатор структурированных данных открывается по адресу карточки и показывает, что система прочитала. Возьмите десяток товаров разных типов: акционный, распроданный, с вариантами по размеру, из последнего импорта. Ошибки вылезают на вариантах и на акциях, где цену перебивает скрипт.
Типы разметки и их применение за пределами товара - тема отдельной статьи про Schema.org. Сам магазин как организация описывается через Organization и sameAs, про это есть разбор сущности бренда. Здесь граница проходит по товару.
Отзывы: главный актив и главная техническая дыра
Отзывы ценнее описания по простой причине: покупатели пишут то, чего нет в спецификации. «Влезла в нишу 45 сантиметров, зазор пара миллиметров». «Шумит на отжиме, ставить рядом со спальней не советую». «Молоко взбивает нормально, но капучинатор мою каждый вечер». Это готовые ответы на запросы вида «поместится ли», «шумно ли», «сложно ли обслуживать» - те самые формулировки, с которыми покупатель приходит в чат.
Техническая часть портит всю картину. Отзывы почти везде подключены сторонним виджетом и подтягиваются скриптом уже после отрисовки страницы. Большинство систем JavaScript не исполняет - в исходном коде для них пусто. Магазин с четырьмя тысячами отзывов выглядит магазином без отзывов.
Последствие неприятное. Мнение о товаре системе все равно нужно, и она собирает его там, где текст лежит в коде: на маркетплейсе, в видеообзоре, на форуме, в сторонней подборке. Ваши отзывы работают на чужую карточку.
На проверку уйдет минута: откройте карточку, посмотрите исходный код страницы и поищите в нем фрагмент текста отзыва. Если фрагмент не находится, отзывов для системы нет.
Что с этим делают:
- отзывы отдают в HTML страницы, виджет оставляют для оформления
- размечают средний балл вместе с текстами отзывов, датами и авторами
- внутри блока их группируют по сценариям и возражениям: про маленькую кухню, про шум, про обслуживание
- отвечают в карточке на вопросы покупателей, и ответы тоже лежат в коде
Группировка полезна сама по себе. Блок «что пишут про шум» - готовый ответ на такой вопрос покупателя. Один абзац с четырьмя цитатами работает лучше, чем средний балл 4,6.
Свежесть весит больше количества. Три сотни отзывов, последний из которых написан два года назад, читаются как сигнал, что товар сняли с продажи. Двадцать отзывов за квартал полезнее.
Накрутка работает против магазина. Одинаковые восторженные тексты без деталей не дают ни сценариев, ни ограничений, извлекать из них нечего. Отзыв с недостатком ценнее: он попадает в ответ на вопрос про слабые места модели, а о них спрашивают почти всегда. Магазин, где минусы названы честно и прокомментированы, выигрывает сравнение с тем, у кого все на пять звезд.
Особый случай - новый магазин, где отзывов почти нет. Рисовать их бессмысленно и опасно: поисковые системы отклоняют рейтинг в разметке, под которым нет оценок покупателей, а нейросеть сверяет цифру с тем, что видит на других ресурсах. Работает обходной путь: блок вопросов и ответов, разбор от продавца с личным опытом использования, отзывы о доставке и сервисе, видео распаковки. Все это дает тот же тип содержимого - конкретику от человека, который товар держал в руках.
Просить отзыв надо вопросами. Письмо через две недели после доставки с тремя пунктами - куда поставили, что понравилось, что оказалось неожиданным - приносит текст, из которого есть что цитировать. Пять звезд без комментария не дают ничего ни системе, ни следующему покупателю.
Про ресурсы за пределами сайта, где мнение о товаре тоже собирается, есть материал про размещение контента. Для карточки же правило короткое: сначала свой код, потом чужие площадки.
Категория или карточка: что отвечает на «лучшие»
Запросы делятся на два типа, и отвечают на них разные страницы.
Запрос про выбор внутри категории - «лучшие встраиваемые посудомойки 45 сантиметров», «что взять из узких стиральных машин до 60 тысяч рублей» - закрывается страницей категории или подборки. Системе нужен список с ценами и отличиями, одна карточка тут не подходит.
А на конкретную задачу отвечает карточка: «подойдет ли эта модель под столешницу 60 сантиметров», «хватит ли мощности на две чашки подряд». Ответ лежит в характеристиках и отзывах.
Поэтому в каталоге нужны страницы под составные запросы, а общими разделами дело не закрывается. Фильтр «узкие посудомойки 45 см с отсрочкой старта» выносят на отдельную страницу с адресом, заголовком и коротким текстом - если по такому сочетанию есть спрос. Открывать все комбинации фильтров подряд нельзя, получится тысяча пустых страниц и мусор в индексе.
Порядок товаров в категории тоже участвует в ответе. Система читает первые позиции списка вместе с ценами, поэтому распроданные товары и позиции под заказ вверху страницы отнимают место у того, что можно купить сегодня. Сортировка по наличию решает это без единой строки кода.
Объем текста на странице категории переоценен. Рабочий ориентир - 300-350 слов: краткое описание, чем модели отличаются, на что смотреть при выборе. Дальше выгоднее показать больше товаров на первой странице, чем дописывать простыню внизу. Система читает список позиций с ценами как ответ, а нижний текст с ключевыми словами игнорирует.
Разделы лучше называть на языке покупателя. «Встраиваемая техника для узких кухонь» ближе к тому, как человек описывает задачу, чем «Бытовая техника / Встраиваемая / 45 см». Внутренняя номенклатура из учетной системы в заголовки категорий попадать не должна, она понятна складу и никому больше.
Хлебные крошки с разметкой BreadcrumbList показывают, где товар находится в каталоге. Для магазина с глубокой вложенностью это дешевая правка с заметной отдачей: карточка перестает выглядеть страницей без контекста, и система понимает, к какому типу товаров ее относить.
Подборки под сценарий работают лучше формальных категорий. «Кофемашины для узкой кухни», «посудомойки для семьи из четырех человек», «техника для съемной квартиры» - страницы под то, как покупатель описывает ситуацию.
Сравнения и подборки цитируют охотнее карточек
Карточку по цитируемости обгоняют другие форматы: сравнение двух моделей, подборка под сценарий, гайд покупателя.
Покупатель почти всегда сравнивает. На вопрос «что лучше взять при бюджете до 3 миллионов сумов» системе нужен источник, где две модели уже поставлены рядом и названы отличия. Карточка отвечает про один товар, сравнение закрывает вопрос целиком.
Цитируемое сравнение собирается в обратном порядке. Сначала короткий вывод: кому какая модель. Потом таблица отличий по параметрам, а за ней по абзацу на модель с ситуацией, где она выигрывает. Система берет первый фрагмент, который отвечает на вопрос, и если там написано «обе хорошие, читайте дальше», брать нечего.
Условие одно, и его нарушают почти все: сравнение должно быть честным. С недостатками и с ситуациями, где выигрывает другая модель. Иногда - с прямым ответом «эту не берите, если у вас жесткая вода». Подборка, где все пять товаров хороши, а разница только в цене, для системы бесполезна: отличий из нее не вытащить.
Чем конкретнее ограничение в заголовке, тем выше шанс на цитату. «Три посудомойки для кухни с нишей 45 см: что влезет и что не влезет» лучше, чем «Как выбрать посудомоечную машину». Второй заголовок в интернете уже есть, тысячу раз.
Подборки надо держать свежими, иначе они работают против вас. Список «лучшие модели 2025 года», который не обновляли год, вычеркивается по дате: система видит устаревший материал и берет свежий у конкурента. Дата обновления с перечнем изменений в начале страницы решает проблему на год вперед.
Гайд покупателя закрывает шаг раньше - когда человек не знает, какие вообще бывают варианты. Такой материал редко приносит прямую продажу, но системы берут из него определения и критерии выбора.
Сравнение снимает выбор между двумя финалистами, а подборка ловит сценарий. Магазину нужны все три формата, но начинать лучше со сравнений по топовым позициям - там короче путь к деньгам.
Товарные данные и фиды: два контура
В ответ товар попадает двумя дорогами. Первая - через сайт: бот читает карточку и разметку. Вторая - через товарный фид: система берет данные из выгрузки, которую магазин готовит сам. Фидовые боты страницу не рендерят и на верстку не смотрят, для них существует только содержимое фида.
Контуры по рынкам разные, и путать их дорого.
В России работают фиды под Яндекс: товарные блоки в выдаче, Яндекс Маркет как отдельная площадка. Плюс карточки на Ozon и Wildberries: для системы это такой же источник данных о товаре, как ваш сайт. Часто более полный: там обязательные поля заполнены, потому что без них модерация не пропустит.
В Казахстане и Узбекистане работает Google Merchant Center, и товарный фид туда - базовая настройка для магазина. Плюс локальные площадки: Kaspi в Казахстане, Uzum в Узбекистане. Карточки там у магазина обычно уже есть, и заполнены они по требованиям площадки, а не по вашему усмотрению.
В фиде заполняются все поля, а не обязательный минимум. Идентификатор GTIN или артикул производителя, бренд, категория по классификатору площадки, состояние товара, габариты упаковки. По идентификатору система сшивает вашу карточку с карточками того же товара в других местах и собирает цену, характеристики и отзывы в одну сущность. Без идентификатора позиция остается безымянной строкой, которую не с чем сопоставить.
Частота обновления при этом важнее полноты. Фид выгружается раз в сутки, цены в магазине меняются трижды в день - получается тот же рассинхрон, что и с разметкой, только заметный не сразу.
Синхронизировать нужно четыре поля в первую очередь: цену, наличие, название и изображения. Название в фиде часто расходится с тем, что стоит на сайте, и получаются два разных товара вместо одного. С картинками похоже: в карусель уходит кадр из фида, а на странице стоит другой, и покупатель после перехода не сразу понимает, что попал на тот же товар. Главное изображение должно совпадать в обоих местах.
Отдельно про маркетплейс как источник. Если ваша карточка на площадке заполнена лучше, чем карточка на сайте, система процитирует площадку. Формально товар в ответ попал. Фактически покупатель ушел покупать туда, где выше комиссия и нет вашего контакта. Так что аудит идет по обеим карточкам сразу.
Про агентские покупки скажу коротко, без картинок будущего. Shopify и Universal Commerce Protocol строят инфраструктуру, где агент собирает корзину и оформляет заказ сам. McKinsey оценивает объем такой торговли в 3-5 триллионов долларов к 2030 году. В нашем регионе это пока не работает - ни платежная часть, ни интеграции магазинов. Готовиться к сценарию отдельно не нужно: полные атрибуты, честная цена и актуальный остаток - то же самое, что требуется сегодня.
С чего начать при разном размере каталога
Первый шаг одинаковый для всех: десять товаров с наибольшей выручкой. Не весь каталог и не то, что жалко бросать. Десять позиций, которые кормят магазин.
Сотню позиций закрывают руками, полностью, за пару недель. Каждая карточка получает полный набор атрибутов, назначение, сценарий, ответы на частые вопросы покупателей. Плюс разметка на всех страницах и отзывы в коде. Каталог такого размера можно довести до состояния, когда работать дальше некуда.
До тысячи позиций руками идет только топ по выручке, дальше шаблоны по типу товара. Шаблон описания собирается из полей учетной системы: тип, габариты, материал, назначение, сценарий. Получается сухо, зато полно, и это лучше, чем красивый текст без единого параметра. Отзывы и вопросы дописываются по мере накопления.
На десятках тысяч позиций работа идет с данными, а не со страницами. Атрибуты приводятся к единому справочнику, описания генерируются из полей, качество проверяется выборкой по сотне карточек. Приоритет - выручка и маржа: доработали топ, померили, спустились ниже.
Остается вопрос, кто делает это руками. Копирайтер без доступа к учетной системе напишет гладкий текст без цифр и характеристик, потому что взять их неоткуда. Рабочая связка выглядит так: данные выгружает тот, кто ведет каталог, формулировки покупателей собирает тот, кто читает переписку и слушает звонки, разметку ставит разработчик один раз шаблоном. Три роли расписывают до старта, иначе задача повисает между отделами и не двигается месяцами.
Результат проверяют действием, а не отчетом. Возьмите десять товаров, для каждого сформулируйте два-три запроса покупателя со сценарием и бюджетом, прогоните через пять систем и запишите, кто попал в ответ. Повторите через полтора-два месяца после правок. Методика замера с метриками и периодичностью описана в статье про измерение видимости в нейросетях.
Сроки тут длиннее, чем хочется. Страницу нужно переобойти, фид - перевыгрузить, а часть систем обновляет представление о товаре с задержкой в недели. Раньше чем через полтора-два месяца по десятке топовых позиций сдвига не будет, и то при условии, что менялись данные, а не оформление. Замер до старта поэтому обязателен: без исходной точки через два месяца нечего будет сравнивать, останется спор о впечатлениях.
Коротко
Покупатель описывает системе задачу, а не модель, и товар попадает в ответ через данные о нем. Обвала органики у магазина при этом нет: над каталогом AI-сводка почти не показывается. Меняется место, где человек делает выбор.
Работа сводится к четырем вещам. Полные атрибуты карточки с назначением и сценарием, поднятые в начало страницы. Разметка Product с ценой и наличием, синхронная с учетной системой. Отзывы в коде страницы, а не в скрипте. Товарный фид под свой рынок, с теми же ценами и названиями, что на сайте.
Пятое, о чем забывают: карточка того же товара на маркетплейсе читается наравне с вашей, и если там данные полнее, процитируют площадку.
Начинать надо с десяти позиций, которые дают выручку, а не с полного каталога. Замер делается до правок, повторяется через полтора-два месяца и считается по доле запросов, где магазин попал в ответ. Трафик из чатов на старте будет маленьким, и мерить результат по нему бесполезно.
Частые вопросы
С чего начать магазину на тысячу позиций?
С десяти товаров, дающих наибольшую выручку. По ним делается полный набор: атрибуты, назначение, сценарий использования, разметка Product с ценой и наличием, отзывы в HTML. Через полтора-два месяца - повторный прогон запросов по нейросетям и сравнение с исходным замером. Остальной каталог доводится шаблонами по типам товара, вручную тысячу карточек никто не осилит.
Нужна ли эта работа, если основные продажи идут на маркетплейсе?
Нужна, но приоритет другой. Если продажи на площадке, начинать надо с полноты карточки там: атрибуты, ответы на вопросы, отзывы. Системы читают маркетплейс охотно. Собственный сайт при этом остается местом, где вы контролируете данные и куда ведет цитата, если карточка на сайте полнее.
Помогает ли разметка, если магазин собран на конструкторе?
Помогает, если конструктор отдает цену и наличие в разметке, а потом обновляет их вместе с каталогом. Проверяется через валидатор структурированных данных: цена в коде должна совпадать с ценой на странице. Если платформа ставит разметку без цены или с устаревшим остатком, толку от нее мало.
Что делать с отзывами, если они в стороннем виджете?
Проверить, видны ли тексты в исходном коде страницы. Если нет, запросить у сервиса вывод отзывов в HTML - у части платформ есть такой режим или выгрузка. Когда режима нет, отзывы дублируются на страницу отдельным блоком с разметкой, а виджет остается для оформления и сбора новых.
Как понять, что работа дала результат?
Через прогон запросов. Берется набор из двадцати-тридцати формулировок покупателя, фиксируется, кто попал в ответ до работы, и замер повторяется через полтора-два месяца. Считается доля запросов, где магазин упомянут. Трафик и продажи здесь плохие индикаторы: переходов из нейросетей мало, а на выбор система влияет раньше клика.