Безопасный перенос сайта WordPress

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

Что необходимо подготовить

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

Проверьте, где расположен корень WordPress. В нём обычно находятся каталоги wp-admin, wp-content, wp-includes и файл wp-config.php. Каталог wp-content особенно важен: в нём хранятся загруженные изображения, темы, плагины и другие элементы, добавленные сайтом. Файл wp-config.php содержит параметры подключения к базе и дополнительные настройки, поэтому его нужно сохранить отдельно и не публиковать в открытом доступе.

Зафиксируйте версии PHP, СУБД и ключевых расширений, используемых на старом сервере. На новой площадке желательно начать с совместимых версий, а обновление выполнять уже после успешного переноса. Также запишите настройки веб-сервера, SSL-сертификата, планировщика задач, кэширования и почты, если сайт ими пользуется.

Резервная копия перед переносом

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

Затем экспортируйте всю базу данных сайта. Формат SQL удобен для последующего импорта и проверки содержимого. Если панель хостинга предлагает экспорт с выбором кодировки, используйте UTF-8 и сохраните параметры таблиц. Имя базы, пользователя и пароль из старого wp-config.php можно записать в отдельную защищённую заметку, но не включать в публичные документы или систему контроля версий.

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

Проверить подходящий вариант можно на странице Beget.

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

Перенос файлов и базы данных

На новом сервере создайте базу данных и пользователя с правами, достаточными для работы WordPress. Импортируйте SQL-файл в созданную базу. Если панель ограничивает размер загружаемого файла, используйте предусмотренный хостингом инструмент импорта или консольный способ, доступный в документации провайдера.

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

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

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

Замена адреса сайта

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

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

Перед настройкой откройте Beget и сверьте актуальные условия.

После замены адресов очистите кэш WordPress, кэш плагинов, серверный кэш и кэш CDN, если они используются. В разделе постоянных ссылок сохраните текущую структуру ещё раз, чтобы WordPress обновил правила маршрутизации. Если после этого главная страница открывается, а внутренние страницы возвращают ошибку, проверьте файл правил веб-сервера и настройки виртуального хоста.

Проверка сайта перед переключением

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

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

Проверьте права доступа к файлам и каталогам в соответствии с политикой нового хостинга. Конфигурационные файлы не должны быть доступны для скачивания из браузера. Убедитесь, что HTTPS работает без предупреждений, изображения и скрипты загружаются по защищённому протоколу, а перенаправление с HTTP настроено ожидаемым образом.

Сравните несколько URL старого и нового сайта. Проверьте канонические адреса, ссылки в меню, карту сайта, robots.txt и редиректы. Если менялся домен, подготовьте перенаправления со старых URL на соответствующие новые страницы, а не только на главную.

Переключение домена и контроль после запуска

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

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

Когда требования понятны, перейдите в Beget и проверьте выбранный вариант.

В первые часы после переключения контролируйте журнал ошибок, доступность главной страницы и внутренних URL, загрузку изображений, отправку почты и работу административной панели. Проверьте сайт из нескольких сетей и с мобильного устройства. Если часть DNS-кэшей ещё не обновилась, результаты могут отличаться.

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

Частые проблемы после переноса

Белая страница или ошибка сервера чаще всего связаны с несовместимой версией PHP, неисправным плагином, неверными правами доступа или ошибкой в конфигурации. Начните с журнала ошибок нового сервера и временно отключите проблемное расширение через файловую систему, если административная панель недоступна.

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

Отсутствующие изображения обычно указывают на неполный перенос wp-content/uploads или на неправильный путь к файлам. Ошибки внутренних страниц часто возникают из-за неактуальных правил постоянных ссылок или неверной настройки веб-сервера. Если сломались отдельные виджеты, формы или платёжные функции, сравните настройки расширений и переменные окружения на старой и новой площадке.

Если сайт работает, но посетители всё ещё видят старую версию, проверьте DNS, CDN и кэш браузера. Не выполняйте повторный перенос вслепую: сначала определите, какой сервер отвечает на конкретный запрос, и только потом корректируйте записи или кэширование.

Что почитать дальше

Обложка вдохновлена работой Эль Лисицкого «Проун 19D» (1922). Посмотреть оригинал в Wikimedia Commons.