Сайт на 1С-Битрикс "вроде работает", но каждая "мелочь" снова бьёт по бюджету и нервам: фильтр, корзина, страх обновить ядро. Доработка сайта битрикс или сделать с нуля - не вопрос вкуса, а развилка денег и риска. Ниже - decision framework за один час: чек-лист техдолга, экономика года и SEO-план с 301, чтобы зафиксировать одно решение в ТЗ или КП без месяцев откладывания.
Доработка сайта на "1С-Битрикс: Управление сайтом" - изменения уже работающего проекта (шаблон, компоненты, интеграции, скорость) без смены фундамента. Новая разработка с нуля - новый шаблон или архитектура и перенос контента/URL, когда техдолг и страх обновлений делают точечные правки дороже чистой базы. Сегодня пройдите диагностику: боль бизнеса → снимок техсостояния → red flags → смета года vs ориентир нового проекта. Результат - одна фраза в ТЗ: "дорабатываем на staging" или "новый проект + карта URL/301".
Речь только про CMS "1С-Битрикс: Управление сайтом" на вашем хостинге. Это не Bitrix24 (CRM) и не облачный портал - другой продукт. Обновление платформы через SiteUpdate - отдельная тема (см. обновление сайта на Битрикс); абонентская поддержка - тоже другая развилка (организация поддержки, что входит в техподдержку). Здесь - выбор: чинить текущий проект или пересобирать.
Что такое доработка сайта на Битрикс и когда она уместна
Доработка - правки на живом фундаменте: шаблон, компоненты, формы, каталог, скорость, интеграции. Новая разработка или глубокая пересборка - новый каркас (часто новый шаблон/архитектура), перенос контента и URL, иногда смена подхода к ЧПУ. Редизайн на текущем проекте уместен, если структура и код живы; новый сайт - если меняются информационная архитектура, ядро/PHP-база или бизнес-модель.
Делайте: сначала назвать цель в деньгах и заявках, не "хочу красивее". Не делайте: смешивать SiteUpdate (патчи безопасности и модулей) с решением "переделать сайт".
Зафиксируйте боль бизнеса за 15 минут
На практике владелец магазина третий раз за квартал платит за "мелкую" доработку фильтра, а после прошлой правки на сутки отвалилась корзина. Типичная ошибка - снова согласиться на "ещё чуть-чуть", не записав боль. Пока боль не зафиксирована, подрядчик всегда предложит латать. За 15 минут ответьте письменно:
- Что ломает продажи прямо сейчас: скорость, мобильный UX, фильтр, корзина, формы, обмен с 1С?
- Сколько раз за квартал уже платили за "мелкую" правку по той же зоне?
- Был ли простой после прошлой доработки (корзина, оплата, каталог)?
- Какой результат нужен через 90 дней: быстрее чекаут, новый сценарий, меньше ручных правок?
- Что точно out of scope: смена CMS, облачный конструктор сайтов, "просто поменять цвета"?
Делайте: боль в рублях и сценариях. Не делайте: стартовать с макета, пока не ясно, что чинить.
Снимите снимок техсостояния до сметы
Без снимка вы покупаете часы вслепую. Минимум перед КП:
- Версия PHP и ядра CMS, дата последнего успешного SiteUpdate.
- Есть ли staging-копия (отдельный стенд) и Git, или правки только на проде.
- Есть ли правки прямо в ядре `/bitrix/` вместо кастома через API/компоненты.
- Документирован ли чужой код: readme, доступы, кто делал шаблон.
- Критичные интеграции: 1С, оплата, CRM - где "тонкие места".
SiteUpdate в админке - система обновлений продукта и модулей, не "новый сайт". Если команду трясёт от кнопки обновления, это сигнал техдолга, а не повод ещё раз "подкрутить фильтр" на проде. Например, правки прямо в ядре `/bitrix/` делают каждое обновление лотереей. Норма отрасли - работы на копии до прода: так вы проверите сценарий до оплаты часов на проде.
Делайте: аудит обновляемости до оплаты часов. Не делайте: соглашаться на правки ядра "потому что так быстрее".
Пройдите red-flag чек-лист: дорабатывать или пересобирать
Отметьте "да/нет". При трёх и более "да" планируйте пересборку, а не очередной хотфикс:
- Поддержка и аварийные правки съедают бюджет развития.
- "Простые" вещи (кнопка, фильтр, блок) внезапно на полсайта.
- Сайт тормозит, а точечная оптимизация уже не помогает.
- Боитесь обновлять ядро / модули (страх SiteUpdate).
- Мобильный UX устарел так, что теряете заявки с телефона.
- В шаблонах костыли: SQL и хаки вместо нормальных компонентов - техдолг удорожает сопровождение.
- Нет доступов/документации к чужому коду, правки в ядре.
Рабочий поток: боль → снимок → red flags (≥3 "да"?) → экономика → вариант доработка | пересборка → фраза в ТЗ.
Делайте: считать флаги честно с подрядчиком. Не делайте: игнорировать страх обновлений как "привычку команды".
Сравните экономику: год латания vs смета нового проекта
Что дешевле - доработка или с нуля? Считайте год вперёд, не счёт за прошлую неделю. Практическая эвристика из отраслевых гайдов: если сумма поддержки и доработок за 12 месяцев больше примерно половины ориентира сметы нового проекта, перезапуск часто выгоднее бесконечного латания. Добавьте буфер на SEO-переезд (карта URL, 301, тесты).
| Критерий | Доработка / редизайн на текущем | Новая разработка / пересборка |
|---|---|---|
| Когда выбирать | Код и структура живы, 0–2 red flags | ≥3 red flags или смена IA/бизнес-модели |
| Бюджет | Часы по пулу задач + риск "всплытий" | Фикс/этапы сметы + буфер SEO |
| Срок до эффекта | Быстрее по точечным фичам | Дольше, но чище база для роста |
| Риск SEO | Ниже, если URL не трогают | Управляем картой URL + 301; риск высок без редиректов |
| Простой | Минимален при staging | Cutover после тестов на копии |
| Интеграции | Чиним точечно | Переносим и регрессионно тестируем |
Типовой магазин часто закрывается готовым решением и доработками поверх; "с нуля" оправдан при нестандартной логике. Ориентиры бюджета запуска - в материале сколько стоит сайт на Битрикс, без подмены этой статьи полной сметой.
Делайте: таблицу "год spend vs ориентир нового" в Excel до подписи КП. Не делайте: выбирать сценарий по эмоции после одного счёта.
Выберите сценарий и защитите SEO: staging, URL map, 301
Если сценарий "доработка"
- Составьте пул задач только на staging.
- Запретите правки ядра; кастом - через компоненты и штатные точки расширения.
- Критерий приёмки: после правки критичный сценарий (корзина/форма) жив и SiteUpdate на копии не ломает его.
- Не раздувайте абонентку до скрытой пересборки - границы пакета см. в статье про техподдержку.
Если сценарий "с нуля / глубокая пересборка"
- Карта старых URL → новых (или сохранение ЧПУ).
- 301 на все важные посадочные; перенос title, description, контента.
- Обновить sitemap и проверить urlrewrite.php при смене ЧПУ - иначе SEO "обнулится" не из-за Битрикс, а из-за битых адресов.
- Тест форм, оплаты, обмена с 1С на копии до DNS cutover.
Позиции не обязаны упасть: риск высок при смене ЧПУ без редиректов. Перенос с другой CMS - другая задача (перенос сайта на Битрикс); здесь речь о уже живом проекте на Управление сайтом.
Делайте: SEO-чеклист до смены DNS. Не делайте: обещать "обнулим и наберём заново" без карты 301.
Зафиксируйте решение одной фразой в ТЗ и КП
Без фиксации через месяц снова услышите "давайте ещё доработаем". В ТЗ/КП одна явная строка:
- "Дорабатываем текущий проект на staging, без правок ядра" или
- "Новый проект на 1С-Битрикс: Управление сайтом + URL map + 301 до cutover".
Как собрать ТЗ без споров на старте - в гайде как составить ТЗ на сайт Битрикс. Если нужен независимый взгляд на аудит развилки, можно обсудить проект на странице контактов - без срочных "оставьте заявку". Примеры работ - в портфолио.
Делайте: решение в одном предложении до старта часов. Не делайте: оставлять в КП размытое "развитие сайта".
Итог для владельца: за час вы прошли боль → технический снимок → red flags → экономику → сценарий с SEO-безопасным переходом. Получите одно решение в чек-листе, а не бесконечную серию "мелких" счетов. Результат - сможете зафиксировать "дорабатывать текущий" или "запускать пересборку" без страха, что новый сайт обнулит позиции. Запуск с нуля для бизнеса без этой развилки - в статье как сделать сайт для бизнеса.
Автор: Максим Мольков, разработчик 1С-Битрикс.
Источники: система обновлений SiteUpdate, документация CMS Управление сайтом, практика аудитов техдолга и SEO-переездов (карта URL, 301, staging).
Частые вопросы
Стоит ли переделывать сайт на Битрикс?
Если набралось ≥2–3 red flags (страх SiteUpdate, "простые вещи сложно", поддержка дороже развития) - планируйте пересборку. Иначе дорабатывайте на staging с запретом правок ядра.
Редизайн или новый сайт на Битрикс?
Редизайн на текущем проекте - если код и структура живы. Новый сайт - если меняются IA, ядро/PHP-база или бизнес-модель. Решение зафиксируйте одной фразой в ТЗ.
Что дешевле: доработка или сайт с нуля?
Сложите поддержку и доработки за 12 месяцев и сравните с ориентиром сметы нового проекта плюс буфер SEO. Если год латания больше ~50% сметы нового - перезапуск часто выгоднее.
Потеряются ли позиции при новом сайте?
Не обязаны. Сделайте карту URL, 301, перенос meta и контента, тест на копии. Риск высок при смене ЧПУ без редиректов и без правки urlrewrite.php.
Можно ли доработать чужой код на 1С-Битрикс?
Да, после аудита доступов и техдолга. Если документации нет и правки сидят в ядре - чаще дешевле пересборка, чем наращивать костыли.
Это то же, что обновление Битрикс (SiteUpdate / CUpdateClient)?
Нет. SiteUpdate (механизм обновлений в админке, связанные API вроде CUpdateClient / CUpdateSystem) - патчи платформы и модулей. Эта статья про продуктовую развилку: доработка текущего проекта vs новая разработка на CMS Управление сайтом.
