Как перенести сайт с Wix на индивидуальную разработку
Сайт на Wix может годами поддерживать бизнес. А потом ограничения дают о себе знать — обычно сразу и по всем фронтам: форма не работает так, как нужно отделу продаж, макет страницы спорит с брендом, а оформление заказа или бронирование функционирует только до следующего изменения. Именно в этот момент задача, как перенести сайт с Wix на индивидуальную разработку, перестаёт быть технической формулировкой и становится бизнес-решением со сроками, страницами и последствиями.
Переезд — это не только про код. Это про то, какие части текущего сайта на Wix по-прежнему заслуживают своего места, что нужно переписать, а что стоит без сожаления убрать. Лендинг на 12 страниц, сайт для лидогенерации с 4 формами или контентный проект с 200 статьями потребуют разного пути миграции, даже если итог всё равно будет называться «кастомным сайтом». В практическом смысле это и есть миграция сайта с Wix на кастомную разработку, где важно не потерять ни структуру, ни бизнес-логику.
Определите объём миграции и бизнес-цели
Начните с узкого вопроса: что здесь означает «индивидуальная разработка»? Для одного проекта это замена фронтенда Wix при сохранении привычной структуры контента. Для другого — превращение сайта в полностью кастомную систему со своими моделями контента, правилами администрирования и интеграциями. Если ответ расплывчатый, миграция быстро начнёт размываться, а перенос сайта с Wix на индивидуальную разработку превратится в бесконечную череду уточнений.
Запишите целевую дату запуска в конкретных терминах. Частый пример: «сохранить 20 страниц с наибольшим трафиком, пересобрать воронку бронирования, оставить все формы лидогенерации и улучшить мобильную производительность на главной и страницах услуг». Такой формат полезен тем, что его можно проверить. «Сделать лучше» — нельзя. Если команда не может назвать 3 измеримых результата, значит, объём работ всё ещё слишком расплывчатый.
Бизнес-цель важна не меньше, чем план разработки. Маркетинговому сайту может быть важнее ускорить редактирование для команды, а сайту, где ключевую роль играет продажи, — более чистая маршрутизация лидов и меньше брошенных форм. Если текущий сайт на Wix уже поддерживает структуру корпоративного сайта, новая версия должна сначала сохранить те же бизнес-приоритеты, а уже потом пытаться их переизобрести.
Перед тем как делать что-либо ещё, задайте один практический вопрос: что произойдёт, если запуск сдвинется на 2 недели? Ответ покажет, чем именно движет миграция — срочностью, датой кампании или потолком возможностей платформы. И он же покажет, кто почувствует последствия первым.
Проведите инвентаризацию зависимостей сайта на Wix
Сделайте полный перечень того, что сайт на Wix действительно делает. Не останавливайтесь на страницах. Зафиксируйте формы, автоматизации, сценарии бронирования, сбор email-адресов, чат-виджеты, встроенные блоки, вход в личный кабинет, скрытые посадочные страницы, мультиязычный контент и любые виджеты, которые появились только потому, что кто-то срочно добавил их в прошлом году. Wix позволяет быстро подключать функции; проблема в том, что потом о них так же легко забыть.
Обычно есть зависимости, которые выглядят незначительными, но создают больше всего работы. Подписка на рассылку может передавать данные сразу в 2 системы. Страница бронирования может запускать письмо, событие в календаре и запись в CRM. Один встроенный калькулятор может зависеть от поведения скрипта, которое в индивидуальной разработке придётся воссоздавать с нуля. На этом этапе внимательная проверка — не формальность. Это предупреждающий знак.
Перед тем как двигаться дальше, занесите зависимости в простую таблицу.
| Функция Wix | Текущее назначение | План замены | Ответственный |
|---|---|---|---|
| Форма лидогенерации | Собирает обращения с 6 страниц | Кастомная форма с передачей в CRM | Маркетинг |
| Сценарий бронирования | Назначает консультации | Кастомный модуль расписания или внешний сервис | Операции |
| Встраиваемый виджет | Показывает калькулятор цен | Пересобранный компонент | Разработка |
| Сбор email | Питает список для кампаний | Новый путь интеграции | Маркетинг |
Не забывайте и про мобильное поведение. Виджет, который нормально выглядит на десктопе, может сломаться на экране 390 пикселей. Одна такая деталь способна повлиять на весь график миграции.
Решите, что сохранить, переписать или убрать
Для любой миграции нужен список для приоритизации с 3 колонками: сохранить, улучшить, удалить. Именно здесь команда перестаёт считать каждую страницу неприкосновенной. На сайте Wix часто остаются старые тексты, дублирующиеся посадочные страницы, сезонные акции и старые CTA, которые больше не соответствуют текущему предложению. Оставить всё только потому, что это уже есть, — верный способ раздуть миграцию.
Опирайтесь на бизнес-данные, а не на эмоции. Страница, которую посещают 1 000 раз в месяц и которая приносит лиды, заслуживает совсем иного отношения, чем страница, которую не открывали с 2022 года. Блок FAQ, который отвечает на реальные возражения, можно оставить и привести в порядок. Всплывающее окно, написанное под старую кампанию, лучше убрать. Если функция создаёт лишние шаги и не даёт измеримой пользы, её стоит вывести из использования.
Переписывать нужно те элементы, которые всё ещё важны, но работают недостаточно хорошо. Это может быть главный экран, блок сравнения тарифов или контактная форма с слишком большим количеством полей. Сохранять стоит тот контент и то поведение, которые уже работают. Удалять — всё, у чего больше нет задачи. Просто. И непросто одновременно.
На этом этапе команды часто замечают, насколько многое на Wix строилось на обходных решениях, а не на осознанном дизайне. Кастомная разработка не должна копировать каждый такой обходной путь. Она должна оставить полезные 20% и не тащить за собой остальное.
Спланируйте процесс миграции контента
Миграции контента нужен отдельный процесс, а не примечание в таблице. Начните с текстов страниц, затем перенесите медиа, потом записи блога, затем файлы для скачивания. Порядок важен, потому что тексты часто меняются во время согласования, а изображения не стоит импортировать, пока кто-то не подтвердил финальный список файлов. Если сначала перенести устаревший контент, время будет потрачено дважды.
Разбейте контент на партии. Например, сайт на 50 страниц можно переносить группами по 10 страниц, причём каждую группу стоит проверять до начала следующей. Это даёт команде контента возможность рано заметить пропавшие изображения, битые ссылки и старые CTA. И это снижает риск продублировать материал, который больше не должен быть на сайте.
Очистите исходные материалы до импорта. Уберите старые PDF, проверьте размеры изображений и при необходимости перепишите заголовки страниц. Если задействованы публикации в блоге, решите, переносить ли абсолютно все записи или только те, что по-прежнему поддерживают трафик и авторитет бренда. Для насыщенной контентом миграции часто хорошо подходит более широкий проект, например контентный портал об инвестициях, где структура и редакционная гигиена влияют на весь продукт.
Не копируйте экспорт вслепую. Контент Wix часто содержит особенности форматирования, которые в редакторе выглядят безобидно, а на новом сайте — неаккуратно. Одного лишнего переноса строки достаточно, чтобы страница ощущалась недоделанной.
Переведите взаимодействия Wix в кастомные требования
Самая сложная часть задачи, как перенести сайт с Wix на индивидуальную разработку, часто связана не с контентом, а с поведением. Интеракции Wix могут прятаться в анимациях, модальных окнах, личных кабинетах, переключателях вкладок, аккордеонах, фильтрах и формах лидогенерации. Разработчик не сможет воссоздать «то же ощущение», если поведение не описано чётко.
Переведите каждое взаимодействие в функциональное требование. Для формы лидогенерации укажите названия полей, правила валидации, состояния ошибок, сообщения об успешной отправке, защиту от спама и то, что должно происходить после отправки. Для модального окна опишите, когда оно открывается, как закрывается, должно ли появляться на мобильных устройствах и блокирует ли оверлей прокрутку страницы. Такая детализация экономит время позже, особенно если функция должна подключаться к чему-то вроде цепочки email, SMS и push-уведомлений.
Анимации заслуживают того же внимания. Если секция плавно появляется через 200 миллисекунд, это нужно записать. Если в личном кабинете контент скрывается до входа в систему, зафиксируйте правила доступа и состояния пользователя. Если таблица цен меняется в зависимости от страны или тарифа, опишите логику. Формулировки «сделайте как на Wix» недостаточно. Разработчикам нужно поведение по шагам, а не догадки.
Один практичный приём: записывайте короткие видео текущего сайта на Wix. Клип на 90 секунд может показать больше поведения, чем долгий созвон. Это особенно важно, когда 3 человека по-разному помнят одну и ту же функцию.
Настройте передачу URL, редиректов и аналитики
Планирование URL стоит начать ещё до того, как закончится дизайн. Составьте список текущих адресов, сопоставьте новые и отметьте страницы, которым нужно сохранить существующие URL. Если slug меняется, перенаправление нужно определить заранее, а не после запуска. Сайт на 80 страниц, где перенаправлено только 12 путей, может выглядеть аккуратно в таблице и при этом потерять трафик, если важные маршруты окажутся пропущены.
Непрерывность поискового трафика — это не магия, а работа. Цепочки редиректов нужно проверять, старые страницы должны вести в правильное новое место, а внутренние ссылки следует обновить так, чтобы новый сайт не зависел от перенаправлений вечно. Если старый сайт на Wix индексировался годами, к этой истории нужно отнестись особенно аккуратно. Такая миграция может затронуть и безопасность сайта, и трекинг, поэтому права доступа и изменения скриптов лучше проверять вместе, а не по отдельности.
Передача аналитики требует такого же внимания. Определите, какие события важны: отправка формы, начало бронирования, завершение бронирования, клик по скачиванию, клик по телефону и, возможно, глубина прокрутки на ключевых страницах. Решите, куда отправляется каждое событие и кто сможет это проверить. Если команда использует инструмент, похожий на платформу аналитики и мониторинга сайта, новый сайт должен с первого дня передавать в неё чистые данные.
Зафиксируйте все SEO- и аналитические допущения, которые нельзя проверить по исходным документам. Сюда входят теги, цели конверсии и любой устаревший фрагмент кода, который никто уже не помнит. Лучше один раз подтвердить, чем потом потерять месяц данных.
Подготовьте запуск, QA и точки отката
День запуска требует контрольных точек, а не оптимизма. Список QA должен охватывать десктоп и мобильные устройства, основные браузеры, точность контента, доставку форм, битые ссылки, поведение редиректов и скорость страниц на самых посещаемых шаблонах. Протестируйте сайт минимум на 2 размерах экрана для каждого шаблона, иначе команда пропустит проблему, которая проявляется только на маленьком дисплее.
Проведите тестирование форм с реальными отправками. Контактная форма может выглядеть исправной, но всё равно не работать, если маршрутизация писем настроена неправильно, антиспам-фильтр слишком строгий или сообщение об успехе вообще не появляется. Проверьте каждый критичный сценарий до запуска, а затем повторите проверку после переключения домена на новый сайт. Второй тест помогает поймать сюрпризы, вызванные боевой конфигурацией, а сюрпризы обычно приходят поздно.
Подготовьте точку отката до запуска, а не после. Если на кастомном сайте возникает серьёзная проблема, команда должна понимать, откатывать ли DNS, отключать ли релиз или восстанавливать предыдущую сборку. План отката — не что-то драматичное. Это спокойная подготовка. Для сайтов, которым регулярно нужна поддержка, передача проекта должна включать поддержку сайта после запуска, чтобы исправления не превращались в аварию на 3-й день.
Перед финальным запуском проверьте 3 вещи за один проход: контент страницы, доставку форм и события аналитики. Затем проверьте всё ещё раз после запуска уже с телефона. Проверка на телефоне помогает поймать неудобные мелочи.
И ещё один момент: если старый сайт на Wix включает закрытую область, набор правил бронирования или ограниченный доступ, связанный с более крупной системой, план запуска должен учитывать и контроль доступа, и поток данных. Видимая страница может пройти QA, а связанный процесс — сломаться в фоне. Такой сбой сложнее заметить, чем неработающую кнопку, и дороже исправить, когда клиенты уже пользуются новым сайтом.
