Перенос сайта с одного хостинга на другой — это не просто техническая задача. Это момент истины. Момент, когда вы либо подтверждаете контроль над своим цифровым активом, либо впервые осознаёте, насколько хрупкой может быть эта иллюзия контроля. Многие думают: «Зачем мне это? Пусть всё работает, как работает». Но однажды приходит день, когда старый хостинг начинает тормозить, поддержка отвечает раз в неделю, цены растут, а возможности — нет. И тогда вы понимаете: сайт — это не просто набор файлов. Это ваша репутация, ваш бизнес, ваш голос в интернете. И вы не можете позволить ему зависеть от чужой ненадёжности.
Хорошая новость: перенести сайт можно. И не только можно — это обязан уметь каждый, кто хоть раз размещал что-то в сети. Не обязательно быть системным администратором. Достаточно понимать логику процесса и действовать последовательно.
Что на самом деле нужно перенести?
Прежде чем нажимать кнопки и копировать файлы, давайте чётко определимся: что именно составляет ваш сайт? Многие ошибочно полагают, что сайт — это то, что видит посетитель в браузере. Это иллюзия. На самом деле сайт — это три независимых, но взаимосвязанных компонента:
- Файлы — весь код, изображения, скрипты, стили, медиафайлы. Всё, что лежит в корневой директории и её подпапках.
- База данных — структурированное хранилище динамического контента: записи блога, товары, пользователи, комментарии, настройки. Без неё сайт может открыться, но будет пустым или неработоспособным.
- Почтовые ящики — если вы используете email на своём домене (например, info@вашсайт.рф), то письма хранятся на сервере хостинга. Их тоже нужно переносить, хотя и особым способом.
Всё. Больше ничего. Никаких «магических» настроек, скрытых конфигов или тайных ключей. Если вы обеспечите целостность этих трёх компонентов и правильно их соедините на новом месте — сайт заработает. Всё остальное — технические детали реализации.
Шаг первый: получить архив и дамп
Вы не можете перенести то, чего у вас нет. Поэтому первое, что вы делаете — это получаете полную копию сайта с текущего хостинга. Это не «скачать через FTP пару папок». Это — создание полного архива файлов и дампа базы данных.
Если у вас есть доступ к панели управления хостингом (cPanel, ISPmanager, DirectAdmin и т.п.), вы можете сделать это самостоятельно. Обычно там есть раздел «Файловый менеджер» и «Базы данных». В файловом менеджере вы выбираете корневую папку сайта (часто это public_html, www или папка с именем домена), создаёте архив (ZIP или TAR.GZ) и скачиваете его. Для базы данных — ищете функцию «Экспорт» или «Создать дамп», выбираете формат SQL и сохраняете файл на свой компьютер.
Если доступа нет — пишите в поддержку текущего хостинга. Требуйте архив файлов и дамп БД. Не «помощь с переносом», а именно файлы. Вы — владелец контента. У вас есть полное право на его получение. Не соглашайтесь на уклончивые ответы. Настаивайте. Без этих файлов вы ничего не сделаете.
Важно: не переносите сайт «на лету», подключаясь напрямую к старому и новому серверу одновременно. Это рискованно. Сначала получите всё к себе. Пусть у вас будет локальная копия. Это ваша страховка. Если что-то пойдёт не так — вы всегда сможете начать заново.
Шаг второй: подготовить новый хостинг
Теперь переходим к новому хостингу. Вы уже выбрали провайдера, заказали тариф, получили доступ к панели управления. Отлично. Теперь нужно подготовить «почву» для сайта.
Первое — добавить домен. Да, даже если вы пока не собираетесь менять DNS, домен нужно добавить в панель. Почему? Потому что хостинг-панель привязывает файлы и базы данных к конкретному домену. Без этого вы не сможете корректно настроить окружение.
Это делается в разделе «Домены» → «Добавить домен». Вы указываете имя (например, example.com), и система автоматически создаёт корневую директорию для него. Иногда её нужно создать вручную — тогда вы переходите в файловый менеджер и создаёте папку, например, /example.com.
Второе — создать базу данных. Переходите в раздел «Базы данных», нажимаете «Создать», указываете имя БД, имя пользователя и пароль. Запишите эти данные. Они вам понадобятся буквально через пять минут. Имя базы часто формируется автоматически (например, u12345_example), но главное — это логин и пароль. Их вы задаёте сами. Используйте надёжный пароль. Не «123456» и не «password». Это не формальность — это защита ваших данных.
На этом подготовка завершена. У вас есть «пустой» домен и «пустая» база данных. Теперь можно загружать контент.
Шаг третий: загрузить файлы и импортировать базу
Открываете файловый менеджер нового хостинга. Переходите в корневую папку вашего домена. Загружаете туда архив с файлами сайта. После загрузки — распаковываете его внутри этой папки. Внимание: не «распаковать в новую папку», а именно «распаковать здесь». Иначе вы получите структуру вида /example.com/site/public_html/..., и сайт не заработает.
После распаковки проверьте, что в корне лежат привычные файлы: index.php, .htaccess, папки wp-content (если WordPress) и так далее. Если всё на месте — отлично.
Теперь база данных. Вы загружаете SQL-файл с дампом в ту же корневую папку (или в отдельную, если панель требует). Затем переходите в раздел «Базы данных», находите созданную вами БД, и выбираете опцию «Импортировать». Указываете путь к файлу и запускаете процесс. В зависимости от размера базы это может занять от нескольких секунд до нескольких минут. Не прерывайте операцию.
Если импорт завершился без ошибок — поздравляю. Файлы и данные на месте. Но сайт всё ещё не будет работать. Почему? Потому что он не знает, как подключиться к новой базе.
Шаг четвёртый: правка конфигурационного файла
Это самый важный и самый часто упускаемый момент. Файлы сайта содержат конфигурационный файл, в котором прописаны параметры подключения к базе данных: хост (обычно localhost), имя БД, логин и пароль. На старом хостинге эти данные были одни. На новом — другие.
Вам нужно открыть этот файл и заменить старые значения на новые. Где он находится — зависит от CMS:
- WordPress: wp-config.php в корне.
- Joomla: configuration.php.
- Bitrix: /bitrix/php_interface/dbconn.php.
- Drupal: /sites/default/settings.php.
- ModX: core/config/config.inc.php.
- phpBB: config.php.
- Redmine: config/database.yml.
Открываете файл через встроенный редактор панели (или скачиваете, правите локально и загружаете обратно). Находите строки вроде:
define('DB_NAME', 'старая_база');
define('DB_USER', 'старый_пользователь');
define('DB_PASSWORD', 'старый_пароль');
И заменяете их на те, что вы создали на новом хостинге:
define('DB_NAME', 'u12345_example');
define('DB_USER', 'u12345_dbuser');
define('DB_PASSWORD', 'ваш_надёжный_пароль');
Сохраняете изменения.
Вот теперь сайт технически готов к работе. Но проверять его через основной домен ещё рано. Сначала нужно убедиться, что всё работает именно на новом сервере, а не по инерции на старом.
Шаг пятый: проверка без смены DNS
Есть два способа проверить сайт до того, как вы направите на него весь трафик.
Первый — через файл hosts. Это системный файл на вашем компьютере, который позволяет вручную указать, какому IP-адресу соответствует домен. Вы находите IP-адрес нового хостинга (он указан в панели управления, обычно в разделе «Информация о сервере» или «DNS»), открываете файл hosts (в Windows — C:\Windows\System32\drivers\etc\hosts, в macOS/Linux — /etc/hosts), добавляете строку:
123.45.67.89 example.com www.example.com
(где 123.45.67.89 — реальный IP нового сервера)
Сохраняете файл, очищаете кэш DNS (ipconfig /flushdns в Windows, sudo dscacheutil -flushcache в macOS), и заходите на example.com в браузере. Если сайт открывается, все страницы работают, формы отправляются — значит, перенос прошёл успешно.
Второй способ — через тестовый поддомен. Многие хостинги автоматически создают временный адрес вида example.com.testhosting.ru или u12345.swtest.ru. Вы просто вводите этот адрес в браузер — и видите сайт, как он будет выглядеть после переноса. Это проще, чем править hosts, но не все провайдеры предоставляют такую возможность.
Важно: при проверке через hosts или тестовый домен могут возникнуть проблемы с отображением стилей или изображений. Это связано с тем, что CMS часто хранит в базе данных абсолютные URL-адреса (например, https://example.com/wp-content/uploads/...). Если вы заходите по другому адресу — браузер не находит ресурсы. Это не ошибка переноса. Это особенность работы CMS. Чтобы всё отображалось корректно, можно временно включить в WordPress режим «относительных путей» через плагины или правку кода, но для базовой проверки это не обязательно. Главное — чтобы структура страниц, меню и функционал работали.
Шаг шестой: перенос почты
Почтовые ящики — отдельная история. Их нельзя просто скопировать, как файлы. Почта — это не статичные данные, а сервис, привязанный к серверу. Поэтому на новом хостинге вы создаёте ящики заново: в панели управления — раздел «Почта» → «Создать ящик». Указываете имя (info, admin, support) и пароль.
Но что делать с письмами, которые уже есть на старом сервере? Их можно сохранить, но только вручную. Самый надёжный способ — использовать почтовый клиент с поддержкой IMAP, например, Mozilla Thunderbird. Вы настраиваете в нём оба аккаунта — старый и новый. Затем перетаскиваете папки (Входящие, Отправленные и т.д.) из одного аккаунта в другой. Thunderbird скачает все письма локально и загрузит их на новый сервер.
Это займёт время, особенно если почта накапливалась годами. Но это единственный способ сохранить историю переписки. Если вы не сделаете этого до смены DNS — письма, пришедшие после переключения, будут приходить на новый сервер, а старые останутся на старом и станут недоступны.
Шаг седьмой: смена DNS
Всё проверено. Всё работает. Пришло время сделать перенос окончательным.
Если домен зарегистрирован у того же провайдера, где вы арендуете хостинг, — великолепно. Часто достаточно просто «привязать» домен к хостингу в панели, и DNS-записи обновятся автоматически.
Если домен у стороннего регистратора (а так бывает чаще всего), вам нужно зайти в аккаунт у регистратора и изменить DNS-серверы (NS-записи). Вместо старых вы указываете NS-серверы нового хостинга. Например:
ns1.newhosting.com
ns2.newhosting.com
(точные адреса всегда указаны в документации хостинг-провайдера)
После сохранения изменений начинается процесс пропагации DNS. Это не мгновенно. Информация расходится по всему миру постепенно. Полное обновление может занять от нескольких минут до 24 часов. В это время часть пользователей будет видеть сайт на старом хостинге, часть — на новом. Это нормально. Главное — не вносить дополнительных изменений в это время.
Важно: не меняйте A-записи или CNAME вручную, если вы не уверены в том, что делаете. Лучше сменить именно NS-серверы целиком. Это проще и надёжнее.
Что делать после переноса?
Не закрывайте старый хостинг сразу. Подождите 48–72 часа. Убедитесь, что:
- сайт стабильно работает на новом сервере,
- все формы и функции работают,
- почта приходит и отправляется,
- в веб-мастерских (Google Search Console, Яндекс.Вебмастер) нет ошибок индексирования.
Только после этого отменяйте подписку на старый хостинг. И даже тогда — сохраните архивы. На всякий случай.
Почему всё это важно?
Потому что веб — это инфраструктура, и как любая инфраструктура, она требует осознанного отношения. Перенос сайта — это упражнение в цифровой грамотности. Каждый раз, когда вы проходите этот путь, вы становитесь чуть более независимым, чуть более защищённым от произвола провайдеров, чуть более уверенным в том, что ваш контент — действительно ваш.
Не бойтесь сложностей. Бойтесь невежества. Потому что невежество — это когда вы не можете перенести свой сайт, потому что «боитесь что-то сломать». А сложность — это когда вы знаете, что делаете, и делаете это аккуратно, шаг за шагом.
И помните: нет ничего, что нельзя перенести. Есть только то, что вы ещё не перенесли.
Удачи в переносе. И помните: если вы дочитали до этого места — вы уже готовы.
