Перенос WordPress на новый хостинг без простоя

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

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

Что вы на самом деле переносите#

Пять вещей, и только первые две выносит плагин для миграции.

• Файлы. wp-content - это та часть, которая ваша: themes, plugins, uploads и нередко папка mu-plugins, о существовании которой все забыли. Файлы ядра можно просто скачать заново с wordpress.org на новом месте: незачем копировать 60 МБ файлов, которые можно получить за секунду.
• База данных. Все таблицы с вашим префиксом. Записи, настройки, пользователи и любые таблицы, созданные плагинами: магазин или форум хранит большую часть данных в таблицах, о которых ядро ничего не знает.
• `wp-config.php`, который вы копируете для справки, а потом переписываете. Учётные данные базы на новом хостинге будут другими, и использование старых - самая частая причина, по которой только что перенесённый сайт показывает ошибку подключения к базе данных.
• Всё, что находится вне WordPress. Правила редиректов в .htaccess или в конфигурации сервера, задания cron, которые за вас выполнял старый хостинг, вручную отредактированный robots.txt, списки разрешённых IP, ключ API для SMTP в настройках плагина.
• DNS и сертификат. Тот, кто держит зону, продолжает её держать; меняются только записи. Если старый хостинг был ещё и вашим DNS-провайдером или регистратором, разберитесь с этим до дня переноса, а не во время него: какую из трёх сторон вы на самом деле переносите, объясняет статья неймсерверы или DNS-записи.

Запишите этот список. Перенос, который ломается неделю спустя, почти всегда ломается на четвёртом пункте.

Выберите метод и сначала оцените размер сайта#

Перед выбором проверьте два числа: размер wp-content и размер базы данных. В панели или по SFTP это размер папки и размер таблиц в phpMyAdmin.

Плагины для миграции действительно хороши на маленьких сайтах и действительно ненадёжны на больших, по скучной причине: они работают внутри запроса PHP, поэтому действуют max_execution_time и memory_limit, а папка uploads в 3 ГБ не помещается в запрос на 30 секунд. Сбой обычно тихий: архив усечён, но выглядит целым. Если сайт большой, делайте вручную; у ручного пути ниже нет размерного предела, о котором стоило бы говорить.

Спланируйте окно и снизьте TTL#

У DNS-записей есть время жизни, которое говорит резолверам, как долго помнить ответ. Если у вашей A-записи TTL равен 86 400 секундам, некоторые резолверы будут отправлять посетителей на старый сервер целые сутки после того, как вы её изменили.

1. За два дня до: снизьте TTL записей, которые будете менять, - apex и www - до 300 секунд. Делать это нужно заранее, чтобы старый длинный TTL успел истечь везде.
2. Проверьте, что сработало. dig +noall +answer example.com печатает запись с оставшимся TTL. Он должен отсчитываться от 300, а не от большего числа.
3. Выберите час. Самый тихий час по часовому поясу ваших посетителей, а не вашему. Посмотрите в аналитике, а не гадайте.
4. Решите, что замораживается. Для блога ничего: потерянный комментарий - это переживаемо. Для магазина или сайта с подпиской переведите старый сайт в режим обслуживания на десять минут между финальным экспортом базы и сменой DNS и скажите об этом на странице.
5. Оставьте старый хостинг оплаченным ещё на две недели. Это план отката, и он стоит меньше, чем инцидент.

Если что-то из этого незнакомо, что делает каждый тип записи, разобрано в статье DNS-записи простыми словами, а www или apex: домен и редиректы важна здесь потому, что оба имени должны одновременно оказаться на новом хостинге.

Скопируйте файлы#

Если есть доступ к shell на обоих концах, заархивируйте на стороне сервера и перенесите один файл:

$ cd /var/www/example.com$ tar -czf /tmp/wp-content.tar.gz wp-content$ scp /tmp/wp-content.tar.gz user@new-host:/tmp/

Без доступа к shell сделайте то же через файловый менеджер: создайте архив wp-content на старом хостинге, скачайте один файл, загрузите на новый и распакуйте на месте. Скачивание 40 000 мелких файлов по SFTP занимает часы; скачивание одного архива в 800 МБ занимает минуты, и весь фокус в этой разнице. Параметры подключения есть в статье SFTP и файловый менеджер.

Оставьте то, что вам не нужно:

