Технический аудит сайта на 1С-Битрикс — подробный разбор и моя методика

Если сайт на 1С‑Битрикс стал медленным, сыплет ошибками или «падает» под нагрузкой — это не каприз сервера, а накопленные технические долги. Я провожу аудит, чтобы быстро найти узкие места, подтвердить их цифрами и дать понятный план исправлений без «воды» и формальных отчётов.

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

• Честная картина состояния проекта и рисков;
• Приоритизированный план: что чинить сначала, что можно отложить;
• Оценку влияния на скорость, стабильность и безопасность.

Почему технический аудит на Битриксе — это необходимость

Что будет, если его не делать

Снижение скорости работы сайта и падение позиций в поиске

Битрикс — мощная, но требовательная CMS. Со временем база данных разрастается, кэш засоряется, а скрипты начинают работать медленнее. В итоге страницы открываются не за секунды, а за 5–8 секунд. Поисковые системы учитывают скорость загрузки, и медленный сайт постепенно теряет позиции, даже если контент и ссылки в порядке.

Ошибки в модулях и функционале, мешающие клиентам оформлять заказы

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

Уязвимости в системе, через которые можно потерять данные или сайт

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

Неэффективная работа сервера, из-за которой вы переплачиваете за хостинг

Неправильная конфигурация PHP, MySQL, Apache или nginx приводит к избыточной нагрузке. Провайдер предложит «поднять тариф», хотя на деле достаточно оптимизировать окружение, чтобы сайт работал быстрее на том же хостинге.

Чем отличается аудит на Битриксе от других CMS

1С-Битрикс — не универсальный движок, а система с собственной архитектурой, модульной структурой и высокими требованиями к окружению. Поэтому аудит здесь требует специфических знаний и инструментов. Подход, который сработает на WordPress или OpenCart, в Битриксе может упустить критичные моменты.

Отличие от SEO-аудита

SEO-аудит фокусируется на контенте, семантике, структуре страниц и ссылках. Он полезен, но не выявит, например, что база данных работает без индексов, модуль кеширования отключён или PHP-версия устарела. Эти проблемы напрямую влияют на SEO, но не видны при обычной оптимизационной проверке.

Отличие от маркетингового аудита

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

Что входит в мой технический аудит

Проверка производительности

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

• Время отклика сервера (TTFB);
• Скорость генерации страниц PHP-скриптами;
• Эффективность кеширования компонентов и шаблонов;
• Потребление CPU и памяти под нагрузкой;
• Время загрузки в мобильной и десктопной версии.

Анализ кода и структуры сайта

Битрикс гибкий, но из-за этого в проектах часто появляются лишние модули, «захардкоженные» решения и изменения ядра, которые мешают обновлениям. Я проверяю, как организованы файлы, компоненты, шаблоны и модули, а также ищу фрагменты кода, которые вызывают лишнюю нагрузку или конфликтуют между собой.

• Поиск устаревших или конфликтующих модулей;
• Проверка структуры директорий и подключения шаблонов;
• Анализ кастомных доработок ядра и компонентов;
• Проверка корректности подключения CSS и JS;
• Анализ ошибок в логах (/bitrix/php_interface/dbconn.php, /bitrix/error.log и пр.).

Проверка безопасности

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

• Проверка актуальности версии ядра и модулей;
• Анализ установленных расширений на предмет уязвимостей;
• Проверка HTTPS и корректности SSL-сертификата;
• Оценка настроек прав пользователей и администраторов;
• Диагностика ошибок конфигурации, которые могут открыть доступ к системе.

Анализ хостинга и сервера

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

• Сравнение параметров сервера с официальными требованиями 1С-Битрикс;
• Проверка версии PHP, MySQL/MariaDB и настроек (memory_limit, opcache и т.д.);
• Анализ конфигураций nginx / Apache на предмет конфликтов и избыточных правил;
• Оценка скорости работы SSD/ NVMe-дисков и доступности серверных ресурсов;
• Проверка стабильности работы в пиковые часы нагрузки.

Таблица: что входит / что не входит

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

