Перенос сайта WordPress на другой хостинг без потери позиций

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

Что именно переносится и почему домен переключают последним

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

• Файлы. Вся папка сайта: ядро, тема, плагины, папка загрузок, wp-config.php, .htaccess.
• База данных. Дамп в формате SQL со всеми таблицами, включая служебные, созданные плагинами.
• Почта домена. Ящики вида info@ живут на MX-записях, и при смене хостинга их легко потерять вместе с перепиской.
• Записи домена. Строка A с адресом сервера, записи MX, TXT для подтверждения прав, CNAME для поддоменов.

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

Обратный порядок — «переключим, а там разберёмся» — это гарантированный простой. Пока вы правите права доступа и ищете, почему не открывается админка, робот получает ошибки. Несколько сотен страниц с кодом 5xx подряд заметно снижают скорость обхода, а часть адресов может временно выпасть из выдачи. Возвращаются они не мгновенно.

Подготовка: снимаем файлы и базу

Файлы забираются по FTP, по SFTP или, что быстрее и надёжнее, через консоль архивом. Разница существенная: FTP-клиент копирует десятки тысяч мелких файлов по одному и на большом сайте работает часами, а иногда обрывается, оставив половину папки загрузок. Архив на стороне сервера собирается за минуты и переносится одним файлом.

Проверьте, что в архив попали скрытые файлы. .htaccess начинается с точки, и многие архиваторы его пропускают. Без него на новом сервере внутренние страницы будут отдавать 404, а главная — открываться.

База снимается дампом. Через phpMyAdmin это работает для небольших сайтов; если база больше сотни мегабайт, дамп нужно делать в консоли и сразу сжимать. Дамп обязательно проверьте: откройте начало файла и убедитесь, что там указана кодировка utf8mb4, и загляните в конец — оборванный на середине таблицы дамп встречается регулярно и обнаруживается только при импорте.

Отдельно выпишите на бумагу или в заметку то, что понадобится через час: версию PHP, версию MySQL или MariaDB, адрес сайта из настроек, имя базы и пользователя. Узнать, где физически стоит текущий сайт и что за площадка вас обслуживает, можно способами из материала Узнать хостинг сайта по домену — иногда выясняется, что домен и хостинг вообще в разных местах, и переключать придётся не там, где вы думали.

Разворачиваем и проверяем сайт на новом сервере

На новом хостинге создаётся сайт с тем же доменным именем, заливаются файлы, создаётся база и импортируется дамп. В wp-config.php прописываются новые данные подключения: имя базы, пользователь, пароль и хост базы — последний не всегда localhost, у некоторых площадок это отдельный адрес.

Дальше главный вопрос: как посмотреть на сайт, если домен ещё смотрит на старый сервер. Есть три способа.

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

Технический адрес хостинга. Многие площадки дают временное имя вида site.hostname.ru. Работает, но сайт открывается по чужому адресу: часть ссылок будет вести на старый домен, часть ресурсов не загрузится, и вы получите ложные ошибки. Такой адрес обязательно закрывайте от индексации заголовком X-Robots-Tag: noindex и паролем, иначе получите полный дубль сайта в индексе.

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

Если сайт всё-таки открывается по другому адресу, адреса внутри базы придётся заменить. Обычная замена по SQL ломает сериализованные данные — в них записана длина строки, и после подстановки другого адреса длина перестаёт совпадать, из-за чего слетают настройки темы и части плагинов. Корректно это делает команда wp search-replace из WP-CLI. При переезде на тот же домен замена вообще не нужна — ещё один довод в пользу проверки через файл hosts.

Окружение: что должно совпасть

Самая частая причина «после переезда всё сломалось» — не потерянные файлы, а другое окружение. Новый сервер может оказаться современнее старого, и сайт, который годами работал на PHP 7.4, встретит PHP 8.3 фатальными ошибками в старой теме.