• Каталоги кэша: wp-content/cache, wp-content/et-cache, всё, что создал плагин кэширования. Всё это создаётся заново, а устаревшие файлы кэша - хороший способ продолжать отдавать старые URL после переноса.
• Архивы плагинов для бэкапа внутри wp-content. Часто это самое большое, что есть на диске, и это копии сайта, который вы и так копируете.
• Файлы error_log, которые могут быть огромными и ничего не скажут вам на новом сервере.

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

Перенесите базу данных#

С доступом к shell - дамп и загрузка:

$ mysqldump --single-transaction --default-character-set=utf8mb4 \    --add-drop-table -u olduser -p olddb > site.sql$ gzip site.sql

На новом хостинге сначала создайте базу и пользователя, затем импортируйте. Через phpMyAdmin та же работа - это Export, затем Custom, затем опция gzip, а на другом конце Import. Три детали решают, будет ли импорт чистым:

• `utf8mb4` от начала до конца. Экспортируйте и импортируйте в одной и той же кодировке, иначе буквы с диакритикой и эмодзи приедут в виде кракозябр. Поиск и замена потом этого не исправят.
• `--single-transaction` делает согласованный снимок без блокировки сайта, что важно, если вы снимаете дамп с загруженной базы.
• Лимиты размера импорта. Импорт через phpMyAdmin идёт через PHP, поэтому действуют upload_max_filesize, post_max_size и max_execution_time. Сжатый gzip-дамп обычно в четыре-восемь раз меньше и нередко решает, сработает ли всё. Если и он не помещается, разбейте дамп или поднимите лимиты: какие именно, описано в статье настройки php.ini, которые важны, а сторона панели - в руководстве по импорту и экспорту в phpMyAdmin.

На RE:NODE тарифы для сайтов включают два слота баз данных, создаваемых из панели со сгенерированными хостом, пользователем и паролем. Кнопка Open in phpMyAdmin входит в систему по одноразовому токену, срок действия которого истекает через шестьдесят секунд, так что дамп можно импортировать во вкладке браузера, ни разу не вводя учётные данные в форму. Впишите в wp-config.php эти новые учётные данные, а не старые.

Search and replace - шаг, который ломает сайты#

База данных полна абсолютных URL: siteurl и home в таблице options, каждый src изображения в содержимом записей, настройки виджетов и темы, конфигурация плагинов. Если меняется домен или вы переходите с http на https, всё это нужно переписать.

Не делайте это через SQL. Это самая вредная ошибка при переносе WordPress:

-- Do not do this. It corrupts every serialised setting in the table.UPDATE wp_options SET option_value = REPLACE(option_value, 'old.com', 'new.com');

WordPress хранит массивы и объекты как сериализованные строки PHP, в которых записана длина в байтах каждого значения. Замените old.com на newsite.com внутри такой строки, и сохранённая длина перестанет совпадать, так что PHP не сможет её десериализовать, а плагин или виджет молча вернётся к значениям по умолчанию. Пропадают настройки темы, пустеют меню, ломаются слайдеры, и ущерб проявляется через несколько дней, когда вы давно перестали подозревать перенос.

Используйте инструмент, который понимает сериализацию. С WP-CLI:

$ wp search-replace 'https://old.example.com' 'https://example.com' \    --all-tables --precise --dry-run$ wp search-replace 'https://old.example.com' 'https://example.com' --all-tables

Сначала запустите пробный прогон, прочитайте таблицу с числом замен, потом запускайте по-настоящему. Без доступа к shell ту же работу из админки делает плагин Better Search Replace, у которого тоже есть режим dry-run. Отдельный скрипт Search Replace DB тоже подходит, но с одним правилом: удалите его сразу, как закончите. Скрипт, переписывающий вашу базу и лежащий по угадываемому адресу, - это готовая компрометация, ждущая, пока её найдут.

Если изменился и путь в файловой системе - /home/olduser/public_html на что-то другое, - ищите и старый путь. Горстка плагинов хранит абсолютные пути, и они сбоят непонятным образом, когда пути больше нет.

Проверьте до того, как трогать DNS#

Просматривать новый сайт под его настоящим доменным именем можно, ничего не меняя публично: достаточно сказать своей машине, куда смотреть. Добавьте одну строку в файл hosts - C:\Windows\System32\drivers\etc\hosts в Windows, /etc/hosts в macOS и Linux:

203.0.113.25    example.com www.example.com

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

Пройдитесь по настоящему чек-листу, а не просто взглянув на главную страницу:

