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

Содержание

Введение

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

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

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

Аренда VPS/VDS от 219 руб/месяц

Преимущества VPS в AdminVPS:

✓ Бесплатное администрирование

✓ Только быстрые NVMe-диски

✓ Защита от DDoS-атак

✓ Быстрая техподдержка

Аренда VPS/VDS виртуального сервера от AdminVPS — это прозрачная и честная услуга с доступной ценой

Подготовка к переносу

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

Обязательное условие — создание резервной копии. Скопируйте все файлы сайта, включая скрытые и системные, из каталога public_html или www, экспортируйте базу данных, сохраните конфигурационные файлы (например, .htaccess, wp-config.php, config.php) и, при необходимости, почтовые ящики. Храните бекап не только на старом хостинге, но и локально — это поможет восстановиться даже в случае полной потери доступа к серверу.

Особое внимание стоит уделить настройкам DNS. За 1–2 дня до переноса желательно снизить значение TTL (времени жизни DNS-записей) до минимального — например, 300 секунд. Это позволит быстро переключить домен на новый сервер без долгой задержки из-за кеширования. После завершения переноса TTL можно вернуть обратно.

Если сайт работает на CMS, важно заранее убедиться в совместимости её версии и всех модулей с новым хостингом. Также стоит проверить поддержку нужных версий PHP, баз данных, почтовых функций, SSL, а также возможность настройки cron-задач и кеширования. Ошибки на этом этапе чаще всего становятся причиной сбоев уже после переноса.

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

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

Первым делом необходимо перенести все файлы проекта с текущего хостинга на новый. Для этого подключитесь к серверу через FTP, SFTP или по SSH и скачайте полный архив содержимого каталога сайта — обычно это папка public_html, www или htdocs. Важно не пропустить скрытые файлы и каталоги, такие как .htaccess, .user.ini или файлы с кешем и логами, если они важны для работы проекта. Иногда такие файлы не отображаются в клиенте по умолчанию — проверьте настройки отображения.

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

Если используется система управления версиями, например Git, можно задействовать её для переноса, но это потребует дополнительной настройки и не всегда оправдано для простых сайтов. Для большинства случаев достаточно архивировать файлы на старом сервере, загрузить архив на новый и распаковать его уже в окружении нового хостинга.

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

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

После переноса файлов необходимо скопировать базу данных. Это особенно важно для динамических сайтов: интернет-магазинов, блогов, корпоративных порталов, где данные хранятся не в файлах, а в СУБД — чаще всего MySQL или MariaDB.

На старом хостинге выполните экспорт базы данных. Проще всего сделать это через интерфейс phpMyAdmin или Adminer — большинство панелей управления хостингом поддерживают хотя бы один из этих инструментов. Выберите нужную базу, проверьте, что включены все таблицы, установите формат экспорта как SQL и сохраните файл на компьютер. Важно, чтобы при экспорте сохранялась кодировка, используемая на сайте — чаще всего это utf8mb4.

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

mysql -u user -p dbname < dump.sql

Эта команда доступна на VPS и выделенных серверах.

После импорта проверьте наличие всех таблиц, а также правильность отображения текста — если он повреждён (например, вместо кириллицы отображаются символы «???» или иероглифы), скорее всего, была выбрана неверная кодировка при экспорте или импорте. В этом случае придётся повторить процесс с корректными параметрами.

Импорт завершён — теперь сайт имеет и файлы, и базу на новом хостинге. Осталось связать их между собой, внеся изменения в конфигурационные файлы.

Настройка конфигурации

После переноса файлов и базы данных необходимо обновить конфигурационные файлы сайта, чтобы он корректно работал на новом хостинге. В первую очередь нужно изменить параметры подключения к базе данных: адрес сервера, имя пользователя, пароль и имя базы. Эти данные находятся в конфигурационном файле, который зависит от CMS или фреймворка. В WordPress это wp-config.php, в OpenCart — config.php, в Laravel — .env, в других системах может использоваться settings.php, database.php или другой файл.

Если на новом сервере используется нестандартный адрес базы данных (например, вместо localhost используется внутренний адрес кластера), его также нужно указать. Ошибки на этом этапе приводят к сбоям подключения и ошибкам типа Error establishing a database connection.

Также проверьте абсолютные пути, если они жёстко прописаны в коде. Некоторые сайты используют прямые указания директорий (например, /home/olduser/public_html/), которые на новом сервере могут отличаться. То же касается URL-адресов — если сайт переехал на новый домен или поддомен, это необходимо отразить в базе данных или настройках CMS.

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

Если на старом хостинге использовались cron-задачи, их нужно перенести вручную. Проверьте, какие команды запускались по расписанию (например, обновление RSS, синхронизация данных, рассылки), и добавьте их в планировщик на новом сервере, используя crontab -e или панель управления.

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

Смена DNS-записей

Когда сайт полностью перенесён и работает на новом хостинге в тестовом режиме (через IP-адрес или временный домен), можно приступать к смене DNS-записей, чтобы направить основной домен на новый сервер.

Если вы используете NS-записи хостинга (то есть делегировали управление DNS провайдеру), замените текущие NS на те, которые указаны в панели нового хостинга. Обычно они выглядят как ns1.vps-провайдер.ru и ns2.vps-провайдер.ru. Эти записи вносятся в панели регистратора домена. После сохранения изменений начнётся распространение новой информации по DNS-серверам Интернета — на это может уйти от нескольких минут до суток, в зависимости от установленного TTL.

