Доработка сайта или новый сайт: разбор по критериям

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

Ось первая: что происходит с индексом

Если сайт уже накопил позиции в Яндексе и стабильный органический трафик, это актив, который легко потерять при неаккуратном переезде. Прежде чем решать что-либо, выгрузите из Вебмастера список индексируемых URL, отчёт по кликам за полгода и текущие позиции по ключевым запросам. Если органика даёт заметную долю заявок, любое решение о переделке должно включать план сохранения этого трафика: 301-редиректы, идентичную семантику в title и H1, перенос текстовых блоков, которые уже ранжируются. Сайты без истории в поиске или с околонулевым трафиком из органики теряют меньше при полном пересборе — там риск не в SEO, а в бюджете и сроках.

Ось вторая: во что превратился код

• Правки последних месяцев делаются медленнее, чем раньше, при той же сложности задач
• Разработчики жалуются на «костыли над костылями» и боятся трогать соседние модули
• Обновления CMS или плагинов регулярно что-то ломают
• Нет доступа к репозиторию, документации или прежнему подрядчику
• Производительность деградирует с каждым новым разделом

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

Ось третья: тянет ли платформа задачу

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

Ось четвёртая: изменился ли сам бизнес

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

Матрица решений: как свести всё в таблицу

1. Выпишите органический трафик и топ-20 страниц по кликам за последние 6–12 месяцев
2. Оцените код по пятибалльной шкале: читаемость, тестируемость, документация, зависимости
3. Составьте список функционала, который нужен в ближайший год, и проверьте, поддерживает ли его платформа
4. Сверьте текущую структуру разделов с актуальным списком услуг и целевой аудиторией
5. Сложите баллы по осям: большинство «зелёных» — доработка, большинство «красных» — новый сайт

Как считается бюджет в каждом сценарии

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

Промежуточный вариант: поэтапная доработка вместо революции

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

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

Если решили делать новый сайт: как не потерять то, что работало

1. Зафиксируйте карту старых URL и их метрики трафика до начала разработки
2. Перенесите структуру услуг и семантику, которая уже приносит заявки, в новую архитектуру
3. Спроектируйте 301-редиректы со старых адресов на новые до релиза, а не после
4. Сохраните тексты и заголовки страниц, которые ранжируются, даже если меняется дизайн вокруг них
5. Обновите карту сайта и отправьте её на переобход в день запуска