• Главная страница, запись, архив рубрики, страница с формой и результаты поиска.
• /wp-admin: войдите, откройте экран плагинов, убедитесь, что ничто не сообщает об отсутствующей таблице.
• Постоянные ссылки: откройте любой URL, кроме главной. 404 на каждой странице, кроме главной, означает, что правила перезаписи ещё не на месте.
• Изображения: откройте запись с медиа и убедитесь, что файлы загружаются с нового хостинга.
• Магазин: корзина, оформление заказа до шага оплаты и один тестовый заказ в песочнице платёжного шлюза.
• Всё, что идёт по расписанию: запустите событие cron вручную и посмотрите, что оно выполняется.

Когда закончите, удалите запись из hosts. Если оставить её, через месяцы вы окажетесь единственным человеком на свете, который не видит, что сайт лежит.

Само переключение#

Когда TTL равен 300 секундам, а новый сайт проверен, переключение короткое.

1. Переведите старый сайт в режим обслуживания или просто примите риск, если ничего не пишется.
2. Экспортируйте базу ещё раз и импортируйте поверх копии на новом хостинге. Этот второй проход обычно занимает несколько минут и ловит всё, что записано с момента первой копии. Новые загрузки синхронизируйте так же.
3. Заново выполните search-replace на свежем импорте. Это новая копия данных, и старые URL в ней вернулись.
4. Смените A-запись для apex и для www на новый адрес. Больше ничего в зоне не меняйте: записи MX остаются на месте, и именно это сохраняет работу почты.
5. Следите за консолью или access-логом нового хостинга. Трафик должен появиться через минуту-две и расти по мере того, как резолверы теряют закэшированные ответы.
6. Оставьте старый сайт в режиме обслуживания, а не удаляйте. Это ваш откат, и он не даёт отставшим писать в базу, которую вы бросаете.

У сертификата есть проблема порядка, которую стоит ожидать. Выпуск проверяет, что имя действительно указывает на запросивший сервер, поэтому сертификат для example.com обычно нельзя выпустить на новом хостинге, пока DNS уже не указывает на него. Это окно от секунд до минут между сменой записи и появлением сертификата, в течение которого посетитель может увидеть предупреждение. На RE:NODE это решает слот прокси: направьте A-запись на адрес с этой вкладки, и сертификат выпускается, как только имя начинает разрешаться, а затем продлевается автоматически в окне в 21 день. Сама проверка разобрана в статье HTTPS и Let's Encrypt простыми словами.

После переключения и что идёт не так#

В течение первого часа: заново сохраните постоянные ссылки в настройках, чтобы пересоздать правила перезаписи, проверьте HTTPS на нескольких URL, отправьте тестовое письмо из формы обратной связи и убедитесь, что отложенные записи и события cron срабатывают. В течение первой недели: следите за 404 на URL, о существовании которых вы не знали, и ещё раз проверьте search console на ошибки обхода.

Повторяющиеся сбои и то, что каждый означает:

Error establishing a database connection. В wp-config.php всё ещё учётные данные старого хостинга, либо DB_HOST равен localhost, а нужно настоящее имя хоста.

Сайт перенаправляет на старый домен. siteurl и home в таблице options не были переписаны. Временно переопределите их через WP_HOME и WP_SITEURL в wp-config.php, а потом как следует исправьте базу.

Предупреждения о смешанном контенте. В содержимом записей остались старые URL с http://. Заново выполните search-replace для схемы, а не только для имени хоста.

Пустые меню, сброшенные настройки темы. Сериализованные данные испорчены простой заменой в SQL. Восстановите базу до этого шага и повторите нормальным инструментом. Частичного исправления не существует.

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

Пропадает почта. Почта не следует за веб-сервером. Записи MX остаются у вашего почтового провайдера, а транзакционной почте сайта нужен SMTP-плагин, настроенный на провайдера, который вас аутентифицирует: RE:NODE почту не хостит, так что учтите это заранее, а не обнаруживайте потом. Почему записи по-прежнему важны после переезда, объясняет статья SPF, DKIM и DMARC простыми словами.

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

FAQ#

Сколько занимает перенос WordPress?

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

Будет ли сайт недоступен во время переезда?

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

Можно ли переехать без смены домена?

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

Использовать плагин для миграции или делать вручную?

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

Что делать со старым хостингом?

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

Нужно ли сообщать поисковым системам, что сайт переехал?

Если домен не менялся, нет: они этого не заметят, и не должны. Если домен изменился, оставьте старый домен живым с редиректами 301 на соответствующие URL нового и держите их не меньше года.