B2B-каталог теряет товар по пути к заявке: разбор ошибок

Разбор нескольких B2B-каталогов: где теряется выбранный товар, почему формы не передают контекст и как исправить путь до заявки.

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

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

Ссылка из категории вела не на товар, а на 404

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

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

Карточка показывала характеристики, но не предлагала запрос по товару

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

Общая форма обратного звонка с одним телефоном не решает эту задачу. Из открытого HTML нельзя подтвердить, что форма автоматически передаёт название и адрес выбранной позиции. Без доступа к письму или CRM нельзя утверждать, что менеджер получает контекст товара.

Рабочая заявка B2B-каталога должна передавать как минимум:

• название или идентификатор позиции;
• URL карточки;
• нужный объём, фасовку или существенный параметр заказа;
• контакт и удобный способ ответа;
• источник и страницу отправки для аналитики.

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

Поиск был виден, но не передавал запрос

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

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

Мобильная версия убирала контакт в момент выбора

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

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

Почему sitemap и canonical связаны с тем же маршрутом

Путь пользователя и путь поискового робота расходились похожим образом. На одном сайте robots.txt отсутствовал при рабочей XML-карте, на другом robots.txt ссылался на адрес карты, который возвращал 404. Ещё в одном случае версии домена с www и без www открывались самостоятельно, часть внутренних ссылок использовала HTTP, а canonical отсутствовал.

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

Для каталога нужно проверить:

• один основной HTTPS-хост и постоянные редиректы с остальных вариантов;
• одинаковые канонические адреса во внутренних ссылках, canonical и XML-карте;
• рабочий адрес sitemap в robots.txt;
• отсутствие в карте 404, закрытых и служебных URL;
• прямые ссылки из категории на конечные карточки без лишних переходов.

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

Аналитика не должна считать ошибку заявкой

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

Это вывод по открытому коду, а не подтверждение потери реальных заявок. Для окончательной проверки нужны тестовая отправка, доступ к почте или CRM и сопоставление события с фактическим обращением.

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

Что показал контрольный замер скорости

В тестовых браузерных профилях главная одного из каталогов загружалась примерно за 14–21 секунду, тогда как несколько внутренних страниц — примерно за 1–2 секунды. На главной использовался большой переключающийся первый экран и сторонние запросы.

Этот замер нельзя переносить на всех посетителей или автоматически объяснять сервером. Два запроса к сервисам Яндекса в тестовом маршруте получили ошибки сертификата, поэтому они не были приписаны сайту. Результат — основание отдельно проверить изображения первого экрана, сетевые запросы и полевые Core Web Vitals.

Устаревший стек обновляют только с планом отката

Один из публичных ответов сервера раскрывал давно неподдерживаемую версию PHP; на страницах также оставались старые frontend-плагины и ошибочные запросы к внешним ресурсам. Это не доказывает наличие уязвимости, но требует инвентаризации.

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

Приоритет исправлений

1. Проверить маршрут «категория → карточка → форма» и исправить ссылки, ведущие на 404.
2. Добавить действие по выбранному товару и передавать его название и URL в заявку.
3. Подтвердить успешную доставку тестовой заявки в почту или CRM.
4. Починить поиск и проверить фильтры на реальных сценариях подбора.
5. Вернуть главное действие и контакты в мобильную карточку.
6. Свести редиректы, canonical, внутренние ссылки, robots.txt и sitemap к одному набору адресов.
7. Разделить успешные заявки и ошибки в аналитике.
8. После исправления критического пути проверить скорость и безопасно обновлять стек.

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

Публичная проверка не позволяет утверждать, что заявка не приходит менеджеру, CRM теряет товар, реклама настроена неправильно или конкретная ошибка уже снизила продажи. Для таких выводов нужны доступы и тестовые обращения.

Материал фиксирует только наблюдаемые признаки: адреса и ответы страниц, элементы интерфейса, открытый HTML, публичные файлы robots/sitemap и ограниченные внешние замеры.

Когда нужен аудит или доработка B2B-каталога

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

Я могу проверить категории, карточки, поиск, формы, мобильную версию, индексирование и аналитику, а затем составить приоритетный план доработок. Условия комплексной проверки собраны на странице аудита сайта, работы с категориями и карточками — на странице сайта-каталога и интернет-магазина, а исправление форм и маршрута обращения — на странице доработки сайта.