Ошибки при разработке сайта на Битрикс, которые дорого исправлять

Большинство проблем сайтов на Битриксе — это не баги «движка», а ошибки разработчика, заложенные в основу. Многие из них дёшево исправить на старте, но через год переделка стоит как половина нового проекта. Разберём самые частые и самые дорогие.

1. Доработки в ядре Битрикса

Любая правка файлов в /bitrix/modules/ или ядре компонентов — это «бомба замедленного действия». При первом же обновлении правки исчезнут, и сайт сломается.

• Правильно: копировать компонент в /local/components/ и менять там.
• Использовать события (EventManager) для подмены поведения.
• Переопределять шаблоны компонентов через /local/templates/.

2. Игнорирование папки /local/

Папка /local/ создана как раз для всей кастомной разработки. Если её игнорировать и складывать всё в /bitrix/templates/, апгрейд платформы превращается в хаос.

3. Бесконечные include_areas

Битрикс позволяет вставлять «области» с произвольным контентом прямо в шаблон. Удобно для редактора, но если их сотни — сайт превращается в неподдерживаемое болото.

• Используйте инфоблоки и сущности highload вместо include_areas для повторяющегося контента.
• Структурированные данные легче переносить, искать, экспортировать.

4. Прямые SQL-запросы вместо API

Иногда разработчики «срезают» через прямой SELECT к БД. Это ломается при миграции, апгрейде, смене структуры таблиц.

• Правильно: использовать D7 ORM (CIBlockElement::GetList → Bitrix\Iblock\ElementTable).
• Использовать кэшируемые методы.

5. Отсутствие кэширования

Сайт «летает» при разработке (5 товаров в каталоге) и умирает на проде (5000 товаров). Причина — отсутствие кэша компонентов.

• Включайте кэш компонентов всегда, кроме случаев с динамическим контентом.
• Используйте теги кэша для точечной инвалидации.
• Включите Composite-кэш на главной и страницах каталога.

Каждый компонент без кэша — это +50–200 мс к ответу страницы. На сайте с десятком компонентов это превращается в секунды и «тормоза» под нагрузкой.

6. Самописная авторизация

Иногда «очень опытные» разработчики делают свою систему пользователей вместо стандартной. Через год это ломает интеграции с CRM, личные кабинеты, разграничение прав.

• Используйте стандартный модуль main → пользователи и группы.
• Расширяйте через User Fields, не делайте отдельные таблицы.

7. Отсутствие миграций

Все изменения структуры (новые инфоблоки, поля, права) делаются через админку и нигде не фиксируются. При выкате на прод приходится повторять руками — и забывать половину.

• Используйте модуль миграций (sprint.migration, arrilot.bitrix-migrations).
• Каждое изменение структуры — миграция в Git.

8. Нет Git и тестового контура

Правки делаются прямо на проде через FTP. Любая ошибка — отвал сайта в продакшене. Откатиться невозможно.

• Git обязателен для любой разработки.
• Минимум 2 контура: dev и prod, лучше 3 (dev, staging, prod).
• CI/CD для автодеплоя.

9. Игнор адаптива

В 2026 году 60–70% трафика — мобильный. Сайт без адаптива теряет половину клиентов и проседает в поиске.

10. Нет логирования и мониторинга

• Ошибки скрыты от пользователя, но и от разработчика.
• Письма не уходят, а никто не знает.
• Решение: отдельный лог ошибок (журнал событий), мониторинг (Sentry, Zabbix).

Стоимость переделки

Итог

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