Если вы используете внешнюю DNS-платформу (например, у регистратора), достаточно изменить только A-запись, указав в ней новый IP-адрес VPS. Это быстрее, чем смена NS, и подходит для тех, кто сам управляет зонами. Также не забудьте обновить MX-записи (если используется почта), TXT-записи (например, SPF или записи для верификации), и другие, если они меняются при переезде.

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

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

Проверка и отладка после переноса

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

Начать стоит с логов ошибок. Включите отображение ошибок в настройках CMS или в конфигурации сервера и проверьте журналы: error.log, php-error.log, логи веб-сервера. Это поможет выявить скрытые проблемы, связанные с путями, правами, подключением к базе или отсутствием зависимостей.

Проверьте все ключевые разделы сайта: админ-панель, формы обратной связи, корзину, личные кабинеты, страницы оплаты и авторизации. Обратите внимание на загрузку изображений, работу скриптов, плагинов и модулей. Часто после переезда перестают корректно работать функции, завязанные на абсолютные пути, сторонние API или кеш.

Если используется SSL-сертификат, проверьте его валидность и привязку к домену. На некоторых хостингах его нужно активировать вручную или переоформить заново. Также удостоверьтесь, что все страницы открываются по HTTPS и нет смешанного контента (mixed content), особенно при ручной вставке ссылок и изображений.

Проверьте производительность. После переезда возможно изменение скорости загрузки — как в лучшую, так и в худшую сторону. Для оценки можно использовать инструменты вроде PageSpeed Insights, GTmetrix или встроенные средства разработчика в браузере.

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

Возможные проблемы при переносе и как их решить

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

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

Ошибки 500 или белый экран указывают на сбои в работе PHP: несовместимость версий, отсутствие нужных расширений или ошибки в конфигурационных файлах. Для начала стоит включить отображение ошибок (в CMS или через файл php.ini) и посмотреть журнал — скорее всего, он укажет на конкретную строку кода или модуль, вызвавший сбой. Если сайт работал на старом хостинге с PHP 7.4, а новый сервер использует PHP 8.2, нужно проверить совместимость CMS и плагинов.

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

Иногда после переноса перестают работать формы, почта, авторизация. Причины могут быть в заблокированных функциях mail() на новом сервере, в некорректных настройках SMTP или в том, что переменные среды не были перенесены из файла .env. Также может понадобиться настройка sendmail или стороннего почтового API.

Если используется кеширование или система с CDN, могут возникнуть проблемы с отображением старого контента. Очистите кеш CMS, кеш браузера и при необходимости — кеш на стороне CDN. Это особенно важно, если был установлен плагин оптимизации или сжатия контента.

Всё это подчёркивает, насколько важно тестировать сайт после переноса в «боевых» условиях. Лучше потратить 30 минут на проверку, чем потом сутками устранять жалобы пользователей или восстанавливать утраченные данные.

Перенос сайта на VPS: почему это разумный шаг

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

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

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

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

Чек-лист: как безопасно перенести сайт на другой хостинг

1. Подготовка:

Получены доступы к панели хостинга, FTP/SFTP/SSH
Получены параметры подключения к базе данных
Есть доступ к управлению доменом (регистратор, DNS)
Создан полный бекап: файлы, база, конфиги, почта
TTL в DNS-записях снижен до 300 секунд
Проверена версия CMS и её совместимость с новым окружением
Уточнены зависимости: PHP, MySQL, cron, SSL, почта, кеш

2. Перенос файлов:

Скачаны все файлы сайта, включая скрытые (.htaccess и др.)
Сохранена структура директорий и права доступа
Файлы загружены на новый хостинг

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

Выполнен экспорт базы данных в формате SQL
На новом хостинге создана пустая БД с нужной кодировкой
Импорт выполнен без ошибок, текст отображается корректно

4. Настройка конфигурации:

Обновлены параметры подключения к базе в конфигурационном файле
Проверены абсолютные пути и URL-адреса
Настроены переменные окружения, логи, директории кеша
Перенесены и активированы cron-задачи

5. Обновление DNS:

Изменены NS-записи или A-запись домена
Подтверждена доступность сайта по новому адресу
TTL возвращён к прежнему значению после обновления DNS

6. Проверка после переноса:

Проверена загрузка сайта и всех основных разделов
Отслеживаются логи ошибок сервера и CMS
Проверена работа форм, авторизации, оплаты
Убедились, что SSL активен и нет смешанного контента
Очищен кеш сайта и браузера

Этот список можно использовать как контрольный лист для самостоятельного переноса или при передаче задачи техническому специалисту.

Заключение

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

Хорошая подготовка, проверенные бекапы, корректные настройки и внимательная отладка — всё это делает процесс переноса управляемым и предсказуемым. А выбор VPS в качестве нового хостинга открывает больше возможностей: производительность, контроль, безопасность и масштабируемость.

Если вы планируете расти, расширять проект или просто хотите стабильности — VPS станет надёжной платформой, на которую можно опереться.

Читайте в блоге:

Перенос сайта на другой хостинг: правильный порядок действий