Перейти к основному содержимому

Разработка 23 октября 2026г. 9 мин чтения

Переезд на WordPress с другой CMS: что ломается

Наш сайт Сайты2.рф переехал с Grav на WordPress в июле 2026 года, и почти всё, что мы рассчитывали получить бесплатно вместе с переносом, пришлось доделывать руками: у статей поехали даты, часть страниц задвоила текст, картинки не подгрузились в библиотеку, а несколько внутренних ссылок стали битыми. Разбираем каждую поломку по отдельности и что с ней делать, чтобы чужой переезд прошёл быстрее нашего.

Наш сайт Сайты2.рф переехал с Grav на WordPress в июле 2026 года, и почти всё, что мы рассчитывали получить бесплатно вместе с переносом, пришлось доделывать руками: у статей поехали даты, часть страниц задвоила текст, картинки не подгрузились в библиотеку, а несколько внутренних ссылок стали битыми. Разбираем каждую поломку по отдельности и что с ней делать, чтобы чужой переезд прошёл быстрее нашего.

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

Мы прошли этот путь на своём сайте: сотня статей блога, десяток кейсов, отраслевые страницы, сравнения систем и глоссарий на шестьдесят с лишним терминов. Дальше - что сломалось и как это проверяют.

Что снять со старого сайта до переезда, а не после

Три вещи снимают до того, как контент тронут.

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

Список адресов. Полный перечень URL старого сайта: разделы, страницы, товары, теги - без него не проверить, что каждый адрес отвечает кодом 200 или редиректит. Собирают из карты сайта, логов сервера и отчёта поисковой системы: источники редко совпадают, и расхождение показывает забытые страницы.

Замер позиций и скорости. Снимок позиций по основным запросам и скорости ключевых страниц - без него падение после переезда нельзя ни доказать, ни опровергнуть. Логику замера "до" разбирали в статье про редизайн без потери позиций.

Что CMS переносит сама, а что делаем руками

Мы писали про похожий, но другой случай - перенос сайта с Тильды: там обычного экспорта нет, контент вытаскивают вручную. Здесь обе системы обмениваются контентом штатно, и теряется то же самое.

Автоматически приходит то, что хранилось как обычный текст: заголовки, тело статей, категории, слаги, даты - если их передать в настройках импортёра. Что собиралось логикой шаблона, переносить дороже: сначала это нужно обнаружить.

Переносится само Обычно приходится руками
Текст статьи и заголовок Загрузка картинок в библиотеку файлов
Даты публикации (при настройке импортёра) Мета-теги и структурированная разметка
Категории и теги Редиректы со старых адресов
Слаги (адреса страниц) Формы и их обработчики
Комментарии, если они были Настройки кэша и производительности

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

Три неожиданности с контентом: даты, задвоенные блоки и картинки

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

Задвоенный контент. У нас часть страниц (сравнения систем управления) собиралась не из тела записи, а из отдельных полей: цена, сроки, плюсы, минусы, а тело держали пустым - шаблон брал данные из полей. При переносе тело вернулось вместе с полями, и страница стала печатать одно и то же дважды. Находят такое по длине текста записи: если она заметно больше похожих страниц, там задвоение.

Пропавшие картинки. Изображения не попали в библиотеку файлов новой системы: ссылки указывали на старые пути, а миниатюры оказались пустыми у всех перенесённых записей. Карточка в ленте, картинка при репосте - всё, что опиралось на миниатюру, показывало пустоту. Чинится массовой заливкой файлов с привязкой к записям.

Ссылки, которые вели в никуда, и правки, которые чуть не наделали проблем

Битые внутренние ссылки. Часть страниц старого сайта ссылалась на разделы, которых на новом ещё не завели - например, лендинги под рекламные кампании. Ссылки продолжили работать синтаксически, но стали вести в никуда: похожая механика - в статье про 301 редирект.

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

Сверка адресов и редиректы: почему список нужен до переезда

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