Входит в технический аудит	Не входит (отдельные задачи)
Диагностика скорости и производительности (TTFB, время генерации, кеширование).	Полное внедрение оптимизаций и рефакторинг кода.
Проверка версий ядра и модулей, совместимость обновлений.	Обновление ядра/модулей «под ключ» с регресс‑тестами.
Анализ кода компонентов и шаблонов на ошибки и узкие места.	Разработка новых компонентов и функционала.
Проверка безопасности: права, конфиги, уязвимые точки, HTTPS.	Настройка WAF/проактивной защиты и пентест.
Анализ окружения: PHP, MySQL/MariaDB, nginx/Apache, opcache.	Миграция на другой хостинг или перенос на VPS.
Проверка базы данных: индексы, типы таблиц, рост и фрагментация.	Оптимизация и перепроектирование схемы БД.
Проверка логов ошибок и журналов событий.	Фикс конкретных багов по задачам.
Оценка рисков и приоритизация исправлений.	UX/маркетинг‑аудит, копирайтинг, дизайн, SEO‑ссылки.

Что проверяется в техническом аудите на 1С-Битрикс — подробно

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

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

• Время до первого байта (TTFB) — показывает, как быстро сервер начинает отдавать ответ.
• Общее время загрузки страницы (Fully Loaded Time) — учитывает работу сервера, базы данных и фронтенда.
• Время загрузки мобильной версии — особенно важно, так как Google использует mobile-first индекс.
• Стабильность скорости под нагрузкой — проверяется стресс-тестами.

Нагрузка на CPU и память

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

• Мониторинг среднего и пикового использования CPU;
• Отслеживание объёма потребляемой RAM и swap-памяти;
• Выявление «тяжёлых» запросов к базе данных;
• Анализ фоновых агентов и крон-заданий, создающих нагрузку;
• Оценка влияния кеша и CDN на снижение нагрузки.

Поиск устаревших или конфликтующих модулей

В Битриксе модули — частый источник проблем. Старые версии не обновляются, а несовместимые модули могут «ломать» сайт или замедлять его работу. Я проверяю каждый установленный модуль и фиксирую, есть ли у него обновления и совместимость с вашей версией PHP и ядром.

• Сверяю версии ключевых модулей (main, iblock, catalog, sale, form, seo);
• Ищу дубликаты по функциям, например два SEO-модуля или несколько кеш-систем;
• Проверяю, не используют ли они устаревший код, удалённый в новых версиях;
• Отмечаю «замороженные» модули из Маркетплейса, у которых нет обновлений и поддержки;
• Смотрю обработчики событий (OnBeforeAdd, OnSaleOrder* и др.), которые могут замедлять сайт;
• Проверяю, не мешают ли модули композитному кешу.

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

// Вывод списка установленных модулей и их версий

// Получение списка установленных модулей с версиями из modules.php
use Bitrix\Main\ModuleManager;

$modules = ModuleManager::getInstalledModules();
$result = [];

foreach ($modules as $code => $desc) {
    $modulePath = $_SERVER["DOCUMENT_ROOT"] . "/bitrix/modules/{$code}/install/version.php";
    if (file_exists($modulePath)) {
        include($modulePath);
        $version = $arModuleVersion['VERSION'] ?? 'unknown';
    } else {
        $version = 'unknown';
    }
    $result[] = $code . ': ' . $version;
}

