Аудит B2B-сайта: формы, посадочные страницы и аналитика

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

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

Сильная коммерческая база не гарантирует получение заявок

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

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

Сайт сообщал об успехе до подтверждения сервера

В публичном JavaScript функция отправки запускала AJAX-запрос, а затем сразу очищала поля, закрывала окно и показывала сообщение об успешной отправке. Интерфейс не ждал положительного ответа сервера и не имел отдельной обработки сетевой или серверной ошибки.

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

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

Одинаковые ID могли смешивать разные формы

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

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

Битая коммерческая ссылка и слабый мобильный CTA

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

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

Где структура ограничивала SEO и AI-ответы

У основных страниц были title и canonical, robots.txt и sitemap.xml работали, а доменные варианты перенаправлялись на один адрес. При этом несколько коммерческих разделов не имели настоящего H1, часть meta description оставалась пустой, а в HTML description дублировался. У большинства изображений каталога и проектов отсутствовал осмысленный alt.

На проверенных страницах не было структурированных данных Organization/LocalBusiness, Service, Product, BreadcrumbList или FAQ. Разметка сама по себе не поднимет сайт в поиске, но помогает явно описать видимый контент. Для SEO и GEO важнее сначала добавить факты: состав услуги, регион работы, условия, этапы, сроки реакции, документы, сценарий расчёта и ответы на частые вопросы. Системный подход к таким страницам описан в хабе SEO и продвижение сайта.

Скорость: задержка до HTML и тяжёлые коммерческие страницы

Внешние замеры показали TTFB примерно 1,3–1,7 секунды. Главная и каталог аренды передавали браузеру около 2 МБ ресурсов, внутренние страницы — примерно 0,4–1 МБ. В тестовом профиле загрузка занимала около пяти секунд. Это диагностическая выборка, а не замена полевых Core Web Vitals.

Сайт использовал серверный PHP, jQuery и отдельный JavaScript-бандл. В заголовках раскрывалась устаревшая ветка PHP. Обновлять её без проверки совместимости нельзя: сначала нужны инвентаризация приложения, резервная копия и тестовая среда. Для скорости логично начать с серверного профилирования, затем проверить изображения первого экрана, сторонние подключения и загрузку нижних блоков.

Что исправлять в первую очередь

1. Сделать уникальными формы и их идентификаторы, сохранить услугу и страницу обращения.
2. Показывать успех только после подтверждённого ответа сервера; обрабатывать ошибки и не очищать данные преждевременно.
3. Провести согласованные тесты до почты или CRM и связать только успешные обращения с целями аналитики.
4. Исправить битую ссылку и добавить заметные мобильные CTA на ключевых направлениях.
5. После этого улучшать H1, descriptions, alt, коммерческие блоки, структурированные данные и скорость.

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

Что проверить на вашем сайте

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