Когда сайт на Битрикс пора переделывать — признаки и план

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

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

Доработка или полная переделка: в чём разница

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

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

Семь признаков, что точечные правки перестали помогать

1. Одинаковые изменения приходится повторять вручную

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

2. Контент нельзя нормально редактировать

Если для замены текста, изображения или порядка блоков каждый раз нужен разработчик, сайт не выполняет одну из базовых задач CMS. Причиной может быть не Битрикс, а шаблон, в котором контент жёстко записан в PHP и HTML.

3. Простая задача вызывает цепочку ошибок

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

4. Обновлять Битрикс и PHP опасно

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

5. Скорость не улучшается после настройки кеша

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

6. Структура сайта не соответствует спросу

Услуги объединены по внутренней структуре компании, посетитель не понимает, куда перейти, а SEO-посадочные создаются как случайные копии. В этом случае косметический редизайн не решит проблему: сначала нужно перепроектировать карту сайта и пользовательские сценарии.

7. Стоимость поддержки постоянно растёт

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

Когда сайт всё ещё можно доработать

• ядро Битрикса не изменено, а доработки находятся в /local/;
• структура инфоблоков понятна и соответствует контенту;
• основные проблемы сосредоточены в нескольких компонентах;
• дизайн можно обновить без перестройки всех пользовательских сценариев;
• есть рабочие интеграции, которые нет смысла создавать заново;
• текущие URL и структура разделов подходят для дальнейшего SEO.

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

Что проверить до принятия решения

1. Код: изменено ли ядро, где находятся компоненты, есть ли дубли и устаревшие зависимости.
2. Контент: как устроены инфоблоки, свойства, меню и повторяющиеся данные.
3. Производительность: время ответа сервера, запросы к базе, кеш и фоновые процессы.
4. SEO: индексируемые URL, дубли, редиректы, мета-теги, sitemap и страницы с трафиком.
5. Интеграции: формы, CRM, обмен с 1С, оплаты, доставки, почта и внешние API.
6. Управление: сколько времени занимает типовое изменение и кто может его выполнить.

Как переделать сайт и не потерять SEO

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

На тестовой версии проверяют заголовки, canonical, robots.txt, sitemap.xml, микроразметку и внутренние ссылки. После запуска контролируют ответы 404, индексирование, позиции и трафик. Подробнее эти проверки собраны в SEO-чек-листе перед запуском сайта.

Практичный порядок работ

1. зафиксировать цели бизнеса и критические сценарии пользователей;
2. провести технический, контентный и SEO-аудит;
3. разделить проблемы на локальные и системные;
4. собрать новую структуру данных и прототипы ключевых страниц;
5. разрабатывать на отдельной копии с реальными данными;
6. подготовить карту URL, редиректы и план переключения;
7. после запуска наблюдать за формами, ошибками, скоростью и поисковым трафиком.

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