Конструктор или код: когда сайт пора переносить

Вопрос, который обычно задают не вовремя

«Конструктор или разработка сайта» — вопрос, который почти всегда задают дважды. Первый раз на старте, когда сайта ещё нет и любой ответ выглядит одинаково убедительно. Второй — года через полтора, когда сайт есть, работает, и что-то в нём перестало получаться.

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

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

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

Что конструктор действительно решает

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

Скорость. От идеи до работающей страницы — вечер. Ни один подрядчик не сделает быстрее, потому что у подрядчика есть бриф, согласование и очередь.

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

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

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

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

Где конструктор упирается, и это не про дизайн

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

Упираются в три другие вещи.

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

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

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

Пять признаков, что вы упёрлись

Ни один из них поодиночке не повод переезжать. Три сразу — уже разговор.

Вы регулярно платите за сторонние сервисы, чтобы обойти ограничение платформы. Считайте эти подписки частью стоимости конструктора — обычно они удваивают её.

Одна и та же правка занимает часы, потому что делается на двадцати страницах вручную. Это не про удобство: это про то, что структура данных не соответствует задаче.

Вы не можете ответить на вопрос, почему конкретная страница медленно грузится. Не «знаете, но не чините», а именно не можете посмотреть.

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

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

Что стоит переезд на самом деле: 673 адреса

Теперь про счёт, который обычно не показывают. Разработка нового сайта — это меньшая часть переезда. Большая — то, что происходит со старыми адресами.

Наш сайт переехал с прежней платформы, и поисковик за годы успел узнать сотни адресов. После смены движка они перестали существовать. В отчёте Search Console это выглядит как 673 адреса с ответом «не найдено».

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

Отсюда практическое правило: карта соответствий старых и новых адресов составляется до разработки, а не после запуска. Инвентаризация выгружается из старой платформы и из Search Console, потому что списки не совпадут — поисковик знает адреса, о которых вы забыли.

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

Почему трафик падает даже при аккуратном переезде

Это стоит знать заранее, чтобы не принять нормальный процесс за провал.

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

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

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

Про SEO на конструкторах — без мифов

Утверждение «сайты на конструкторах не продвигаются» неверно, и повторяют его чаще всего те, кто продаёт разработку.

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

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

И в скорости загрузки. Конструкторы грузят универсальный набор скриптов, потому что не знают заранее, что вам понадобится. На своём коде отдаётся только нужное. Разница обычно не катастрофическая, но на мобильном трафике заметная — а Core Web Vitals измеряются именно на реальных визитах.

Когда переезжать точно не нужно

Три ситуации, в которых разработка не окупится, как бы убедительно её ни продавали.

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

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

Вам сказали, что «на конструкторе нет SEO». Прежде чем верить, попросите показать, какая конкретно правка невозможна. Если ответа нет — это не аргумент.

Гибрид, который часто оказывается верным

Между «всё на конструкторе» и «всё своё» есть промежуточный вариант, который почему-то редко предлагают.

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

Технически это решается общим доменом с разделением по путям. Для поисковика и для посетителя это один сайт.

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

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

Экспорт: проверьте до того, как он понадобится

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

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

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

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

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

Как принять решение за один вечер

Возьмите список задач, которые вы за последние полгода хотели сделать на сайте и не сделали. Именно хотели и не сделали, а не «было бы неплохо».

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

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

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

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

Что мы бы сделали иначе

Две вещи, которые стоили нам времени.

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

И запускать стоило частями. Мы выкатили новый сайт целиком, и когда что-то пошло не так, невозможно было понять, какая именно часть виновата. Раздел за разделом — медленнее, но каждый шаг проверяем.

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