Дальше построчная сверка: каждый старый адрес получает точный аналог на новом сайте или редирект 301 на ближайшую по смыслу страницу. Адреса без аналога - удалённый раздел, товар, снятый с продажи навсегда - отдают код ошибки, а не редиректят на главную: поисковики читают такой редирект как попытку скрыть исчезновение страницы. Подробнее - у Google Search Central.

Если переезд CMS совпал с переездом на другой сервер, добавляется отдельный слой проверок от DNS до сертификата - разбирали его в статье про перенос на другой хостинг.

Проверка после переезда: карта сайта, robots, формы, письма

Дальше проверяют не контент, а служебные механизмы сайта.

Карта сайта и robots.txt. Новая система генерирует карту сайта по новым адресам - её нужно отправить в Яндекс.Вебмастер заново. Файл robots.txt проверяют отдельно: в нём легко унаследовать запрет на индексацию служебных разделов, которые в новой системе называются иначе.

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

Расхождение сервера и репозитория. У нас нашлась своя мелочь: служебный тег подтверждения прав на сайт когда-то добавили прямо на сервере и не занесли в код - обычная выкладка темы тихо снесла бы его. С тех пор сверяем все файлы на сервере с репозиторием перед выкладкой, а не только те, что правили: расхождение в нетронутом файле значит чужую правку на проде, и её нужно забрать себе.

Сколько идёт переезд и когда он не нужен вовсе

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

Переезд не нужен, если проблема в другом: сайт медленный из-за тяжёлых картинок, а не системы управления; редактору неудобно, потому что его не обучили; нет заявок из-за отсутствия трафика, а не из-за неудобной формы. В таких случаях перенос решит проблему разве что случайно.

Чек-лист приёмки после переезда

Порядок проверок, которым пользуемся сами:

  • Полная копия старого сайта снята и хранится отдельно от рабочей среды.
  • Список всех адресов старого сайта собран из карты сайта, логов и панели вебмастера.
  • Позиции по основным запросам и скорость ключевых страниц замерены до переноса.
  • Даты публикации статей проверены на осмысленность, а не только на факт наличия.
  • Страницы, которые раньше собирались из отдельных полей, проверены на дублирование контента.
  • Все изображения на месте, у записей есть миниатюры.
  • Внутренние ссылки прогнаны через проверку на битые адреса.
  • Каждый старый адрес получил аналог на новом сайте или редирект 301.
  • Новая карта сайта отправлена в панель поисковика.
  • Robots.txt проверен на актуальность запретов.
  • Формы, оплата и автоматические письма проверены вручную, а не визуально.
  • Файлы на сервере сверены с репозиторием перед финальной выкладкой.

Что мы теперь снимаем со старого сайта в первую очередь

Из полутора десятков переездов для клиентов после собственного, самый дорогой урок оказался простым: список адресов и точку отсчёта по позициям и скорости снимают до того, как контент тронут. Остальные поломки - даты, дубли, пропавшие картинки, битые ссылки - находятся дольше, но чинятся быстрее, если заранее знать, где искать. Перенос CMS редко ломается в одном месте - обычно сразу в десятке мест.

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

Частые вопросы

Сколько стоит перенос сайта на WordPress с другой CMS?

Порядка 60 000-300 000 рублей в зависимости от объёма контента и того, сколько страниц собиралось нестандартной логикой шаблона, а не обычным текстом. Простой сайт на полсотни страниц переносится дешевле сайта на несколько сотен с кейсами, сравнениями и глоссарием.

Можно ли перенести сайт на другую CMS без потери позиций в поиске?

Можно, если список старых адресов снят до переноса и на каждый настроен либо точный аналог, либо редирект 301. Просадка обычно случается не из-за смены системы, а из-за забытых адресов и отложенной настройки редиректов.

Что делать, если после переезда пропали картинки или задвоился текст на части страниц?

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

Нужно ли останавливать старый сайт на время переезда?

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

Нужен сайт по этой теме?

Расскажите о задаче – вернёмся с расчётом и предложением структуры.