Параметр	Где смотреть	Чем грозит несовпадение
Версия PHP	Панель хостинга, «Здоровье сайта» в админке	Фатальные ошибки, белый экран, отвал плагинов
Версия MySQL или MariaDB	Панель хостинга, phpMyAdmin	Ошибки импорта дампа, конфликт кодировок
Модуль mod_rewrite	Ответ на любую внутреннюю страницу	404 на всех страницах, кроме главной
Лимит памяти PHP	Панель, «Здоровье сайта»	Обрыв импорта, ошибки в админке
Максимальный размер загрузки	Настройки PHP	Не грузятся картинки и обновления
Отправка почты	Тестовая отправка формы	Заявки уходят в никуда, письма не доходят
Кодировка соединения с базой	Начало дампа, настройки MySQL	Кириллица превращается в вопросительные знаки
Права на файлы и каталоги	Файловый менеджер, SSH	Не работает загрузка медиа, ошибка обновлений

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

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

Сертификат и время жизни записей домена

Две вещи, которые готовятся заранее и чаще всего забываются.

Сертификат. Он привязан к серверу, а не к домену, и на новом хостинге его нужно выпустить заново. Если этого не сделать до переключения, посетители в момент переезда увидят предупреждение браузера о небезопасном соединении — это худшее, что можно показать людям и роботу одновременно. Бесплатный сертификат выпускается за минуты, но требует, чтобы домен уже указывал на новый сервер; поэтому многие панели умеют выпускать его сразу после переключения в автоматическом режиме — проверьте, что эта опция включена, и держите её на контроле в первые полчаса. Какие бывают виды сертификатов и чем они отличаются, разобрано в статье Что такое сертификат SSL.

Время жизни записей. У каждой записи домена есть параметр TTL — сколько секунд провайдеры хранят её в кэше. По умолчанию это часто 3600 или 14400 секунд, то есть от часа до четырёх. Пока старое значение не истечёт, часть посетителей будет попадать на старый сервер, часть — на новый. За сутки до переезда уменьшите TTL до 300 секунд. Тогда переключение разойдётся по миру за пять-десять минут вместо четырёх часов, а после успешного переезда значение можно вернуть обратно.

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

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

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

1. За сутки уменьшить TTL до 300 секунд.
2. Непосредственно перед переключением снять свежий дамп базы на старом сервере и залить его на новый — иначе потеряются заказы, заявки и комментарии, появившиеся за время подготовки.
3. На время переноса свежих данных закрыть приём заказов или предупредить, что заявки могут задвоиться.
4. Изменить A-запись домена на адрес нового сервера. MX-записи не трогать, если почта остаётся на прежнем месте, — их случайная перезапись самая обидная потеря при переезде.
5. Дождаться, пока домен начнёт открываться с нового сервера, и выпустить сертификат.
6. Проверить сайт по чеклисту из следующего раздела.
7. Через двое-трое суток вернуть TTL и только после этого отключать старый хостинг.

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

Первые сутки: что проверять

После переключения проверка идёт не по ощущению «вроде открывается», а по списку. Большинство проблем переезда невидимы на главной странице.

Что проверить	Как проверить	Признак проблемы
Главная и внутренние страницы	Открыть 5–10 разных адресов	404 на внутренних — потерян .htaccess
Код ответа	Инструмент проверки ответа сервера	Вместо 200 приходит 5xx или лишний редирект
Протокол и версия домена	Открыть сайт с www и без, по http и https	Нет склейки, открываются четыре версии сайта
Сертификат	Замок в адресной строке, срок действия	Предупреждение браузера
Картинки в старых записях	Открыть статью двухлетней давности	Битые изображения — не доехала папка загрузок
Формы обратной связи	Отправить тестовую заявку	Письмо не приходит — не настроена почта
Админка и вход	Зайти в панель, открыть список записей	Ошибка соединения с базой
robots.txt и карта сайта	Открыть оба адреса напрямую	Запрет индексации всего сайта, пустая карта
Скорость ответа	Замер времени до первого байта	Стало заметно дольше, чем было
Почта домена	Отправить письмо на ящик домена	Письма не доходят — перезаписаны MX

