Как перенести сайт на WordPress без потери SEO, контента и заявок

Перенос сайта на WordPress может означать две разные задачи. Первая — миграция проекта с Tilda, Joomla, ModX, Wix или самописной CMS на новую систему управления. Вторая — перенос уже работающего WordPress-сайта на другой хостинг, сервер или домен.
В обоих случаях недостаточно скопировать тексты и изображения. Нужно сохранить структуру URL, мета-теги, формы, аналитику, интеграции, пользовательские данные и возможность отката. Ошибки при миграции приводят к битым ссылкам, исчезнувшим заявкам, дублям страниц и снижению поискового трафика.
Главный принцип переноса
Сначала создаётся карта соответствия старого и нового сайта, затем выполняется миграция. Пользователь и поисковый робот должны понимать, куда переместилась каждая важная страница и как работает её новый аналог.
Успешный перенос незаметен для клиента: привычный адрес открывается, форма работает, а поисковая система получает однозначный сигнал о новом расположении страницы.
Какие виды переноса бывают
| Сценарий | Что меняется | Основной риск |
|---|---|---|
| С другой CMS на WordPress | CMS, тема, административная панель и часто дизайн | Потеря структуры, контента и функций |
| WordPress на другой хостинг | Сервер, база данных, DNS и окружение | Простой, ошибки конфигурации и почты |
| WordPress на новый домен | Домен, внутренние ссылки, аналитика и SEO-сигналы | Потеря трафика без редиректов |
| HTTP на HTTPS | Протокол всех ресурсов | Смешанный контент и циклические редиректы |
| Поддомен в основной раздел | Структура URL и область сайта | Дубли и неправильная каноникализация |
| Редизайн с сохранением CMS | Тема, шаблоны и часть структуры | Удаление ценных страниц и контента |
Задачи можно совмещать, но это увеличивает риск. Одновременная смена CMS, домена, дизайна и структуры усложняет диагностику: если после запуска упал трафик, трудно определить конкретную причину. По возможности изменения разделяют или тщательно фиксируют исходные данные.
Когда перенос на WordPress оправдан
- контент сложно редактировать без разработчика;
- текущая CMS не поддерживается или ограничивает развитие;
- невозможно создавать новые посадочные страницы;
- сайт зависит от закрытой подписки или конструктора;
- нужна индивидуальная тема и собственные блоки;
- требуются интеграции, которые невозможно надёжно подключить;
- компания хочет контролировать хостинг, файлы и базу данных;
- существующая система создаёт дубли и технические SEO-ограничения.
Перенос не является самоцелью. Если текущая CMS справляется с задачами, безопасно обновляется и удобна сотрудникам, смена платформы может не окупиться. Решение должно основываться на ограничениях, стоимости развития и планах бизнеса.
Возможности платформы и подход JustBusiness описаны на странице разработки сайтов на WordPress.
Этап 1. Полная инвентаризация старого сайта
До разработки нового проекта нужно зафиксировать, что уже существует. Для этого выгружаются URL, мета-теги, заголовки, статусы страниц, изображения, входящие ссылки и поисковый трафик.
| Что собрать | Зачем |
|---|---|
| Все индексируемые URL | Не потерять важные страницы и настроить редиректы |
| Title, Description и H1 | Сохранить релевантность и избежать пустых мета-полей |
| Трафик и позиции | Определить приоритетные страницы |
| Внешние ссылки | Сохранить адреса с накопленным авторитетом |
| Формы и цели | Не потерять заявки и аналитику |
| Файлы и изображения | Перенести документы, медиа и alt-тексты |
| Интеграции | Восстановить CRM, почту, оплату и API |
| Пользователи и заказы | Определить требования к миграции данных |
Выгрузка должна включать не только страницы меню. На сайте могут быть посадочные страницы рекламы, старые статьи, PDF-файлы и разделы, которые получают трафик, но не видны в основной навигации.
Этап 2. Решение: сохранить структуру или изменить
Если текущая структура логична и имеет поисковый трафик, URL лучше сохранить. Изменение адреса оправдано, когда он технически плох, содержит лишние уровни, не соответствует новой структуре или переносится на другой домен.
URL сохраняем
- страница получает трафик;
- на неё ведут внешние ссылки;
- содержание и назначение остаются прежними;
- адрес понятен и не содержит технического мусора;
- нет конфликта с новой архитектурой.
URL меняем
- объединяются несколько дублей;
- полностью меняется назначение страницы;
- адрес зависит от старой CMS;
- раздел переносится в другую иерархию;
- страница удаляется или заменяется.
Для каждого изменённого адреса заранее назначается новый URL. Это оформляется как карта редиректов, а не составляется после запуска по сообщениям об ошибках.
Карта редиректов
| Старый URL | Новый URL | Действие |
|---|---|---|
| /old-service/ | /services/new-service/ | 301 на релевантную страницу |
| /catalog/item-1.html | /catalog/item-1/ | 301 без изменения содержания |
| /old-section/page/ | /new-section/ | 301 после объединения |
| /obsolete-promo/ | — | 410 или релевантная альтернатива |
| /file.pdf | /media/file.pdf | Сохранить адрес или настроить 301 |
Постоянный 301-редирект сообщает, что страница перемещена. Нельзя направлять все удалённые адреса на главную: такой редирект не помогает пользователю найти нужную информацию и может восприниматься поисковой системой как мягкая ошибка.
Контроль после запуска
Список старых URL повторно сканируется. Каждый адрес должен либо открываться с кодом 200, либо вести одним постоянным редиректом на релевантную страницу. Цепочки из нескольких редиректов сокращаются.
Этап 3. Проектирование WordPress-сайта
Миграция — возможность устранить ограничения старой системы, но не повод бездумно менять всё. Сначала создаётся новая карта сайта, прототипы и административная модель.
- типы страниц и записи;
- категории и таксономии;
- блоки Gutenberg;
- поля услуг, кейсов и сотрудников;
- меню и хлебные крошки;
- формы и согласия;
- поиск, фильтры и связанные материалы;
- роли редакторов и администраторов.
Новая административная панель должна учитывать работу команды. Если компания регулярно публикует кейсы и услуги, эти материалы оформляются как отдельные сущности, а не копируются вручную в произвольные страницы.
Этап 4. Перенос контента
Контент можно переносить вручную, через CSV/XML, API или специальный скрипт. Способ зависит от количества страниц и структуры исходных данных.
| Объём | Подход |
|---|---|
| До нескольких десятков страниц | Ручной перенос с редактурой и проверкой |
| Сотни однотипных материалов | Импорт с сопоставлением полей |
| Каталог товаров | CSV, API или обмен с учётной системой |
| Пользователи и заказы | Специальный скрипт и тестовая миграция |
| Сложные связи | Миграционный модуль с журналом ошибок |
Тексты и форматирование
Из старой CMS часто переносятся лишние стили, пустые теги и встроенные размеры. Контент нужно очистить и привести к блокам Gutenberg. Заголовки должны сохранять иерархию, а таблицы и списки — быть доступны на мобильных устройствах.
Изображения
Изображения загружаются в медиатеку WordPress, а не остаются ссылками на старый домен. Проверяются оригиналы, размеры, вес, подписи и alt-тексты. После смены адреса нельзя допускать смешанный контент и загрузку медиа с отключённого сервера.
Файлы
PDF, прайс-листы, инструкции и презентации тоже могут иметь поисковый трафик и внешние ссылки. Их адреса включают в карту миграции.
Этап 5. Перенос форм, аналитики и интеграций
Страница может выглядеть правильно, но перестать приносить заявки, если форма не связана с почтой или CRM. Поэтому каждая интеграция описывается и тестируется отдельно.
- формы заявок и уведомления;
- SMTP и доменная почта;
- CRM и источники лидов;
- Яндекс Метрика и цели;
- коллтрекинг;
- оплата и онлайн-касса;
- доставка;
- 1С и склад;
- карты, виджеты и внешние API.
После переноса проверяется не только факт отправки формы, но и все точки: письмо клиенту, письмо менеджеру, запись в CRM, цель аналитики и обработка ошибки.
Перенос WordPress на другой хостинг
Если CMS не меняется, задача состоит в переносе файлов, базы данных и конфигурации. Новый сервер должен поддерживать требуемые версии PHP, базы, HTTPS, cron и почтовую отправку.
- Создать полную копию файлов и базы данных.
- Подготовить новый сервер и тестовый адрес.
- Импортировать базу и файлы.
- Настроить wp-config.php и серверные параметры.
- Проверить сайт без переключения основного домена.
- Снизить TTL DNS при необходимости.
- Переключить домен на новый сервер.
- Проверить SSL, формы, cron, письма и интеграции.
- Сохранить старый сервер на период контроля.
Переключение DNS — последний шаг, а не начало миграции. Новый сервер должен быть проверен до того, как на него попадут реальные посетители.
Перенос WordPress на новый домен
Смена домена влияет на внутренние ссылки, канонические адреса, аналитику и поисковые сигналы. В базе WordPress встречаются сериализованные данные, поэтому простая замена текста через обычный SQL может повредить настройки.
- изменить Site Address и WordPress Address контролируемым способом;
- обновить внутренние ссылки и медиа;
- настроить постраничные 301-редиректы со старого домена;
- проверить canonical, sitemap и robots.txt;
- обновить аналитику, рекламные кабинеты и внешние сервисы;
- сохранить старый домен и SSL на период редиректов;
- контролировать ошибки и индексацию.
Старый домен нельзя отключать сразу после запуска. Он должен продолжать принимать запросы и перенаправлять их на новые страницы.
Как сохранить SEO
| Элемент | Что сделать |
|---|---|
| URL | Сохранить или настроить постраничный 301 |
| Title и Description | Перенести и улучшать только осознанно |
| H1–H3 | Сохранить смысловую структуру |
| Контент | Не сокращать важные разделы без причины |
| Внутренние ссылки | Обновить на конечные адреса |
| Canonical | Указать новые канонические URL |
| Sitemap | Сформировать карту только из индексируемых страниц |
| Robots | Открыть рабочий сайт и закрыть тестовые среды |
| Изображения | Перенести файлы и alt-тексты |
| Ошибки | Контролировать 404, 5xx и цепочки редиректов |
Позиции могут временно колебаться даже при корректном переносе. Важен не единичный день, а динамика индексации, трафика и ошибок. При смене дизайна нужно также следить за поведением пользователей и конверсией.
Тестовый контур и приёмка
Проверка до запуска
- все шаблоны страниц;
- десктоп и мобильные устройства;
- формы и письма;
- поиск и фильтры;
- мета-теги и URL;
- редиректы;
- скорость и ошибки.
Проверка после запуска
- DNS и SSL;
- аналитика в реальном трафике;
- CRM и интеграции;
- старые URL;
- 404 и 500;
- индексация карты сайта;
- реальные заявки.
Приёмка должна основываться на заранее согласованном чек-листе. Формулировка «перенести сайт» слишком общая: нужно указать количество страниц, типы данных, интеграции, сохранение URL и допустимый простой.
Что чаще всего теряется при миграции
- страницы, которых не было в меню;
- мета-теги и микроразметка;
- старые рекламные посадочные;
- PDF и изображения с внешними ссылками;
- формы и цели аналитики;
- пользовательские роли;
- заказы и статусы;
- cron-задачи;
- настройки почты;
- редиректы старой CMS;
- индивидуальные поля и связи между материалами.
Большинство этих потерь возникает не на этапе копирования, а из-за отсутствия инвентаризации. Поэтому сначала создаётся реестр данных, затем отмечается способ переноса и результат проверки.
Пример переноса на WordPress
В проекте Attractor Development старый некорректно работающий сайт с неудобной административной панелью был перенесён с ModX на WordPress. Одновременно переработаны структура, контент и дизайн, а управление полями адаптировано под работу клиента.
Другие проекты на WordPress, включая корпоративные сайты, каталоги и веб-сервисы, представлены в разделе кейсов JustBusiness.
Сколько занимает перенос
| Сценарий | Ориентир |
|---|---|
| WordPress на другой хостинг без смены домена | От одного дня после подготовки и тестирования |
| Небольшой сайт с другой CMS | От нескольких недель |
| Корпоративный сайт с редизайном | От 5–8 недель |
| Каталог или магазин | Зависит от объёма данных и интеграций |
| Смена CMS, домена и структуры одновременно | Индивидуальный план с расширенным SEO-контролем |
Срок определяется не количеством страниц в меню, а объёмом данных, шаблонов и функций. Миграция пользователей, заказов и связанного каталога требует нескольких тестовых прогонов.
Оценка переноса и поддержка после запуска
Перед началом миграции мы изучаем объём страниц, данные, интеграции и карту URL, после чего называем реальную трудоёмкость и срок. Клиент получает расчёт до запуска работ и самостоятельно принимает решение о старте.
| Работы после переноса | Условия |
|---|---|
| Разовые плановые задачи | 2 500 ₽ в час после предварительной оценки |
| Регулярное развитие | Пакет часов под ежемесячный объём с возможностью докупить часы |
| Внеочередные задачи | 2 800 ₽ в час |
| Срочные задачи на проекте, который мы ведём постоянно | Стараемся сохранить ставку 2 500 ₽ в час |
Статус задач и списанные часы отображаются в общей таблице. До начала каждой работы мы сообщаем ожидаемую продолжительность и дату готовности. Поддержку можно оформить договором абонентского обслуживания, а дополнительный объём — отдельным соглашением.
Конфиденциальность при миграции
При переносе команда получает доступ к базе данных, пользователям, заказам и интеграциям. Все специалисты JustBusiness работают в штате и имеют обязательства по защите персональных и чувствительных данных. Доступ получает только ограниченный круг сотрудников, участвующих в миграции.
Мы гарантируем качество миграционных работ по согласованному чек-листу: перенос данных, проверка функций, редиректы, формы, аналитика и контроль после запуска.
Частые вопросы
Можно ли перенести сайт с Tilda на WordPress?
Да. Обычно заново создаются тема и административная структура, а тексты и изображения переносятся как контент. Формы, анимации и интеграции реализуются средствами WordPress. Важно сохранить URL или настроить редиректы.
Можно ли перенести сайт с Joomla или ModX?
Да. Сначала изучаются типы материалов, категории, поля и расширения. Для большого объёма создаётся миграционный скрипт или импорт. Нестандартные функции разрабатываются отдельно.
Потеряются ли позиции после переноса?
Риск снижается, если сохранить важные URL, контент и мета-теги, настроить 301-редиректы, проверить внутренние ссылки и контролировать индексацию. Небольшие временные колебания возможны.
Можно ли перенести WordPress на другой хостинг без простоя?
Да. Новый сервер готовят и проверяют заранее, затем переключают DNS. Небольшой период расхождения возможен из-за обновления DNS, поэтому старый сервер сохраняют доступным на время перехода.
Нужно ли менять дизайн при переносе на WordPress?
Необязательно. Можно воспроизвести существующий интерфейс или провести редизайн. Но если меняется только CMS, сохранение привычной структуры уменьшает объём и риски.
Что делать со старыми URL?
Для каждого важного адреса нужно сохранить страницу или назначить релевантный новый URL с постоянным 301-редиректом. Все старые адреса проверяются после запуска.
Нужно ли переносить аналитику?
Да. Переносятся счётчики, цели, электронная коммерция и рекламные метки. После запуска выполняется тестовая заявка или покупка, чтобы подтвердить передачу событий.
Можно ли перенести только часть сайта?
Да. Например, блог или каталог можно перенести поэтапно. Но потребуется продумать навигацию, домены, канонические адреса и взаимодействие двух систем в переходный период.
Итог
Перенос сайта на WordPress — это управляемая миграция данных, функций и поисковых сигналов. Техническое копирование файлов является только частью процесса. Основную безопасность дают инвентаризация, карта URL, тестовый контур и контроль после запуска.
Если перенос выполняется с редизайном, важно отделять обязательное сохранение от осознанных улучшений. Тогда новая версия получает удобную CMS и современный интерфейс, не теряя накопленный контент, заявки и трафик.


