Переделать сайт или доработать текущий: как принять решение

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

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

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

Сначала определите, что именно перестало работать

Фраза «сайт устарел» почти бесполезна для принятия решения. Она может означать совершенно разные проблемы.

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

Для каждого случая нужен разный объём работ.

Симптом	Что может потребоваться
Устарел только внешний вид	редизайн отдельных шаблонов или визуальной системы
Слабые тексты и оффер	переработка контента и ключевых страниц
Плохой мобильный сценарий	адаптация интерфейса и отдельных компонентов
Медленная загрузка	техническая оптимизация, иногда замена тяжёлых компонентов
Невозможно добавлять новые разделы	пересмотр архитектуры и шаблонов
Доработки регулярно ломают соседние функции	глубокий технический разбор
Бизнес изменился сильнее, чем структура сайта	перестройка информационной архитектуры или новая разработка
Управление контентом требует правок кода	доработка CMS либо замена текущей реализации

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

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

Когда текущий сайт выгоднее дорабатывать

Доработка — нормальный вариант, если основа сайта не мешает следующим изменениям.

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

В такой ситуации нет смысла выбрасывать работающую систему только ради нового дизайна.

Хорошая техническая база

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

Технический долг есть практически у любого живого сайта. Сам по себе он не требует полной переделки. Важно, мешает ли он работе.

Структура соответствует бизнесу

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

Это задача развития существующей архитектуры, а не повод проектировать сайт заново.

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

Нормально работает админка

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

Хорошую систему управления не стоит уничтожать ради визуального обновления. Новую дизайн-систему часто можно построить поверх уже нормальной модели данных.

Проблемы можно изолировать

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

Так можно проверить эффект изменений, не принимая риски полной миграции.

Когда переделка становится рациональнее дальнейшего ремонта

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

Архитектура больше не соответствует проекту

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

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

Каждая следующая доработка дороже предыдущей

Хороший показатель технического долга — не количество строк старого кода, а стоимость изменений.

Предположим, простая задача «добавить новое поле в карточку услуги» объективно занимает несколько часов. Но на текущем сайте разработчику сначала нужно разобраться в самописном шаблоне, обойти устаревший конструктор, исправить конфликт JavaScript и вручную проверить десяток страниц.

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

Если такая картина повторяется, сравнивать нужно не цену одной доработки с ценой нового сайта. Нужно сравнить стоимость следующего этапа развития в двух вариантах.

Нельзя безопасно обновлять компоненты

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

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

Старый сайт ограничивает бизнес-задачу

Иногда переделка нужна даже при нормальном коде.

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

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

Не путайте редизайн с новой разработкой

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

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

Поэтому решение «нам не нравится дизайн — нужен новый сайт» слишком быстрое.

Google рекомендует оценивать удобство страницы комплексно, включая Core Web Vitals, безопасность и качество взаимодействия, но отдельно подчёркивает, что хорошее значение одной метрики не является гарантией высоких позиций. Для проекта это хороший принцип и за пределами SEO: нельзя принимать решение о переделке по одному показателю.

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

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

Сравнивайте не стоимость запуска, а стоимость владения

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

Допустим, доработка стоит условно меньше новой разработки. На этом основании выбирают доработку.

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

Сравнивать лучше так:

Критерий	Доработка текущего	Переделка
Первоначальные затраты	обычно ниже	обычно выше
Срок первого результата	короче для локальных задач	длиннее
Риски для работающих частей	ниже при аккуратных локальных изменениях	выше в момент миграции
Возможность сохранить SEO без изменений URL	высокая	зависит от проекта миграции
Технический долг	часть остаётся	можно устранить значительную часть
Возможность изменить архитектуру	ограничена текущей системой	значительно выше
Долгосрочная поддержка	выгодна при хорошем фундаменте	выгодна, если старая база уже мешала развитию

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

Что обязательно сохранить, если сайт всё-таки переделывается

Рабочий сайт — это не только дизайн и исходный код. У него уже могут быть поисковая история, посещаемые URL, внешние ссылки, контент, конверсии, интеграции и накопленные пользовательские сценарии.

Переделка не должна автоматически означать уничтожение всего этого.

Особенно аккуратно нужно работать с URL. Если существующая страница имеет смысл и новый сайт может сохранить тот же адрес, менять его только ради «более красивой структуры» обычно нет необходимости.

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

До начала работ полезно зафиксировать:

1. индексируемые и получающие трафик URL;
2. структуру разделов и внутренние связи;
3. Title, Description, H1 и основной контент значимых страниц;
4. формы и реальные маршруты заявок;
5. события аналитики и цели;
6. внешние интеграции;
7. sitemap, robots.txt, canonical и правила индексации;
8. страницы, которые уже имеют внешние ссылки или стабильно получают органический трафик.

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

Практический пример: старый WordPress-сайт с постоянно растущим списком правок

Представим корпоративный сайт на WordPress, который работает несколько лет.

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

На первый взгляд это кандидат на полную переделку.

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

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

Теперь другой случай.

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

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

Здесь сохранение старой реализации ради экономии способно увеличить стоимость проекта. Рабочие URL и контент можно перенести, но модель сайта рациональнее спроектировать заново.

Внешне две ситуации похожи: «есть старый WordPress и нужен новый дизайн». Решение противоположное, потому что отличается состояние основы.

Простая матрица решения

Если после анализа всё ещё непонятно, какой сценарий выбрать, оцените четыре области.

Структура. Можно ли добавить новые направления и типы контента без ломки существующей логики?

Техническая база. Можно ли менять компоненты независимо и безопасно обновлять окружение?

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

Стоимость изменений. Оплачиваете ли вы саму новую функцию или значительную часть бюджета съедает борьба со старой системой?

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

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

Есть и промежуточный вариант: перестроить только проблемный слой. Например, сохранить WordPress, URL и структуру контента, но написать новую тему. Или оставить публичную часть, но заменить неудобный механизм управления определённым разделом.

Поэтому выбор не всегда сводится к двум крайностям «ничего не трогать» и «удалить всё и начать с пустого проекта».

Решение должно отвечать на будущую задачу сайта

Самая полезная проверка звучит не «можно ли ещё починить этот сайт?», а «подходит ли эта основа для того, что мы собираемся делать дальше?»

Практически любой сайт можно продолжать ремонтировать. Вопрос только в том, будет ли это рационально.

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

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

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

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