Строка про robots.txt в этом списке не случайна. На тестовых площадках почти всегда стоит запрет индексации — либо галочка «Попросить поисковые системы не индексировать сайт» в настройках чтения, либо строка Disallow: /. Если копию готовили как тестовую, запрет переедет вместе с ней и останется на боевом сайте. Это самая дорогая ошибка переезда: сайт работает, выглядит нормально, а через две недели выпадает из выдачи целиком.

Как убедиться, что робот видит новый сервер

Поисковая система не получает уведомления о смене хостинга и узнаёт о ней сама, при очередном обходе. Ваша задача — убедиться, что этот обход прошёл нормально.

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

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

Третье: отправьте на переобход несколько важных страниц — главную, ключевые страницы услуг, свежие статьи. Это не ускорит переиндексацию всего сайта, но даст быстрый ответ на вопрос, доступен ли сайт роботу прямо сейчас.

Теперь о том, где позиции действительно теряют. Сам факт смены адреса сервера на ранжирование не влияет: домен не меняется, адреса страниц не меняются, содержимое то же. Проседания случаются по другим причинам. Забытый запрет индексации в настройках чтения. Пропавший .htaccess и вместе с ним склейка адресов с www и без. Сайт, который стал отвечать вдвое медленнее. Незамеченный сбой в первые часы, когда робот успел обойти сотню страниц и получить ошибки. И самое неприятное — потеря части файлов при копировании, из-за чего десятки страниц отдают 404, а вы этого не видите, потому что проверяли главную. Все пять сценариев закрываются проверками из таблицы выше. Если переезд совмещается со сменой движка, риск выше на порядок — этот случай разобран отдельно в материале Сменили движок — и трафик рухнул вдвое: как переехать на новую CMS без потери позиций.

Частые вопросы

Нужно ли делать 301-редиректы при переносе на другой хостинг? Нет. Редиректы нужны при смене домена или адресов страниц. При смене только сервера домен и все адреса остаются прежними, перенаправлять нечего. Если кто-то предлагает «настроить редиректы для переезда на новый хостинг», уточните, что именно он собирается перенаправлять.

Сколько длится переезд? Техническая часть на среднем сайте — от часа до половины дня, из них большая часть уходит на копирование файлов. Полный цикл с уменьшением TTL, проверками и параллельной работой двух серверов занимает три-четыре дня.

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

Что делать, если после переезда пропали картинки в старых статьях? Сначала проверьте, доехала ли папка wp-content/uploads целиком — сравните количество файлов на обоих серверах. Если файлы на месте, а картинки не видны, дело в правах доступа или в том, что в базе прописан старый адрес с другим протоколом. Откройте исходный код страницы и посмотрите, какой именно путь указан у изображения.

Стоит ли переезжать, если текущий хостинг просто дорогой? Считайте не разницу в цене, а стоимость последствий. Дешёвая площадка с медленным ответом и регулярными сбоями обходится дороже переплаты за нормальный сервер. Критерии выбора собраны в материале Какой хостинг выбрать для сайта. Если сомневаетесь, стоит ли ваш проект переносить и что у него с технической частью, начните с бесплатного аудита сайта.

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

Коротко

• Домен переключается последним. Сначала полностью рабочая копия на новом сервере, проверка через файл hosts, потом изменение A-записи.
• В копию входят файлы вместе со скрытым .htaccess и полный дамп базы; версии PHP и MySQL выписываются заранее.
• Сайт сначала поднимают на прежней версии PHP и только отдельным шагом переводят на новую.
• За сутки до переезда TTL записей снижают до 300 секунд, а старый сервер держат включённым ещё двое-трое суток.
• Сертификат выпускается сразу после переключения, иначе посетители увидят предупреждение браузера.
• Главная причина падения позиций после переезда — не сам переезд, а забытый запрет индексации, потерянный .htaccess и незамеченные ошибки в первые часы.

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