Перенос WordPress со staging на production — это больше, чем копирование файлов. После смены домена могут остаться абсолютные URL, noindex, старые canonical, тестовые API-ключи, неверные cron-задачи и лицензия, привязанная к staging. Хорошая миграция заканчивается не загрузкой базы, а системной проверкой нового сайта.
Что такое staging
Staging — отдельная копия сайта для разработки и проверки обновлений. Она может находиться на поддомене, временном домене или закрытом окружении хостинга.
Главная ценность staging — возможность менять тему, плагины и структуру без риска для публичного проекта. Но staging не должен случайно стать индексируемой копией основного сайта.
Перед переносом сделайте полный backup
Экспорт настроек темы не заменяет резервную копию WordPress. Для полного клона нужны база данных, wp-content, медиатека и конфигурация окружения.
Лучше иметь точку восстановления и на staging, и на production перед заменой существующего сайта.
Проверьте, что именно переносите
Есть два разных сценария:
- полный clone — переносится вся база и файлы;
- configuration migration — production уже содержит контент, а вы переносите настройки темы, меню и отдельные параметры.
Смешивание сценариев приводит к неожиданным перезаписям. Для BetCraft Migration Center предназначен прежде всего для управляемого переноса конфигурации поверх корректно клонированного WordPress.
Абсолютные URL
После смены домена старый staging URL может остаться в контенте, меню, виджетах, affiliate-полях и настройках. Простая строковая замена всей базы опасна из-за сериализованных данных и служебных значений.
Безопаснее ограничить замену известными областями и сначала выполнить preview: сколько совпадений найдено и где именно.
Не заменяйте внешние affiliate-ссылки без причины
Domain Replace должен отличать собственный staging-домен от внешнего URL партнёрской программы. Массовая замена внутри каждой ссылки без фильтра способна испортить отслеживание.
После миграции отдельно проверьте основные CTA и несколько redirect URL вручную.
Canonical, robots и sitemap
До запуска убедитесь, что production больше не содержит canonical на staging. Проверьте robots.txt, настройки «Видимость для поисковых систем» и sitemap.
Если staging был закрыт через noindex, эта настройка не должна случайно остаться на публичном домене. И наоборот: тестовую копию после запуска нельзя оставлять открытой для индексации.
301 со старого публичного домена
Если миграция одновременно меняет уже индексируемый основной домен, потребуется отдельный план 301-редиректов URL-to-URL. Это не то же самое, что замена staging-домена в базе.
Для смены публичной структуры полезен отдельный Redirect Center. Он помогает контролировать 404 и старые адреса после запуска.
Лицензия
Коммерческая тема может учитывать активированный домен. Поэтому staging и production нужно переносить по правилам конкретной лицензии: при необходимости деактивировать старую активацию и активировать ключ на конечном домене.
Сам migration bundle не должен содержать секретный site token или автоматически переносить лицензионные данные между сайтами.
API-ключи и секреты
Sports API, SMTP, аналитика и другие интеграции могут использовать разные ключи на staging и production. Такие секреты лучше хранить отдельно от переносимого JSON-конфига.
После миграции проверьте каждый внешний сервис и убедитесь, что production не продолжает отправлять тестовые данные в sandbox.
WP-Cron и фоновые задачи
На staging cron часто отключают или ограничивают, чтобы тестовая копия не отправляла письма и не импортировала реальные данные. На production нужно вернуть нужный режим.
Проверьте Sports API, Feed Manager, напоминания, очистку логов, уведомления и другие фоновые процессы.
Тестовый сайт может использовать mail-catcher или полностью блокировать исходящие письма. После запуска отправьте реальное тестовое сообщение и проверьте SMTP, From, SPF/DKIM на стороне почтовой инфраструктуры, если они используются.
PWA, Service Worker и кэш
Service Worker способен кэшировать старые assets и URL. После смены домена или крупного обновления очистите серверный/CDN-кэш и проверьте PWA в чистом браузере.
Не ориентируйтесь только на сессию администратора: у неё часть кэша может вести себя иначе.
Community и пользовательские данные
Если форум уже содержит реальные темы и профили, нужно понимать, где находится источник истины. Нельзя бездумно заменить production-базу более старой staging-копией и потерять новые сообщения пользователей.
На активном проекте конфигурационные изменения лучше переносить отдельно от пользовательского контента.
Финальная проверка после миграции
- открывается главная и ключевые коммерческие страницы;
- нет хвостов старого staging URL;
- лицензия активна на production;
- меню и Homepage Builder работают;
- affiliate-кнопки ведут на правильные URL;
- REST API отвечает;
- WP-Cron работает;
- email отправляется;
- Consent Center и аналитика настроены;
- PWA и Community доступны;
- нет новых массовых 404;
- индексация включена только там, где нужна.
Migration Center в BetCraft
В BetCraft Migration Center создаёт переносимый bundle настроек, умеет восстановить поддерживаемые меню/виджеты, выполнить безопасный preview Domain Replace и сформировать Final Migration Report.
Дополнительно можно сгенерировать child theme для кастомных CSS/PHP-изменений, чтобы они не зависели от обновления родительской темы. Подробная последовательность описана в документации.
Частые вопросы
Migration bundle заменяет полный backup?
Нет. Он переносит поддерживаемую конфигурацию BetCraft. База, медиатека, пользователи и контент требуют обычного backup/clone-механизма.
Можно ли сделать search/replace по всей БД?
Можно специальными инструментами, которые корректно работают с сериализованными данными, но слепая строковая замена SQL опасна. Для типового переноса лучше менять только нужные области и проверять результат.
Когда открывать индексацию?
После проверки production URL, canonical, sitemap, ключевых страниц, редиректов и отсутствия критических ошибок. До этого сайт лучше считать ещё не запущенным.