Миграция с Wix на современный стек - это перенос контента, форм и функциональности сайта с закрытой конструкторной платформы на связку headless CMS и фреймворк (Astro, Next.js). Главный риск - не сам переезд, а потеря трафика из-за изменённых URL, сброшенных SEO-сигналов и недоступных для экспорта данных. При правильном аудите и плане редиректов эти потери предотвратимы.
Wix отлично справляется с задачей быстро запустить сайт без разработчика. Проблема начинается позже: когда компания вырастает из конструктора, а сайт остаётся её единственным каналом привлечения клиентов. В проектах веб-разработки мы регулярно видим одну и ту же последовательность: сначала на Wix верстают лендинг за неделю, через два-три года бизнес упирается в потолок платформы - и решение о переезде принимается под давлением, а не по плану.
Дальше - что именно упирается в потолок, что теряется при неаккуратном переезде и как сделать миграцию так, чтобы клиенты не заметили смену платформы.
Почему компании уходят с Wix
Wix уходит в прошлое для растущих компаний по одной и той же причине: платформа проектировалась для запуска, а не для масштабирования. Ограничения проявляются в пяти точках.
Лимиты страниц и хранилища. На тарифах Wix действуют ограничения на количество страниц, товаров в каталоге и объём хранилища медиафайлов. Для интернет-магазина с растущим ассортиментом это становится потолком быстрее, чем кажется на старте.
Нет прямого доступа к коду. Wix не даёт редактировать исходный HTML/CSS/JS сайта напрямую - вся кастомизация идёт через визуальный редактор и ограниченный API приложений (Velo). Сложная интеграция с внутренними системами или CRM в такой модели превращается в обходной манёвр, а не в нормальную разработку.
Ограничения SEO. У Wix исторически нет тонкого контроля над структурой sitemap, доступ к robots.txt ограничен настройками платформы, а кастомизация URL никогда не была сильной стороной конструктора. Для сайта, где органический трафик - основной канал, это системное ограничение, а не мелкая неприятность.
Производительность. Чем больше приложений и виджетов установлено на сайт Wix, тем тяжелее становится JS-бандл. Мобильная производительность страдает в первую очередь - большинство виджетов Wix не оптимизированы под мобильный рендеринг.
Вендор-локин. Контент и дизайн живут внутри проприетарного формата Wix. Чистого экспорта в стандартный HTML или в CMS-совместимый формат не существует - весь контент нужно вытаскивать вручную или через ограниченный API.
Если сайт на WordPress тоже упирается в похожие ограничения производительности, логика перехода на headless-стек будет той же - разница только в деталях экспорта данных.
Что теряется при наивной миграции
Наивная миграция: перенос сайта на новую платформу без сохранения структуры URL и без плана редиректов. Это самая частая причина падения трафика после переезда.
Три категории потерь возникают чаще всего.
Первая - структура URL. Wix генерирует адреса страниц по своей логике, часто с параметрами и слэшами, которые не совпадают со стандартной структурой Astro или Next.js. Если новый сайт использует другие пути - все закладки клиентов, ссылки из email-рассылок и внешние упоминания в статьях начинают вести на 404.
Вторая - контент, запертый в проприетарном формате. Wix не отдаёт содержимое страниц в виде чистого HTML или Markdown. Экспорт превращается в комбинацию скрапинга страниц, ручного копирования текста и восстановления структуры заголовков - типично это самая долгая часть проекта миграции.
Третья - SEO-сигналы. Каждая страница на Wix накопила историю: индексацию в Google, внешние ссылки, позиции в выдаче. При переезде без 301-редиректов эта история обнуляется - поисковик видит новый URL как новую страницу без истории, и ранжирование начинается заново.
Аудит сайта на Wix перед переездом
Аудит перед переездом - это полная инвентаризация того, что есть на текущем сайте, до того как что-либо удалено или изменено. Пропущенный на этом этапе элемент почти всегда всплывает уже после запуска нового сайта, когда его сложнее исправить.
Что включить в инвентаризацию:
- Все страницы и их URL - выгрузка полного списка адресов, включая те, что не в основном меню (лендинги под рекламу, старые акции, служебные страницы)
- Приложения и виджеты - что установлено на сайте и какую функцию каждое из них выполняет (форма записи, чат, галерея, календарь бронирования)
- Формы и их интеграции - куда уходят данные из форм на Wix: email, CRM, таблица, сторонний сервис
- Текущие позиции в поиске - зафиксировать позиции по ключевым запросам как базовую точку для сравнения после переезда
Без этого списка легко забыть одну форму бронирования, интегрированную три года назад с сервисом, о котором уже никто в компании не помнит - а клиенты продолжают ей пользоваться.
Как не потерять клиентов при переезде
Клиенты не должны заметить смену платформы - это единственный критерий успешной миграции. Четыре меры защищают от потерь.
301-редирект для каждого URL. Каждая старая страница Wix получает постоянный редирект на соответствующую новую страницу. Это защищает и закладки пользователей, и накопленный SEO-вес - поисковые системы передают большую часть ссылочного веса через 301, а не начинают отсчёт заново.
Пример правил редиректов (Netlify _redirects)
/old-service-page /uslugi/novaya-stranica 301
/blog/post-slug /blog/post-slug-novyj 301
/* /404 404Согласованность контактных данных. Название компании, адрес и телефон (NAP) должны совпадать во всех местах: на новом сайте, в Google Business Profile, в справочниках. Расхождение путает и клиентов, и локальный поиск.
Прозрачная коммуникация об окне простоя. Если предусмотрен технический перерыв - клиенты должны узнать об этом заранее, а не наткнуться на недоступный сайт в момент, когда им нужно оформить заказ.
Тестирование форм и оформления заказа до полного переключения. Каждая форма, корзина и шаг оформления проверяются на новом сайте параллельно со старым - до того как DNS переключен на продакшен.
Выбор нового стека
Правильный стек для замены Wix - это связка фреймворка со статической генерацией (Astro или Next.js) и headless CMS. Комбинация закрывает именно те ограничения, из-за которых компании уходят с Wix.
Доступ к коду возвращается полностью: любая кастомная интеграция, форма или логика пишется как обычный код, а не как обход через ограниченный конструкторный API. Масштаб перестаёт быть проблемой - headless CMS не ограничивает число страниц или объём медиатеки тарифным планом. SEO получает полный контроль: sitemap генерируется программно, robots.txt редактируется напрямую, структура URL проектируется под задачу, а не под шаблон конструктора.
Выбор конкретной headless CMS (Sanity, Contentful, Strapi, Payload) зависит от команды и объёма контента - мы разбирали разницу в сравнении Sanity, Contentful и Strapi для B2B-сайта. Если старого сайта фактически нет или он настолько устарел, что переносить нечего - иногда логичнее не мигрировать контент, а спроектировать сайт с нуля на новом стеке.
Пошаговый процесс миграции
Миграция с Wix проходит пять последовательных этапов. Пропуск любого из них увеличивает риск потери трафика или клиентов после запуска.
Инвентаризация
Фиксируется полный список страниц, форм, интеграций и текущих позиций в поиске - результат аудита из раздела выше становится техническим заданием для всего проекта.
Экспорт контента
Контент вытаскивается со страниц Wix - текст, изображения, метаданные - и приводится к структуре, которую понимает новая CMS. Для среднего сайта из 30-50 страниц это типично самая трудоёмкая часть проекта, поскольку прямого экспорта Wix не предоставляет.
Сборка нового сайта
Новый сайт собирается на выбранном стеке: структура страниц, компоненты, интеграция с headless CMS, подключение форм к их реальным адресатам (CRM, email, база данных).
Настройка редиректов
Составляется полная карта 301-редиректов старый URL - новый URL, она загружается в конфигурацию хостинга (Netlify, Vercel, Cloudflare Pages) до переключения DNS.
Запуск и мониторинг
Домен переключается на новую инфраструктуру, после чего в течение двух-четырёх недель отслеживаются: ошибки 404 в Google Search Console, позиции по ключевым запросам, работоспособность форм и корзины.
Core Web Vitals до и после
Core Web Vitals - это набор метрик Google для оценки скорости и стабильности сайта: LCP (скорость загрузки основного контента), CLS (визуальная стабильность) и INP (отклик на действия пользователя).
Сайты на Wix с несколькими установленными приложениями типично показывают PageSpeed Insights в диапазоне 50-65 баллов на мобильной версии - в первую очередь из-за веса JS-бандла и медленного LCP. После переезда на Astro или Next.js со статической генерацией тот же сайт обычно выходит на 90+ баллов: меньше JavaScript на клиенте, изображения оптимизированы автоматически, HTML отдаётся уже готовым.
Разница ощущается не только в цифрах отчёта. Более подробную методологию измерения и целевые пороги LCP/INP/CLS мы разбирали в статье про улучшение Core Web Vitals в 2026 году - логика измерения одинакова независимо от платформы, с которой уходит сайт.
В типовом проекте переноса каталога на 150-200 товаров с Wix на Astro с headless-каталогом LCP на карточках товаров снижается с 3,5-4 секунд до 1,5-2 секунд - в основном за счёт того, что изображения перестают тянуть за собой JS-логику виджета галереи. Для интернет-магазина это напрямую отражается на конверсии мобильного трафика, где чувствительность к скорости загрузки выше всего.
Типичные ошибки при переезде
Три ошибки встречаются в проектах миграции чаще остальных.
Первая - переезд без карты редиректов, “на глаз”. Команда переносит контент, меняет структуру URL под новый фреймворк и не сопоставляет старые адреса с новыми. Результат - органический трафик проседает в первые недели после запуска, пока Google заново индексирует сайт с нуля.
Вторая - потеря интеграций форм. Форма на Wix, подключенная к CRM или таблице, копируется визуально, но её бэкенд-логика не переносится - новая форма выглядит так же, но никуда не отправляет данные.
Третья - отсутствие тестового периода. Новый сайт запускается сразу в продакшен без параллельного тестирования корзины и форм на реальных, но не завершённых заказах.
Показательный сценарий: компания переносит сайт услуг с формой записи, интегрированной с внешним календарём через виджет Wix. Визуально форма переезжает на новый сайт за один день. Но встроенный виджет использовал собственный API Wix для записи слотов - на новом стеке этот API недоступен, и запись перестаёт создавать события в календаре, пока кто-то из клиентов не пожалуется на пропущенную встречу. Именно поэтому инвентаризация интеграций - не формальность, а страховка от подобных сюрпризов.
Для кого актуально
Миграция с Wix актуальна для компаний, у которых сайт стал полноценным каналом привлечения клиентов, а не просто визиткой. Типичный профиль: команда от 10-15 человек, органический трафик даёт заметную долю обращений, растущий каталог товаров или услуг упирается в лимиты тарифа Wix, а необходимость кастомной интеграции с CRM или внутренними системами больше не решается через готовые приложения платформы.
Часто задаваемые вопросы
Сколько времени занимает миграция сайта с Wix
Типичный проект миграции сайта из 30-50 страниц занимает от четырёх до восьми недель: аудит и инвентаризация - одна-две недели, экспорт и перенос контента - две-три недели, сборка нового сайта и настройка редиректов - одна-две недели, тестирование и запуск - ещё одна неделя. Интернет-магазины с большим каталогом товаров или сложными интеграциями требуют больше времени на этапе экспорта данных.
Упадут ли позиции сайта в Google после переезда с Wix
Кратковременное колебание позиций после переезда - обычное явление, поскольку Google переиндексирует изменённые страницы. При корректно настроенных 301-редиректах для каждого URL и сохранённой структуре контента позиции обычно восстанавливаются в течение четырёх-шести недель. Просадка становится постоянной только если редиректы настроены с ошибками или отсутствуют вовсе.
Можно ли перенести контент с Wix автоматически
Полностью автоматического переноса контента с Wix не существует, поскольку платформа не предоставляет чистый экспорт в HTML или Markdown. Часть данных - тексты, метаданные, список страниц - можно вытащить через скрипты и API приложений Wix, но структуру и вёрстку обычно приходится восстанавливать вручную под новую CMS.
Что делать с формами и интеграциями при переезде с Wix
Каждую форму на старом сайте нужно инвентаризировать отдельно: куда она отправляет данные - в CRM, на email, в таблицу или в сторонний сервис. При сборке нового сайта форма пересоздаётся с той же логикой отправки, а перед запуском проверяется тестовой заявкой, чтобы убедиться, что данные доходят до нужного адресата.
Если ваш сайт на Wix упирается в лимиты платформы, а любая доработка превращается в обходной путь через ограниченный API - опишите текущую структуру сайта команде Exceltic.dev. Проведём аудит и оценим объём переноса на современный стек через сервис переезда сайтов.