Перенос сайта на другой хостинг

Выбор нового хостинга

Переезд — это копия, проверка и переключение DNS, а не гонка. Начните с тарифа, который выдержит сайт в текущем виде: та же или более новая версия PHP, те же расширения, достаточно места на диске с запасом под резервные копии и доступ по SSH. Без SSH остаются файловый менеджер панели и FTP: медленнее и легче сломать переезд на половине. Инструменты, которые понадобятся: wget для проверки состояния страниц на новом сервере.

Что сравнить до оплаты: цена за год, дисковая квота, число баз данных, доступные версии PHP и можно ли переключать их для сайта, SSH, cron, резервные копии и входит ли почта. Как выбирать: Какой хостинг выбрать и, если нужен собственный сервер, VPS хостинг.

Сначала измерьте то, что переносите. Из папки с сайтом:

find . -type f | wc -l

du -sh .

Запишите оба числа: это база для сравнения после копирования. Меньшее число файлов на новом сервере означает, что часть файлов не скопировалась, и обычно причина — скрытая папка или права доступа.

Перенос файлов

Способов три, и их можно сочетать. Файловый менеджер панели — запасной вариант: упаковать сайт в один архив, загрузить, распаковать на сервере. Архив сохраняет права, пустые папки и скрытые файлы, а одна загрузка намного быстрее тысячи мелких.

tar czf site-backup.tar.gz site

ls -lh site-backup.tar.gz

-rw-rw-r-- 1 user user 274 Nov 6 18:45 site-backup.tar.gz

tar сам ничего не печатает; строку выше выводит ls, и она показывает, что архив есть и сколько он весит. Загляните внутрь до загрузки:

tar tzf site-backup.tar.gz

site/
site/index.php
site/web/
site/web/page.html
site/.htaccess

Имя и размер будут вашими; важен один файл, а список показывает, что скрытый .htaccess внутри. Загрузите архив через панель и распакуйте в новом корне сайта:

tar xzf site-backup.tar.gz --strip-components=1

--strip-components=1 отбрасывает верхнюю папку архива, поэтому site/index.php оказывается index.php в текущей папке. Без этого ключа сайт ложится на уровень глубже и главная страница отдаёт 404. Подробнее об архивах: Архивы в Linux.

При доступе по SSH копируйте через SFTP или SCP с ключом SSH: создать ключ ed25519, положить его открытую половину в панель, затем загружать. В интерактивной сессии строки с sftp> — это то, что вы вводите:

sftp user@new-host.example

sftp> cd /home/user/site/public_html

sftp> put -r web

sftp> put index.php

SSH даёт ещё и rsync — самый безопасный способ синхронизировать папку: он передаёт только отличия и умеет сначала показать план. Здесь между двумя локальными папками, чтобы можно было повторить:

rsync -avn site/ public_html/

sending incremental file list
.htaccess
index.php
web/
web/page.html

sent 171 bytes received 29 bytes 400.00 bytes/sec
total size is 48 speedup is 0.24 (DRY RUN)

Та же команда на новый сервер:

rsync -avn -e ssh site/ user@new-host.example:/home/user/site/public_html/

-n — это пробный прогон: прочитайте список, затем повторите команду без -n. Замыкающая косая черта в источнике важна: site/ копирует содержимое, site создаёт папку site внутри приёмника. Скрытые файлы вроде .htaccess переносятся обоими инструментами; проверьте их после копирования:

ls -la /home/user/site/public_html

Не забудьте то, чего нет в архиве: загруженные файлы, логи, кеши и всё, что сайт пишет во время работы. Этим папкам нужна отдельная копия и правильные права: папки 755, файлы 644, и 775 только там, где PHP должен писать.

Перенос базы данных

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

mysqldump --single-transaction --routines --triggers -u old_user -p old_db > old_db.sql

mysql -u new_user -p new_db < old_db.sql

MySQL спросит пароль после каждой команды, поэтому пароль не попадает в историю команд. Без SSH то же самое делает phpMyAdmin: выбрать базу, Экспорт, формат SQL, сохранить файл; на новом сервере — Импорт файла в новую базу.