echo implode('
', $result);

Проверка кастомных доработок ядра

Кастомные доработки ядра 1С-Битрикс — это изменения в системных файлах платформы. При обновлении модуля или ядра такие правки часто затираются, что приводит к сбоям. В техническом аудите фиксируются все подобные изменения и их влияние на работу сайта.

• Сравнение оригинальных файлов ядра с текущими на сервере;
• Поиск изменений в файлах модулей и компонентов;
• Проверка переопределения системных классов и функций;
• Анализ ошибок, связанных с модифицированными файлами;
• Подготовка плана переноса изменений в отдельные модули.

# Пример проверки на изменения в ядре (Linux)
# Папка /bitrix/modules берётся из локального проекта, а original/ — из чистой версии той же редакции Битрикс
diff -r /var/www/site/bitrix/modules /var/www/original/bitrix/modules > core_changes.diff

# Результат будет в файле core_changes.diff — это список всех расхождений

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

Анализ ошибок в логах

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

• Проверка логов веб-сервера (nginx, Apache) на наличие 4xx и 5xx ошибок;
• Анализ системных логов PHP на предмет фатальных ошибок и предупреждений;
• Проверка журнала событий 1С-Битрикс;
• Поиск повторяющихся ошибок и определение их источника;
• Фиксация времени и частоты возникновения каждой проблемы.

# Просмотр последних 100 строк лога ошибок PHP
tail -n 100 /var/log/php_errors.log

# Поиск ошибок 500 в логе nginx
grep " 500 " /var/log/nginx/access.log

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

Проверка HTTPS и сертификатов

Наличие корректного SSL-сертификата защищает передачу данных и повышает доверие пользователей. Ошибки в настройке HTTPS могут блокировать работу сайта в браузерах.

• Проверка срока действия и типа сертификата (Let's Encrypt, коммерческий, wildcard);
• Проверка корректности цепочки сертификатов (intermediate и root CA);
• Анализ настроек шифрования — поддержка TLS 1.2 и 1.3, отключение устаревших протоколов;
• Проверка автоматического продления сертификата;
• Выявление смешанного контента (mixed content) на страницах.

# Проверка даты окончания сертификата
echo | openssl s_client -servername site.ru -connect site.ru:443 2>/dev/null | openssl x509 -noout -dates

При обнаружении проблем формируется список рекомендаций по их устранению: замена или продление сертификата, настройка HTTPS-редиректа, устранение смешанного контента.

Настройки доступа и прав пользователей

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

• Анализ групп пользователей и их прав в административной панели 1С-Битрикс;
• Проверка доступа к админке и системным разделам по IP или VPN;
• Выявление пользователей с избыточными правами (администратор, полный доступ);
• Проверка наличия неиспользуемых или устаревших аккаунтов;
• Оценка политик паролей и сроков их действия;
• Проверка, не доступны ли системные папки и файлы из внешней сети.

// Получение списка пользователей с правами администратора
use Bitrix\Main\UserTable;

$rsUsers = UserTable::getList([
    'select' => ['ID', 'LOGIN', 'EMAIL'],
    'filter' => ['GROUPS.GROUP_ID' => 1] // 1 — группа администраторов
]);

while ($user = $rsUsers->fetch()) {
    echo $user['LOGIN'] . ' (' . $user['EMAIL'] . ')
';
}

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

Проверка версии PHP и MySQL

Несовместимая версия PHP или MySQL может вызывать ошибки, сбои модулей и снижение скорости работы сайта. На этапе аудита фиксируются текущие версии и сравниваются с требованиями 1С-Битрикс.

• Сравнение версии PHP с официальными требованиями платформы;
• Проверка наличия обязательных расширений PHP: mbstring, intl, gd, zip и других;
• Определение версии MySQL или MariaDB и её совместимости с модулями сайта;
• Выявление устаревших параметров конфигурации;
• Подготовка рекомендаций по обновлению.

# Проверка версии PHP
php -v

# Проверка версии MySQL/MariaDB
mysql -V

# Список установленных PHP-расширений
php -m

Результат проверки — список необходимых обновлений и изменений конфигурации.

Компонент	Рекомендуемая версия	Минимально допустимая	Статус старых версий
PHP	8.1 / 8.2	7.4	7.3 и ниже — не поддерживаются
MySQL	8.0	5.7	5.6 и ниже — не поддерживаются
MariaDB	10.5+	10.3	10.2 и ниже — не поддерживаются

Анализ конфигурации сервера (nginx, Apache, PHP)

Конфигурация веб-сервера и PHP напрямую влияет на производительность и безопасность сайта. На этапе аудита фиксируются ключевые параметры и сравниваются с рекомендациями 1С-Битрикс.

• Проверка размера загружаемых файлов (upload_max_filesize, post_max_size);
• Анализ лимитов памяти (memory_limit);
• Проверка времени выполнения скриптов (max_execution_time);
• Настройка кеширования в nginx или Apache;
• Проверка заголовков безопасности (HSTS, X-Frame-Options, X-Content-Type-Options);
• Отключение ненужных модулей и функций PHP.

Параметр	Рекомендуемое значение	Описание
upload_max_filesize	64M+	Максимальный размер загружаемого файла
post_max_size	64M+	Максимальный размер POST-запроса
memory_limit	256M+	Объём памяти для выполнения скрипта
max_execution_time	120	Время выполнения одного скрипта (сек.)
opcache.enable	On	Включение кэширования PHP-кода

# Проверка конфигурации PHP
php -i | grep -E "upload_max_filesize|post_max_size|memory_limit|max_execution_time"

# Проверка конфигурации nginx
nginx -T

# Проверка конфигурации Apache
apachectl -M

Самопроверка: нуждается ли ваш сайт в техническом аудите?

Проблема / симптом	Отметить
Страницы сайта грузятся более 3 секунд
Ядро 1С-Битрикс не обновлялось больше года
Версия PHP ниже 8.0
Таблицы b_user_session / b_sale_fuser > 500 МБ
Композитный кеш и opcache отключены
Появляются ошибки 404 / 500 в логах
Есть кастомные правки файлов ядра Битрикс
Сайт ломается после попытки обновления
Хостинг предлагает перейти на тариф «подороже»
Не делалась профилактика сайта более 6 месяцев

Как я провожу технический аудит (моя методика)

Сбор исходных данных и резервная копия

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

Сохранение файлов сайта и базы данных

Фиксация версии PHP, MySQL, ядра Битрикс и модулей

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

• PHP — фиксируется номер и сборка (например, 8.1.21 cli или fpm). От версии напрямую зависит совместимость модулей и производительность.
• MySQL или MariaDB — проверяется номер версии и используемый движок. Старая версия может не поддерживать современные индексы и функции.
• Ядро Битрикс — записывается текущая сборка, например main 22.300.0.
• Список модулей — фиксируются все установленные решения с номерами версий для выявления тех, что требуют обновления или вызывают конфликты.

Сбор конфигурации сервера и параметров окружения

На этом этапе фиксируются все ключевые характеристики хостинга или сервера, на котором работает сайт. Это позволяет оценить, насколько текущее окружение соответствует требованиям 1С-Битрикс и планируемым нагрузкам.

• Веб-сервер — тип (nginx, Apache или связка nginx+Apache) и версия;
• PHP — используемый режим (FPM, CGI, mod_php) и параметры конфигурации (например, memory_limit, max_execution_time, opcache);
• База данных — MySQL или MariaDB, версия, используемый движок (InnoDB, MyISAM) и кодировка;
• Операционная система — версия и дистрибутив (например, Ubuntu 22.04, CentOS 7);
• Параметры окружения — расширения PHP, доступность cron-задач, конфигурация HTTPS.

Снятие метрик скорости работы до аудита

Перед началом любых изменений важно зафиксировать текущую скорость работы сайта. Это позволит сравнить показатели «до» и «после» и оценить реальный эффект от внедрённых доработок.

• Проверка загрузки страниц через Google PageSpeed Insights — отдельно для мобильных и десктопных версий;
• Измерение времени отклика сервера с помощью Pingdom Tools;
• Проверка показателя TTFB (Time To First Byte) в браузерной консоли или через сервис KeyCDN Performance Test;
• Фиксация данных по CLS, LCP, FCP для Core Web Vitals.

Анализ логов и ошибок

Логи веб-сервера (nginx, Apache)

На сервере сохраняются журналы запросов и ошибок. Для nginx это файлы access.log и error.log, для Apache — access_log и error_log. По ним определяют:

• страницы, вызывающие высокую нагрузку;
• ошибки 4xx и 5xx, отображаемые пользователям;
• IP-адреса с подозрительной активностью (сканирование, атаки, парсинг).

Для фильтрации записей используют команды:

grep "500" /var/log/nginx/error.log | tail -n 20
grep "404" /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

Системные логи PHP

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

• повторяющиеся предупреждения Deprecated и Notice;
• фатальные ошибки Fatal error и Parse error;
• проблемы с подключением к базе данных или внешним API.

Пример команды для поиска ошибок за последний час:

grep "PHP" /var/log/php_errors.log | tail -n 50

Журнал событий в админке Битрикс (Настройки → Инструменты → Журнал событий)

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

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

Повторяющиеся ошибки и их источники.

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

Например, регулярные ошибки 404 Not Found при обращении к одному и тому же файлу могут означать, что в шаблоне или модуле указан неверный путь к ресурсу:

[15-Aug-2025 10:12:45] 404 Not Found: /bitrix/templates/site/js/old-script.js
[15-Aug-2025 10:12:46] 404 Not Found: /bitrix/images/missing-logo.png

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

[15-Aug-2025 11:05:12] MySQL error: Table 'catalog_products' doesn't exist
Query: SELECT * FROM catalog_products WHERE active='Y'

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

В логах также нередко встречаются PHP-предупреждения, возникающие при определённых сценариях работы сайта:

[15-Aug-2025 12:18:07] PHP Warning:  Undefined array key "PRICE" in /home/user/www/bitrix/components/catalog/component.php on line 214

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

Проверка производительности и нагрузки

Встроенный модуль «Монитор производительности»

Модуль «Монитор производительности» в 1С-Битрикс используется для измерения скорости отклика страниц, нагрузки на сервер и выявления узких мест в конфигурации. Тест включает несколько вкладок: «Конфигурация», «Битрикс», «Разработка» и «Масштабируемость».

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

Результаты фиксируются перед началом оптимизации для последующего сравнения с обновлёнными показателями.

Пример данных, которые отображает модуль:

Производительность: 22.74
Среднее время отклика: 0.0388 сек
CPU: 174.1 млн операций/сек
MySQL (запись): 13 760 запросов/сек
MySQL (чтение): 13 154 запросов/сек

Время отклика страниц (desktop и mobile)

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

Пример метрик для одной страницы:

Тип устройства	First Contentful Paint (FCP)	Largest Contentful Paint (LCP)	Полная загрузка
Desktop	0.9 сек	1.8 сек	2.2 сек
Mobile	2.3 сек	4.1 сек	5.0 сек

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

Пиковая нагрузка на CPU и память

Измерение нагрузки на процессор и оперативную память проводится для определения стабильности сайта при повышенном трафике. Данные собираются через утилиты top, htop на сервере, встроенные панели мониторинга хостинга или специализированные системы (например, Zabbix, New Relic).

Пример фрагмента показателей при пиковой нагрузке:

top - 08:32:44 up 5 days,  4:22,  1 user,  load average: 3.12, 2.98, 2.65
Tasks: 142 total,   3 running, 139 sleeping,   0 stopped,   0 zombie
%Cpu(s): 78.4 us,  6.3 sy,  0.0 ni, 14.9 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :  7982.4 total,   845.3 free,  6231.5 used,   905.6 buff/cache
MiB Swap:  2048.0 total,   512.4 free,  1535.6 used. 

Если показатели CPU стабильно превышают 80%, а использование памяти приближается к максимальному, это сигнал о необходимости оптимизации кода, кеширования или расширения серверных ресурсов.

Аудит модулей и ядра

Список установленных модулей и их версий (Marketplace → Установленные решения)

Первый шаг в аудите ядра 1С-Битрикс — зафиксировать полный перечень установленных модулей и их версий. Это даёт понимание, какие из них устарели, требуют обновления или могут конфликтовать между собой. В админке список можно открыть по пути Marketplace → Установленные решения. Я всегда сохраняю этот перечень в отдельный файл, чтобы иметь «снимок» состояния перед оптимизацией.

• Фиксирую версии ключевых модулей (main, iblock, catalog, sale, seo, highloadblock);
• Отмечаю сторонние решения из Marketplace, у которых нет обновлений или поддержки;
• Выявляю дубликаты по функционалу — например, два разных модуля кеширования или SEO;
• Смотрю совместимость с текущей версией PHP и ядра;
• Формирую список кандидатов на отключение или замену.

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

Обновления ядра и модулей

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

• Сверяю текущую версию ядра (main) с последней стабильной на dev.1c-bitrix.ru;
• Проверяю каждый модуль из списка на наличие обновлений через Marketplace → Обновления решений;
• Анализирую список изменений (changelog) — отмечаю исправленные ошибки и улучшения, которые влияют на безопасность и производительность;
• Отдельно смотрю, не требуют ли обновления модули, связанные с оплатами и интеграциями;
• Фиксирую несовместимости — например, когда модуль работает только на PHP 7.4, а сайт планируется перевести на 8.1.

// Проверка доступных обновлений модулей в 1С-Битрикс
// Запускается из init.php или отдельного скрипта в /bitrix/admin/

use Bitrix\Main\Update\Stepper;
use Bitrix\Main\Update\UpdateController;

$controller = new UpdateController();
$updates = $controller->checkUpdates();

if (!empty($updates['MODULES'])) {
    foreach ($updates['MODULES'] as $moduleId => $moduleInfo) {
        echo $moduleId . ' — доступна новая версия: ' . $moduleInfo['VERSION'] . '<br>';
    }
} else {
    echo 'Все модули в актуальной версии';
}

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

Проверка кастомных правок в ядре

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

• Сравнение текущих файлов ядра с файлами из дистрибутива той же версии;
• Проверка каталога /bitrix/modules и системных компонентов на модификации;
• Выявление переопределённых классов и функций;
• Составление списка изменённых файлов с указанием цели изменения;
• Подготовка рекомендаций по переносу изменений за пределы ядра.

# Сравнение текущей версии ядра с оригинальной
# /var/www/site — рабочая копия
# /var/www/bitrix_clean — чистая установка той же версии
diff -r /var/www/site/bitrix/modules /var/www/bitrix_clean/bitrix/modules > core_changes.diff

# Файл core_changes.diff содержит список различий

Результаты оформляются в виде таблицы с перечнем изменённых файлов и рекомендациями по переносу.

Поиск конфликтов между модулями

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

• Проверка обработчиков событий (OnBeforeAdd, OnSaleOrder* и другие) на дублирование;
• Выявление модулей с одинаковыми функциями, например нескольких SEO-плагинов или систем кеширования;
• Анализ логов на наличие ошибок, вызванных взаимодействием модулей;
• Проверка совместимости модулей с текущей версией ядра и PHP;
• Составление перечня конфликтующих модулей и рекомендаций по их замене или отключению.

// Пример получения списка обработчиков события OnBeforeUserUpdate
use Bitrix\Main\EventManager;

$eventManager = EventManager::getInstance();
$handlers = $eventManager->findEventHandlers("main", "OnBeforeUserUpdate");

foreach ($handlers as $handler) {
    echo $handler["TO_MODULE_ID"] . " — " . $handler["TO_CLASS"] . "::" . $handler["TO_METHOD"] . "<br>";
}

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

Модуль	Конфликтует с	Описание конфликта	Возможное решение
Сторонний SEO-модуль	Встроенный модуль seo	Дублирует мета-теги и формирует несколько наборов данных для robots.txt.	Отключить один из модулей, оставить основной источник генерации мета-данных.
Сторонний модуль кеширования	Композитный кеш Битрикс	Разные алгоритмы кеширования вызывают устаревание данных или их дублирование в памяти.	Выбрать один механизм кеширования и отключить второй.
Модуль импорта товаров	Модуль каталога catalog	Изменяет обработчики событий OnBeforeProductUpdate, что блокирует обновления цен или остатков.	Настроить приоритет событий или вынести логику импорта в отдельный процесс.
Сторонний модуль оплаты	Модуль продаж sale	Несовместимость форматов данных приводит к ошибкам при проведении заказа.	Обновить модуль оплаты или использовать стандартный обработчик.
Модуль интеграции с CRM	Модуль highload-блоков	Изменяет структуру HL-таблиц, что вызывает ошибки при работе с другими модулями.	Согласовать структуру данных и обновить зависимости.

Проверка базы данных

Размер таблиц и индексов

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

Таблица	Данные (МБ)	Индексы (МБ)	Комментарий
b_sale_fuser	820	410	Неочищенные корзины пользователей за 5 лет
b_search_content	640	280	Старые записи полнотекстового поиска
b_event_log	520	150	История событий без архивирования

Большая часть этих данных не используется в повседневной работе. После очистки и перестройки индексов общий объём базы снизился с 6,4 ГБ до 3,1 ГБ, а среднее время выполнения сложных запросов — с 0,45 до 0,19 секунды.

Оптимизация и устранение фрагментации

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

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

Таблица	Размер до (МБ)	Размер после (МБ)	Изменение
b_user_session	933	715	-23%
b_search_content	8,27	6,14	-26%

Выполнить оптимизацию можно через административную панель хостинга или в консоли базы командой:

OPTIMIZE TABLE b_user_session;

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

Проверка кодировки и collation

Несогласованная кодировка и collation в базе данных приводят к ошибкам при сортировке, поиске и сохранении данных. В проектах на 1С-Битрикс это встречается, если сайт переносили с одного сервера на другой или обновляли MySQL без приведения схемы к единому стандарту.

Чаще всего встречается комбинация UTF-8 и cp1251: часть таблиц хранит данные в UTF-8, а часть — в cp1251. При запросах к таким таблицам символы отображаются некорректно, а индексы работают медленнее. Отдельная проблема — разные collation внутри одной базы (например, utf8_general_ci и utf8_unicode_ci), из-за чего сортировка по алфавиту даёт неожиданный порядок.

Во время аудита я проверяю:

• Единую кодировку для всех таблиц и столбцов;
• Соответствие collation требованиям проекта (для русского языка — utf8mb4_unicode_ci или utf8_unicode_ci);
• Отсутствие смешанных кодировок в одной базе;
• Правильную кодировку соединения PHP с базой.

Если выявлены несоответствия, планируется миграция на единую схему кодировки и collation. Для Битрикса на новых проектах используется utf8mb4 с поддержкой Emoji и расширенных символов. Изменения проводят только после полного бэкапа, так как смена кодировки затрагивает все данные в таблице.

Использование highload-блоков

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

В ходе аудита я проверяю:

• Количество и назначение всех созданных HL-блоков;
• Объём данных в каждом блоке и частоту запросов к нему;
• Наличие необходимых индексов по полям, которые участвуют в фильтрации и сортировке;
• Корректность связей между HL-блоками и другими сущностями сайта.

Итоговый отчёт и рекомендации

PDF-документ с перечнем проблем и приоритетами исправлений

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

Таблица критичности ошибок

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

• Критично — влияет на работоспособность или безопасность, требует срочного исправления;
• Средний приоритет — снижает производительность или удобство, но не блокирует работу;
• Низкий приоритет — косметические замечания, которые можно реализовать при плановом обновлении.

Проблема	Приоритет	Описание
Отключён композитный кеш	Критично	Снижает скорость загрузки страниц в 2–3 раза
Разные collation в таблицах БД	Средний	Может вызвать ошибки поиска и сортировки
Отсутствует индексация в HL-блоке	Низкий	Увеличивает время ответа фильтра на 1–2 секунды

Предложения по улучшению производительности, безопасности и стабильности

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

1. Производительность — оптимизация кеша, обновление PHP, настройка CDN (в последних обновлениях битрикс отключен);
2. Безопасность — актуализация SSL-сертификатов, настройка прав доступа, закрытие уязвимостей;
3. Стабильность — мониторинг логов, резервное копирование, тестирование обновлений на стенде.

Примеры аудитов, которые я делал

Кейс 1: Было / Сделал / Стало

Было: корпоративный сайт на Битрикс, время загрузки главной — 7,8 сек, 4 000+ ошибок 404 в логах, таблица b_user_session — 1,1 ГБ, композитный кеш отключён.

Сделал: очистка базы, оптимизация таблиц, включение кеширования, настройка nginx+PHP-FPM, удалены сломанные компоненты, добавлены индексы в HL-блоках.

Стало: загрузка — 1,9 сек, логи чистые, ядро актуализировано, сайт выдерживает нагрузку 300+ одновременных пользователей.

Кейс 2: Было / Сделал / Стало

Было: интернет-магазин, падающий в пиковые часы. Таблица b_sale_fuser — 850 МБ, обновления модулей не устанавливались 3 года, сессии не чистились, дедупликация не проводилась.

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

Стало: скорость каталога выросла в 3 раза, падения в чёрную пятницу не зафиксировано, полное внедрение рекомендаций за 14 дней.

Кейс 3: Было / Сделал / Стало

Было: сайт услуг, медленная админка (загрузка списка заявок — 40 сек), highload-блоки на 300 000 записей без индексов, PHP 7.1, избыточные сторонние модули.

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

Стало: админка открывается за 4 сек, нагрузка CPU снизилась на 60 %, внедрена регулярная профилактика базы и автоматическое бэкапирование.

Что вы получите после аудита

Подробный PDF-отчёт с приоритетами исправлений

Вы получите структурированный документ, в котором по каждому выявленному узкому месту указано:

• где находится проблема (модуль, таблица, компонент, настройка);
• как эта проблема влияет на скорость, безопасность или стабильность;
• пошаговая инструкция, как устранить её без риска поломки сайта;
• приоритет: срочно, планово, по желанию.

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

Таблица критичности найденных проблем

Проблема	Приоритет	Влияние	Рекомендуемое действие
Уязвимость из-за устаревшей версии ядра	Срочно	Высокий риск взлома и потери данных	Обновить ядро с сохранением резервной копии
Таблица b_user_session > 900 МБ	Срочно	Замедляет генерацию страниц, создаёт нагрузку на CPU	Очистить записи старше 30 дней + оптимизировать
Отключён композитный кеш	Средний	Страницы грузятся в 2–3 раза дольше	Включить кеширование с тестом на стенде
Смешанные collation в MySQL	Средний	Непредсказуемая сортировка и ошибки поиска	Привести все таблицы к utf8_unicode_ci
Модули из Marketplace без обновлений >2 лет	Низкий	Угроза несовместимости при обновлении ядра	Заменить или удалить при плановом refactoring’e

Рекомендации по улучшению производительности, безопасности и стабильности

Для повышения производительности:

• включить композитный и opcache-кеш;
• обновить PHP до версии 8.1+;
• перенести тяжёлые highload-блоки на отдельный сервер или выделенный кеш-слой;
• настроить автоматическую очистку базы (сессии, логи, корзины).

Для повышения безопасности:

• обновить все модули ядра до актуальных версий;
• закрыть админку по IP или VPN;
• включить двухфакторную аутентификацию для администраторов;
• перейти на SSL-сертификат с автоматическим продлением (Let’s Encrypt).

Для повышения стабильности:

• выделить стенд для тестирования обновлений и рефакторинга;
• настроить ежедневные резервные копии базы и файлов;
• подключить мониторинг ключевых метрик (CPU, RAM, TTFB, Web Vitals);
• завести регламент технического обслуживания раз в 3–6 месяцев.

Возможность заказать внедрение исправлений

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

Личный опыт из практики

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

В ходе аудита выяснилось:

• ядро 1С-Битрикс было кастомизировано «вручную» — сотни изменений в системных файлах;
• несколько модулей Marketplace встроены в код без возможности стандартного обновления;
• при попытке обновить сайты до PHP 8.1 и новой версии ядра полностью ломалась корзина, оформление заказов и синхронизация с 1С;
• highload-блоки использованы не по назначению — вместо нормализованной структуры БД.

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

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

Сколько стоит технический аудит на 1С-Битрикс

Стоимость

Цена зависит от размера проекта, количества модулей, объёма базы данных и сложности интеграций. Для небольших корпоративных сайтов — от 18 000 ₽, для интернет-магазинов и порталов с highload-нагрузкой — от 45 000 ₽. После первого контакта я оцениваю проект и фиксирую стоимость в договоре — без «плавающих» доплат в процессе.

Сроки

Стандартный аудит занимает от 2 до 7 рабочих дней, в зависимости от загрузки сервера, скорости предоставления доступов и объёма данных. Для критичных проектов с нагрузкой (например, интернет-магазин на распродаже) возможен экспресс-аудит за 24 часа с коротким чек-листом и рекомендациями по «горячим» фиксам.

Ответы на частые вопросы (FAQ)

Нужно ли давать доступ к админке сайта?

Да. Аудит проводится через административную часть Битрикс и инструменты диагностики, поэтому необходим доступ как минимум к разделам «Настройки», «Marketplace» и «Инструменты».

Можно ли провести аудит без остановки работы сайта?

Да. Диагностика не влияет на посетителей и не требует вывода сайта из эксплуатации — все проверки выполняются в «читающем» режиме.

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

От 2 до 7 рабочих дней в зависимости от объёма проекта. Есть экспресс-аудит за 24 часа с коротким отчётом по критичным проблемам.

Что входит в PDF-отчёт?

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

Нужно ли предоставлять доступ к базе данных?

Желательно. Анализ таблиц и индексов позволяет найти фрагментацию, устаревшие записи, ошибки collation и определить, какие данные замедляют сайт.

Можно ли сразу после аудита заказать внедрение исправлений?

Да. По желанию я могу не только составить план, но и полностью реализовать все доработки по отчёту «под ключ».

Помогает ли аудит ускорить скорость работы сайта?

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

Имеет ли смысл проводить аудит, если планируется редизайн?

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

Полезные ссылки и файлы из статьи

Бонус: как сделать технический аудит понятным и полезным для заказчика

1. Термины и сокращения поясняются простыми словами (cron, HL-блок, opcache и т.д.).
2. Скриншоты должны быть читаемыми в окне браузера шириной до 50 %.
3. Документ содержит оглавление, чёткие заголовки и нумерацию страниц.
4. У каждой найденной проблемы есть конкретная рекомендация по устранению.
5. Если ошибок не обнаружено — это фиксируется в отчёте.
6. В начале выводятся выводы по скорости, отказам и безопасности — как ключевым метрикам.
7. На первой странице указана дата и месяц проведения аудита.

Заключение

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