Как я переезжал с хостинга на хостинг: All-in-One WP Migration

Миграция WordPress на новый хостинг — это всегда стресс. Я переезжал дважды: с дешёвого хостинга на VPS и с одного VPS на другой. Оба раза что-то шло не так.

Первый раз просто скопировал файлы через FTP и дамп БД через phpMyAdmin. В итоге ссылки в базе остались старые, пришлось через Better Search Replace менять. Плюс права на файлы сбились — сайт выдавал 403.

Второй раз использовал плагин All-in-One WP Migration. Сделал экспорт, залил на новый сервер, импорт. Всё! Плагин сам меняет ссылки в базе, переносит файлы, настраивает. Единственное: на бесплатном тарифе лимит 512MB. Для блога хватит, для магазина с фотками — нет.

Ещё способ: через WP-CLI. Если сервер позволяет — wp db export и wp db import. Профессиональный подход, но требует доступа к SSH. Я так и делаю сейчас.

Главный совет: перед миграцией сделайте бекап. Не поленитесь. Если что-то пойдёт не так — откат за 5 минут.

Больше статей про WordPress — от установки до продвижения — я собрал в сводном гайде.

Расскажу эту историю подробнее, потому что миграция WordPress — это то, через что рано или поздно проходит каждый, кто серьёзно ведёт сайт. Я переезжал дважды, оба раза по-разному, и оба раза получил ценный опыт. Надеюсь, мой рассказ поможет тебе избежать ошибок, на которых я спотыкался.

Начну с первого переезда — он был самым наивным. Я переезжал с дешёвого хостинга на VPS и думал, что всё просто: скопировать файлы, перенести базу, готово. Скопировал файлы через FTP, выгрузил дамп базы через phpMyAdmin. И тут началось. Ссылки в базе остались старые — вместо нового домена или IP везде стоял старый адрес. Пришлось лезть в базу и менять ссылки через Better Search Replace. Это решило проблему со ссылками, но добавило новую: права на файлы сбились, и сайт начал выдавать ошибку 403. Пришлось разбираться с правами и владельцем файлов. Куча времени, нервов, а ведь я думал, что «просто скопирую».

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

Второй переезд был на другой VPS, и тут я решил попробовать плагин All-in-One WP Migration. И это было откровение. Я сделал экспорт сайта в файл, залил его на новый сервер, установил там чистый WordPress, запустил плагин и сделал импорт. Всё! Плагин сам меняет ссылки в базе, переносит файлы, настраивает. Мне не пришлось вручную править ничего. Миграция, на которую в первый раз у меня ушёл вечер, заняла полчаса и прошла без единой ошибки. Вот это я понимаю — инструмент.

Про ограничения All-in-One WP Migration нужно сказать честно. На бесплатном тарифе лимит экспорта — 512 мегабайт. Для блога этого хватает, но для магазина с кучей фотографий — нет. Если сайт тяжёлый, придётся либо платить за расширение, либо искать другой способ. Я для своего блога уложился в лимит без проблем, но если бы у меня был магазин — этот нюанс пришлось бы учитывать заранее. Имей в виду: дешёвое и простое решение имеет свои рамки.

Ещё один способ, который я использую сейчас — миграция через WP-CLI. Это командная строка WordPress, и она даёт полный контроль. Экспорт базы через wp db export, импорт через wp db import, файлы переношу через rsync. Это профессиональный подход: он быстрый, надёжный и не зависит от плагинов. Но есть условие — нужен доступ к SSH. Если у тебя свой сервер или VPS — этот способ лучший. Если общий хостинг без SSH — придётся ограничиться плагинами или панелью.

Почему я перешёл на WP-CLI. Во-первых, скорость: команды выполняются мгновенно, не нужно кликать по интерфейсу. Во-вторых, надёжность: я вижу, что происходит, и могу повторить при необходимости. В-третьих, автоматизация: весь процесс можно записать в скрипт и повторять. Для меня это стало стандартом. Но для новичка WP-CLI может показаться пугающим — поэтому советую начинать с All-in-One WP Migration, а к командной строке переходить по мере роста навыков.