После импорта настройки CMS должны указывать на новую базу (имя, пользователь, пароль, хост) и на новый адрес сайта. У WordPress адрес хранится в базе, поэтому менять его нужно инструментом, а не текстовым редактором:

wp search-replace 'https://old.example.com' 'https://www.example.com' --dry-run

Повторите без --dry-run, когда пробный прогон покажет только ожидаемые таблицы. Слепая замена в SQL-файле ломает сериализованные значения.

Настройки и пути

Файлы, в которых остался старый сервер, — обычная причина белой страницы или неверных ссылок после переезда. Проверьте:

конфигурацию CMS (wp-config.php, .env, configuration.php): база, хост, абсолютные пути;
адрес сайта и base URL в настройках;
абсолютные пути в заданиях cron, скриптах и настройках логов;
.htaccess: редиректы, база перезаписи, документ ошибки;
настройки PHP: лимит памяти, размер загрузки, часовой пояс и версия PHP, назначенная сайту;
права на запись для папок кеша, загрузок и сессий.

Меняйте пути в конфигурации, а не в содержимом страниц. Если старый домен встречается в тексте страницы, исправьте это в CMS или поиском по базе, а старый домен оставьте рабочим с редиректом на время.

Проверка до смены DNS

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

203.0.113.10 www.example.com example.com

Как устроен файл: etc/hosts. Теперь браузер на этой машине видит новый сервер, а все остальные — ещё старый. Запросите строку состояния важных страниц:

wget -qS --spider https://www.example.com/ 2>&1 | head -4

HTTP/1.1 200 OK
Date: Fri, 06 Nov 2026 16:22:03 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked

Так выглядит здоровый ответ; у вас будет своя дата запроса. Проверьте главную, внутреннюю страницу, страницу с обязательным редиректом и несуществующую (должен вернуться документ 404 сайта, а не стандартная страница хостинга). 500 обычно означает путь или права, 403 — нет индексного файла или папка закрыта, а цикл редиректов — правило HTTPS или www срабатывает дважды.

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

Смена DNS

Записи DNS кешируются на время TTL, поэтому сначала снизьте TTL: за сутки до переключения поставьте 300 секунд для записей A (и AAAA) домена и www. Затем смените адрес на новый сервер.

nslookup www.example.com

Server: 192.0.2.1
Address: 192.0.2.1:53

Non-authoritative answer:
Name: www.example.com
Address: <new-server-ip>

Блок показывает, как выглядит ответ: две строки сверху — это ответивший DNS-сервер, а в последней строке должен быть адрес нового сервера вместо <new-server-ip>. Разные резолверы кешируют разное время, поэтому проверьте и из другой сети, например с телефона по мобильному интернету. Старый сервер держите включённым, пока не пройдут проверки из последнего раздела: часть посетителей ещё несколько часов будет попадать на него.

Сертификат и редиректы

Сертификат на новом сервере можно выпустить только после того, как имя указывает на него: бесплатные автоматические сертификаты проверяют домен по HTTP. Поэтому порядок такой: сначала DNS, потом сертификат, потом редиректы. Когда сертификат стоит, все адреса должны приходить к одному каноническому виду за один переход: http на https, а www на домен без www — или наоборот.

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

Почта на домене

Почта и сайт — разные службы, которые связывает только имя домена. Смена веб-сервера не переносит почтовые ящики. Если на домене есть почта, записи MX должны по-прежнему указывать на почтового провайдера, а SPF, DKIM и DMARC — оставаться корректными, иначе письма перестанут приходить или начнут попадать в спам.

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

Проверки и закрытие старого хостинга

Старый аккаунт держите одну-две недели. В это время сравнивайте два сервера и наблюдайте за новым:

Проверка	Как
Все страницы отвечают	открыть по одной из каждого раздела; все отдают 200
Редиректы за один переход	wget -qS --spider для нескольких старых адресов
Нет новых 404	лог доступа нового сервера или отчёт 404 хостинга
Нет ошибок PHP	лог ошибок нового сервера
HTTPS и www	обе формы открываются на каноническом адресе
Продление сертификата	в панели видна дата автоматического продления
Почта	тестовое письмо доходит до ящика на домене
Резервные копии	новый хостинг их делает, и одно восстановление проверено

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

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

Автор статьи: Arthur Isaev