Аудит сайта на Битриксе: 5 узких мест, из-за которых теряются заявки

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

почему сайт на Битриксе тормозит, когда растёт каталог и трафик

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

Проблема почти всегда не в одном месте, а в связке трёх вещей. Композитный кеш Битрикса либо выключен, либо сброшен неправильным хуком в кастомном модуле — и тогда каждая страница собирается заново из базы при любом визите. PHP-FPM на сервере держит пул в четыре-восемь воркеров, а в момент выгрузки прайса и наплыва покупателей запросы встают в очередь. К этому добавляется прямой SQL-запрос в шаблоне карточки товара, который не использует индекс и на каждой загрузке сканирует таблицу остатков целиком.

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

как исправить медленную генерацию страниц и дубли в индексации

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

композитный кеш и лишние запросы к базе

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

дубли страниц, robots.txt и sitemap

Дубли в индексе Яндекса и Google на Битриксе чаще всего появляются из-за фильтров каталога: каждая комбинация «цвет плюс размер плюс сортировка» генерирует свой адрес, и поисковик индексирует их как отдельные страницы, размывая вес между копиями одного и того же товара. Аудит сверяет карту сайта с реальной структурой урлов, проверяет canonical-теги на страницах фильтров и смотрит, не открыты ли для индексации служебные разделы вроде панели администратора или папки с временными файлами.

мобильная вёрстка и скорость отрисовки

Отдельная категория жалоб — сайт нормально выглядит на ноутбуке дизайнера, но на телефоне покупателя кнопка добавления в корзину съезжает под фиксированное меню, а карточка товара дольше прорисовывается из-за тяжёлых изображений без сжатия. Такие вещи не видны в кабинете вебмастера — только при живом просмотре на нескольких реальных устройствах и разрешениях. Аудит фиксирует конкретные экраны, на которых вёрстка ломается, а не общую формулировку «сайт адаптивный».

Ниже — типовые симптомы, которые встречаются на Битрикс-сайтах при аудите, и что за ними обычно стоит.

что делать, если ошибка повторяется после каждого обновления модулей

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

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

Если ошибка возвращается раз за разом, разбираться нужно не с симптомом, а с тем, как устроен деплой. Нужна тестовая копия сайта, на которой каждое обновление проверяется до переноса на продакшен, версионирование кода в системе контроля версий вместо правок прямо на боевом сервере, и правило, обязательное для всех, кто пишет код: любая доработка идёт через local-модуль или обработчик события, а не через правку файлов из комплекта поставки. Аудит фиксирует все места, где кастомный код трогает ядро, и выдаёт список конкретных правок, которые нужно перенести в безопасный формат до следующего планового обновления — иначе история повторится в третий и четвёртый раз, и каждый раз это будет заново потерянная неделя на поиск причины.

как предотвратить потерю заявок из-за открытой админки и старых компонентов

Административная панель Битрикса у части сайтов доступна без ограничения по IP-адресу и без второго фактора авторизации — такой путь находится за несколько минут перебором стандартных адресов. Добавьте сюда модуль, который не обновлялся два-три года и содержит уязвимость из открытых бюллетеней безопасности «1С-Битрикс», и получите сайт, который могут скомпрометировать раньше, чем менеджер заметит первую подозрительную заявку в CRM.

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

Отдельная зона риска — формы, которые собирают персональные данные: телефон, почту, иногда паспортные данные для оформления рассрочки, — но передают их по каналу без шифрования или хранят в логах без ограничения доступа. Это вопрос не только технической безопасности, но и соответствия требованиям 152-ФЗ о персональных данных: при проверке или жалобе клиента отсутствие защищённого канала передачи станет отдельной проблемой, помимо самой утечки.

Что снижает риск заранее:

• ✓ограничить доступ к панели администратора по IP-адресу или через VPN
• ✓обновлять модули по графику, а не по факту поломки
• ✓включить двухфакторную авторизацию для всех администраторов
• ✓проверять формы на предмет незашифрованной передачи персональных данных

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

сколько стоит аудит сайта на Битриксе и что входит в проверку

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

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

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

❓ Частые вопросы

Что показывает аудит сайта на Битриксе, чего не видно в Яндекс.Метрике?

Метрика показывает, что посетитель ушёл со страницы, но не объясняет почему. Аудит разбирает причину на техническом уровне: включён ли композитный кеш, есть ли дубли в индексе, отвечает ли сервер под нагрузкой — и даёт список конкретных настроек и файлов для правки, а не общий совет «ускорьте сайт».

Сколько времени занимает аудит сайта на Битриксе?

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

Можно ли ускорить сайт на Битриксе без переезда на другой хостинг?

Часто да: половина тормозов на Битриксе — это выключенный композитный кеш, неоптимизированные запросы в кастомных компонентах и раздувшийся список исключений из кеша. Аудит показывает, что чинится на месте своими силами, а что действительно упирается в ресурсы сервера.

Как часто нужно проводить аудит сайта на Битриксе?

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

Аудит сайта проверяет только скорость и индексацию или ещё безопасность?

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