Перенос с конструктора на WordPress: какой путь выбрать

Перенос сайта с конструктора на WordPress почти никогда не сводится к копированию страниц. Часть платформ не отдаёт исходную структуру, формы и настройки SEO, поэтому владелец выбирает между точной пересборкой, сохранением привычного визуального редактора и новым сайтом на блоках WordPress. Ошибка на этом этапе стоит недель работы, просадки органического трафика и постоянных проблем с обновлениями.

Почему перенос не делается одной кнопкой

WordPress 6.x хранит страницу как запись с контентом, метаданными и связями с медиафайлами. Конструктор обычно собирает тот же экран из собственных секций, виджетов и настроек темы. Эти модели данных не совпадают.

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

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

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

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

Три подхода к миграции

1. Пересобрать сайт на блоках WordPress

В этом варианте используются стандартный редактор блоков WordPress 6.x, блоковая тема и отдельные плагины только там, где они действительно нужны. Дизайн повторяют не пиксель в пиксель, а на уровне сетки, типографики, цветов и компонентов.

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

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

2. Перенести сайт на WordPress с тем же или похожим конструктором

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

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

Важно проверить не рекламную совместимость, а конкретные функции: экспорт шаблонов, работу глобальных стилей, загрузку медиа, формы, роли пользователей и поведение после обновления WordPress. Универсального импорта макета из Tilda, Wix или Webflow в такой редактор нет.

3. Оставить фронтенд отдельно, а WordPress использовать как CMS

Этот путь подходит для команды, которая уже поддерживает React, Next.js или другой фронтенд и хочет редактировать материалы через WordPress. WordPress в таком проекте отвечает за записи, страницы и медиа, а посетитель получает интерфейс отдельного приложения.

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

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

Сравнение вариантов

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

Как выбрать вариант без гадания

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

1. Посчитайте типы страниц. Если десять страниц отличаются только текстом и изображениями, им нужен один шаблон. Если каждая страница собрана как уникальный лендинг, стоимость пересборки будет выше.
2. Проверьте экспорт. Уточните, что именно отдаёт исходный конструктор: текст, изображения, URL, данные форм или только архив файлов. Не считайте экспорт HTML полноценным переносом в WordPress.
3. Зафиксируйте критичные интеграции. Форму заявки нужно проверить не только визуально, но и по доставке письма, созданию лида в CRM и уведомлению менеджера.
4. Определите владельца обновлений. Если сайт будет менять маркетолог без разработчика, блоки или визуальный редактор могут быть удобнее. Если за проект отвечает инженерная команда, меньшее число зависимостей обычно выгоднее.
5. Составьте план переключения. До смены DNS подготовьте резервную копию, карту редиректов, тестовый домен и критерии приёмки. На продакшен нельзя переносить сайт, который проверяли только на одном ноутбуке.

Что ломается чаще всего

URL меняются вместе с дизайном

Новый WordPress-сайт нередко получает другие постоянные ссылки: меняются слэши, расширения, названия разделов и структура категорий. Для каждой изменённой страницы нужен редирект со старого адреса на релевантный новый, а не отправка всех посетителей на главную.

Импортируют лишнюю разметку

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

Переносят формы как картинку

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

Забывают о медиафайлах

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

Проверяют только главную страницу

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

Как провести запуск

Работайте на отдельной копии сайта или тестовом домене. Сначала перенесите контент и медиа, затем настройте шаблоны, интеграции и SEO-параметры. До переключения домена сравните список старых и новых URL, проверьте robots.txt, карту сайта и канонические адреса.

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

Что делать дальше

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