Почему мы ушли с Tilda и перевели сайт INSAL на Wagtail в одном контуре с CRM (6 серия)

Это шестая статья из серии о том, как CompanionAI шаг за шагом развивал цифровую систему INSAL. В прошлых частях речь шла о заявках, процессах и первом кабинете клиента. Здесь — о следующем этапе взросления: переходе с Tilda на Wagtail и сборке сайта и CRM в единый фундамент.

Когда стало ясно, что Tilda свою задачу уже выполнила

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

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

Но потом сайт начал расти. Появились новые страницы. Блог начал давать первые SEO-сигналы. Контент перестал быть приложением к рекламе и начал жить своей жизнью. Сайт уже влиял не только на заявки, но и на доверие, поиск, восприятие компании и весь внешний контур бизнеса.

Именно в этот момент стало понятно: Tilda свою задачу уже выполнила. Она помогла стартовать. Но для следующего этапа роста ее логика начала теснить сам бизнес.

Почему вопрос стоял уже не в дизайне, а в контроле

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

Нужно было вернуть себе контроль над внешним цифровым контуром компании.

• Над структурой сайта.
• Над контентом.
• Над URL.
• Над заявками.
• Над аналитикой.
• Над будущими интеграциями.
• Над тем, как все это будет расти дальше.

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

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

Как CompanionAI перезапустил сайт INSAL и сменил его цифровую рамку

Мы в CompanionAI не просто перенесли сайт. Мы заново собрали его рамку.

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

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

Почему мы выбрали Wagtail

Переход на Wagtail не был вопросом вкуса. Он был вопросом логики.

К этому моменту CRM-INSAL уже жила на Django. Значит, разумно было не плодить зоопарк технологий, а наоборот — сузить стек обслуживания и собрать сайт рядом с CRM в одном контуре.

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

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

Почему переезд нужно было сделать без потери уже работающего SEO

На момент миграции у INSAL уже было около 120 проиндексированных страниц. Не тысячи, но уже и не пустое поле.

Это были страницы услуг и статьи блога, которые начали работать в поиске. Терять этот результат из-за переезда никто не собирался.

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

Почему редиректы пришлось прописывать вручную

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

Статьи блога на Tilda жили с адресами, где в URL был кусок /tpost/. Тащить эту конструкцию дальше не хотелось. Это примерно как переезжать в новый дом и зачем-то аккуратно перевозить старую перекошенную дверь только потому, что она уже стоит на петлях.

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

Это была не самая эффектная часть проекта. Но одна из самых полезных. Именно на таких вещах и держится переезд, после которого бизнес не просыпается с мыслью: “А куда делся весь трафик?”

Как мы временно сохранили старую схему заявок, но уже готовили новую

При переезде мы не стали переворачивать весь стол сразу.

Формы заявок на новом сайте по-прежнему уходили в Telegram-бота — так же, как это работало на Tilda. Это было временное решение. Но осознанное.

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

Нормальные системы редко растут через “сегодня миграция, завтра революция”. Чаще они растут слоями. Этот случай был именно таким.

Что мы настроили сразу после запуска нового сайта

После запуска новый сайт сразу поставили под измерение и контроль.

Настроили Яндекс Метрику. Собрали семантическое ядро. Подключили инструменты для мониторинга SEO-позиций и обновления семантики. Иначе говоря, сайт перестал быть просто опубликованным. Он стал наблюдаемым.

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

Отдельно позже появилась история с AI веб-аналитиком, но это уже другая статья. Здесь важнее другое: после переезда сайт начали вести не на ощущениях, а на измерениях.

С этого момента и началась нормальная борьба за место под солнцем. Поисковик ведь не встречает новый сайт с объятиями. Он сначала смотрит на тебя как хозяин рынка на нового арендатора.

Что на самом деле дал переход на Wagtail

Самое важное, что дал этот переход, — не новый шаблон и не более аккуратные блоки на страницах.

Он дал контроль.

• Контроль над структурой сайта.
• Контроль над контентом.
• Контроль над URL и логикой страниц.
• Контроль над заявками и будущими интеграциями.
• Контроль над стеком.
• Контроль над тем, как сайт будет расти дальше.

Плюс он подготовил структуру к масштабированию. На конструкторе можно быстро собрать старт. Но когда впереди блог, SEO, лиды, FAQ, база знаний, новые инструменты, связка с CRM и следующие уровни автоматизации, нужен уже не “удобный редактор страниц”, а нормальный фундамент.

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

Вот это и был настоящий смысл перехода.

Почему этот переход был не финалом, а началом следующего этапа

Переезд на Wagtail ничего не завершил. Он открыл следующий этап.

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

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