Специалист требует сменить движок. Это необходимо?

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

Часто компания верит, и начинается переезд на новую платформу, который съедает:

• от трёх месяцев времени;

• от 300 тысяч рублей до миллиона и выше.

Но эти затраты далеко не всегда оправдываются. Я Артём Гал — специалист в области поисковой оптимизации. В сфере с 2005 года; веду авторский телеграм‑канал о GEO‑ и SEO‑продвижении. За это время вывел в ТОП более 200 сайтов на разных платформах — от самописных движков до массовых конструкторов. Рассказываю, почему не всегда нужно менять движок и как понять, что специалист разводит клиента на деньги.

Почему смена движка — это дорого и неэффективно

WordPress, Битрикс, Tilda, 1С‑UMI, Joomla, Drupal, MODX — каждая из этих платформ закрывает 95% задач, с которыми приходит малый и средний бизнес. Разница между ними на уровне инструмента: профессионал сможет работать на любых движках.

Какой движок выбрать для эффективного SEO

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

Но в большинстве случаев, когда клиенту говорят, что на этом движке оставаться нельзя, на самом деле:

• специалист не умеет работать на конкретной платформе и предлагает перейти туда, где удобнее ему;

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

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

Как минимизировать сложности в работе с движком

1. Контекст разработчика

Каждый раз, когда состав команды меняется, компания теряет не просто исполнителя, а контекст.

Ваш разработчик знает вещи, которых не найдёшь ни в одном ТЗ:

• почему вот эта страница свёрстана именно так, а не иначе;

• где лежит логика, которую трогать нельзя;

• что уже пробовали и почему отказались;

• какие интеграции держатся на честном слове;

• где костыль, который при неосторожном движении ломает весь каталог.

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

Если у вас нет контакта с человеком, который делал ваш сайт — попробуйте его найти. Это ценнее, чем любой аудит от нового агентства.

2. Чёткое ТЗ

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

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

Что запомнить

• Фиксируйте решения, а не только результат. Когда что‑то сделано — записывайте, почему именно так. Через два года, когда придёт новый подрядчик, документация сэкономит вам деньги.

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

• Давайте точные задачи. Конкретика — это уважение к чужому времени и защита своего бюджета.

Ещё о разработке сайтов

Создал клиенту 20 нишевых сайтов: зачем и к чему это привело

Запускаем сайт с нуля: пошаговая инструкция

Файл robots.txt: что это и как с ним работать