Переезд с WordPress на Payload CMS: что происходит с контентом и ссылками

Что происходит при переезде на самом деле

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

Я собирал такой каркас для million-estate.com: Next.js 15 (App Router, TypeScript) со встроенным Payload CMS 3 на PostgreSQL 16. Сайт и админка — одно приложение, один контейнер, один деплой. Локализация RU/EN включена в конфиге, RU по умолчанию. Для дальнейшей работы это удобно, но контент всё равно переносится отдельным этапом.

Откуда забирать контент

Первый путь — доступ в админку WordPress. Тогда у вас есть экспорт, оригиналы из медиатеки и значения кастомных полей. Лучший сценарий, качество исходников максимальное.

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

Именно на этом у меня встал этап переноса контента: без доступа к WP-админке остаётся парсинг, и фото получаются слабее. Если затеваете переезд — запросите доступ заранее, до начала работ.

Как контент ложится в коллекции

Первым делом старый сайт разбирается по типам содержимого. Статьи, страницы, мероприятия, экспертизы, люди — каждый тип превращается в коллекцию Payload со своим набором полей. Мешанина из «страниц с шорткодами» в этот момент становится структурированными данными, и это главная выгода переезда.

Мелочи, которые всплывают на этом шаге:

• шорткоды и блоки Gutenberg надо переводить в блоки Payload или в обычную разметку;
• внутренние ссылки внутри текстов обычно абсолютные и ведут на старый домен — их надо переписывать;
• галереи и вложения превращаются в связи с коллекцией media;
• при включённой локализации сразу решите, что считается переводом, а что отдельной сущностью.

Медиа: пережать сразу

Перенос медиа — хороший момент, чтобы разом закрыть вопрос веса страниц. В моих критериях приёмки это отдельный пункт: медиа перенесены и пережаты в WebP/AVIF. Next.js умеет отдавать современные форматы сам, но исходники в библиотеке лучше держать уже нормального размера — тогда вы не платите за конвертацию на каждом запросе и не тащите в новый проект гигабайты старых JPEG.

Ссылки: структуру сохранить, изменённое закрыть 301

Это та часть, где переезд чаще всего ломает трафик. Правило простое: URL-структура сохраняется как есть. Всё, что изменилось, закрывается 301-редиректом со старого адреса на новый.

Что проверить отдельно:

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

Дальше служебные файлы. sitemap.xml, robots.txt и JSON-LD (Organization, Event, Article) собираются заново на стороне Next.js. robots на проекте выглядит так:

User-agent: *
Allow: /
Disallow: /cabinet/

Sitemap: https://million-estate.com/sitemap.xml

Закрытый кабинет — обязательный пункт: личные разделы в индексе никому не нужны.

Проверка руками после переключения

Автотесты сюда не дотягиваются, поэтому сайт проходится целиком. На million-estate.com обход дал 40 внутренних адресов на 15 страницах — все отвечают 200, битых нет. Отдельно проверяются якоря (#accreditation, #concierge, #upcoming, #past, #main): находят ли они свои цели. У внешних ссылок — target="_blank" и rel="nofollow noopener".

Интерактив проверяется тем же проходом: вкладки «Экспертизы» переключают панели, фильтры графика мероприятий отдают правильные выборки (7 предстоящих, 1 прошедшее), стрелки слайдеров листают, кнопки «Поделиться» подставляют адрес текущей страницы. После переезда именно это ломается тихо: вёрстка на месте, обработчик потерялся.

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

• все страницы наполнены;
• медиа перенесены и пережаты в WebP/AVIF;
• URL-структура сохранена, на изменённое стоят 301;
• sitemap.xml, robots.txt и JSON-LD на месте;
• внутренние ссылки и якоря отвечают 200;
• кабинет закрыт от индексации;
• мобильная вёрстка проверена руками.

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