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

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

Задача бизнеса и границы решения

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

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

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

Что зафиксировать до сравнения: входные данные проекта

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

• Типы страниц и их количество: сколько будет шаблонных страниц, сколько уникальных, есть ли разделы с фильтрами и поиском.
• Объём и характер контента: тексты, изображения, документы, видео, таблицы характеристик.
• Кто и как часто редактирует: один маркетолог, три менеджера, внешний подрядчик.
• Интеграции: учётная система, CRM, платёжные сервисы, службы доставки, рассылки, аналитика.
• Данные и доступы: какие сведения будут храниться, кто их видит, как выдаются и отзываются права.
• Требования к переносу: что должно переехать со старого сайта и в каком виде.
• Бюджет владения: не только запуск, но и поддержка, обновления, доработки, хостинг.
• Сроки и точки контроля: когда нужен рабочий сайт и что считается промежуточным результатом.

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

Границы платформ и собственного кода

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

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

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

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

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

Редактирование контента и переносимость

Две вещи, которые чаще всего недооценивают при выборе, — это ежедневное редактирование и переносимость данных.

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

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

Отдельная тема — доступы. Их должно быть возможно выдать и отозвать, а не «передать логин по наследству». Порядок работы с доступами, данными и настройками стоит описать заранее, чтобы при смене сотрудника сайт не остался без управления; подробнее об этом — в материале про администрирование сайта на Битрикс — доступы, данные и настройки.

Матрица сценариев выбора

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

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

Учебный пример: как выбрать между Битрикс и Тильдой

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

Входные условия. Компания «Пример» производит мебель и продаёт её оптом и в розницу. Штат — около 40 человек, из них три менеджера по продажам и два сотрудника, которые будут вести сайт. Каталог — около 1200 позиций, характеристики обновляются из учётной системы. Нужны: каталог с фильтрами, форма заявки, раздел с документами для партнёров, блог с новостями, обмен данными с учётной системой. Онлайн-оплата на первом этапе не нужна, личный кабинет — во втором.

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

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

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

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

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

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

Роли и ответственность в проекте

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

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

Последний пункт часто существует только на бумаге. Проверка здесь одна: восстановление на тестовом контуре. Если восстановление ни разу не проводилось, считать, что копии есть, нельзя; порядок хранения и восстановления описан в материале про резервное копирование сайта на Битрикс — хранение и восстановление.

Как проверить результат и принять работу

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

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

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

Типичные ошибки и ограничения

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

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

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

Ошибка четвёртая — один человек знает все доступы. Это риск и для безопасности, и для непрерывности работы.

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

Ошибка шестая — ожидание, что конструктор заменит разработку, а «тяжёлая» платформа сама решит задачи бизнеса. Ни то, ни другое не работает без постановки задачи и ответственного.

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

Чек-лист перед решением

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