Типовые проблемы сайтов на Битрикс: чек-лист для маркетолога

01

Почему сайты на Битрикс теряют результат незаметно

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

На сайте на 1С-Битрикс важно проверять не отдельную страницу, а пользовательский маршрут: рекламное объявление → посадочная страница → форма или корзина → CRM → ответственный менеджер → сделка или заказ → отчёт. Сбой на любом участке меняет цифры. Например, форма может отправлять письмо, но не создавать лид; CRM может принять лид, но не записать значение utm_campaign; менеджер может получить задачу через час, когда клиент уже выбрал конкурента.

Вторая группа рисков связана с изменениями. Редактор заменил шаблон формы, разработчик обновил модуль, интегратор изменил API CRM — и рабочая ранее связка перестала передавать поле телефона, согласие на обработку данных или состав заказа. Такие ошибки обнаруживают не в момент релиза, а по падению конверсии через недели.

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

03

Формы, CRM и UTM: первая зона проверки

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

Особое внимание — скрытым полям. При смене шаблона или подключении новой формы часто перестают передаваться utm_source, utm_medium, utm_campaign, referer, URL страницы и идентификатор рекламного клика. Если поля не сохранены в лиде или сделке, восстановить источник задним числом обычно нельзя. Не подменяйте проверку просмотром исходного кода: результат должен быть виден в карточке CRM и в отчёте.

Если используется Битрикс24, заранее определите сущность приёма: лид, сделка, контакт или заказ. Неоднозначная логика создаёт дубли и конфликты ответственности. Документацию по настройке CRM-форм и обработке обращений можно сверять в справочном центре Битрикс24, но бизнес-правила всё равно нужно описать отдельно.

04

Скорость, ошибки и каталог: что видит посетитель

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

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

Отдельно тестируйте товарные данные. Цена, остаток, наличие, свойства, изображения и статус доставки должны совпадать с согласованным источником. Если есть обмен с 1С или внешней системой, проверяйте не только успешный запуск обмена, но и конкретный товар после изменения. Ссылка на документацию по разработке и администрированию доступна на портале разработчиков 1С-Битрикс.

05

SEO и аналитика ломаются после обычных правок

Редизайн блока, перенос страницы или замена шаблона кажутся контентной задачей, но способны изменить поисковую видимость и аналитику. Страница может получить новый URL без 301-редиректа, исчезнуть из меню и sitemap, стать закрытой в robots.txt или получить повторяющиеся title и description. Для SEO важнее не наличие «оптимизации вообще», а сохранность индексации и посадочных страниц, на которые уже ведут реклама, ссылки и поисковый трафик.

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

Проверяйте доступность счётчиков после изменения шаблона и согласуйте единый словарь событий. Названия вроде form_submit_new и lead2 не объясняют бизнесу ничего. Лучше: lead_callback_success, lead_catalog_success, order_success. Это упрощает отчёты, аудит и передачу проекта между подрядчиками.

Если конверсия изменилась после релиза, сначала сверяют факт отправки обращения и события аналитики, а потом меняют рекламные ставки.

06

Как провести проверку без технического аудита на месяц

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

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

Не смешивайте дефекты, улучшения и новые идеи. Ошибка — заявка не дошла или цена неверна. Улучшение — добавить автозаполнение поля. Новая функция — сделать калькулятор. Разный тип задачи требует разного срока, бюджета и способа приёмки.

1. 1

   Выберите точки дохода. Соберите формы, корзину, номера телефонов, страницы услуг и товара с существенным трафиком.

2. 2

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

3. 3

   Пройдите путь пользователя. Проверьте сценарии на мобильном и десктопе, включая валидацию и повторную отправку.

4. 4

   Сверьте системы. Найдите лид или заказ в CRM и соответствующее событие в аналитике.

5. 5

   Зафиксируйте дефекты. Приложите URL, шаги, ожидаемый и фактический результат, время проверки.

07

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

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

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

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

08

Когда достаточно разовой доработки, а когда нужна поддержка

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

Регулярная поддержка нужна, когда сайт постоянно меняется: появляются рекламные кампании и посадочные, обновляется каталог, работают оплаты и доставки, идёт обмен с 1С, подключены CRM и сторонние API. Здесь ценность не в количестве часов, а в предсказуемом цикле: приём задач, приоритизация, тестирование, выпуск, контроль после релиза и понятный SLA. Такой формат помогает не копить мелкие проблемы до аварии.

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

09

С чего начать проверку сайта

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

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

Подключать подрядчика стоит, когда дефект затрагивает CRM, оплату, каталог, обмен с 1С, скорость или безопасность, а также когда нет доступа к настройкам и истории изменений. До начала работ согласуйте резервную копию, границы доработки и критерии приёмки. Так вы получите не просто исправленную страницу, а управляемый сайт, на котором маркетинговые показатели можно проверять по фактам.