Теперь про самый важный совет — бекапы. Перед любой миграцией делай полный бекап: файлы и базу. Не поленись. Если что-то пойдёт не так — откат займёт пять минут, а не часы восстановления. У меня правило: бекап перед любым серьёзным изменением, включая миграцию. И проверяй, что бекап рабочий — восстанови его на тестовую копию. Бекап, который нельзя восстановить, — это не бекап. Эта привычка не раз спасала меня.

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

Отдельно про права на файлы скажу пару слов, потому что это частая боль. После переноса файлов права могут сбиться, и сайт выдаёт ошибки доступа. Правильные права для WordPress: директории 755, файлы 644, владелец — тот пользователь, от которого работает веб-сервер. Я после миграции всегда прогоняю проверку прав и исправляю, если что-то сбилось. Это пять минут работы, которые избавляют от 403-х и других ошибок доступа.

Про ссылки в базе тоже стоит напомнить. Если домен меняется, в базе нужно заменить старый адрес на новый. All-in-One WP Migration делает это автоматически, WP-CLI — через команду поиска и замены. Главное — не забыть про это вообще, потому что без замены ссылок сайт будет работать криво: картинки не загрузятся, внутренние ссылки поведут на старый адрес. В первый раз я на этом и попался. Теперь замена ссылок — обязательный пункт моего чек-листа миграции.

Что бы я посоветовал новичку, который собирается переезжать. Не экономь время на подготовке. Сделай бекап, продумай шаги, подготовь новый сервер заранее. Потом выбери способ: плагин — если сайт небольшой и хочется просто; WP-CLI — если есть SSH и хочется контроля. Прогони миграцию, проверь результат, поправь права и ссылки. И не бойся — с правильным подходом миграция проходит гладко. У меня второй переезд занял полчаса и прошёл без ошибок, просто потому что я использовал правильный инструмент.

Подведу итог. Миграция WordPress — это процесс, который можно пройти двумя путями: на граблях (как я в первый раз) или по чек-листу (как во второй). Главные пункты: бекап перед стартом, правильный инструмент переноса, замена ссылок, проверка прав, проверка результата. Всеин-one WP Migration сделал переезд простым, а WP-CLI — профессиональным. Теперь я спокойно переезжаю, когда нужно, и не трачу на это нервов. Если тебе предстоит миграция — не переживай. Подойди к ней системно, и всё пройдёт гладко. А если сомневаешься — начни с бекапа. Он — твоя страховка на любой случай.

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

Второе — про тестовую проверку перед переключением DNS. Я рекомендую поднять сайт на новом сервере и проверить его до того, как переключать домен. Для этого можно временно подменить hosts-файл или использовать внутренний адрес. Так ты увидишь, работает ли сайт на новом месте, не затронув живой сайт. Это лучший способ поймать ошибки до того, как их увидят пользователи.

Третье — про скорость переноса файлов. Если сайт большой, перенос по FTP — это долго. Я использую rsync с сжатием — он быстрее и докачивает файлы при обрыве. Для больших медиатек это ощутимая разница. Ещё можно переносить архивом: запаковал — перекинул один файл — распаковал. Это проще и быстрее, чем тащить тысячи файлов по одному. Выбирай способ под объём своих данных.

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

И пятое — про документирование. После первой миграции я составил себе чек-лист и сохранил его. Теперь каждая следующая миграция — это просто выполнение пунктов по списку. Ничего не забываю, ничего не упускаю. Записывай свой процесс — он пригодится не раз. Миграция WordPress — это не разовая задача, а навык, который понадобится снова. С чек-листом ты будешь делать её спокойно и быстро.

Ещё пара слов про ошибки, которые встречаются чаще всего. Если после миграции сайт выдаёт белую страницу — включай отладку WP_DEBUG и смотри лог ошибок. В 90% случаев там причина: несовместимость версии PHP, отсутствующее расширение или неверные настройки в wp-config. Если сайт открывается, но без стилей — проверь ссылки в базе и права на файлы темы. Если картинки не грузятся — снова ссылки, теперь в медиатеке. Большинство проблем миграции решаются этими тремя проверками.

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