Как перенести сайт на новый хостинг без простоев и потери SEO

Зачем переносить сайт на другой хостинг

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

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

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

Безопасный перенос — это не простое копирование файлов. Необходимо заранее составить план, сохранить исходную версию сайта, проверить новый сервер и только после этого направлять домен на новую площадку.

Какие данные нужно перенести

Перед началом работ важно понять, из каких компонентов состоит сайт. Часто владелец помнит только о файлах, но сайт может зависеть от нескольких связанных систем.

• Файлы сайта. Это страницы, изображения, стили, скрипты, загруженные документы и файлы конфигурации.
• База данных. В ней могут храниться товары, заказы, пользователи, записи блога, настройки CMS и содержимое страниц.
• Настройки домена. DNS-записи определяют, куда направляется сайт, где работает почта и какие внешние сервисы связаны с доменом.
• SSL-сертификат. Он обеспечивает работу сайта по HTTPS.
• Почтовые ящики. Если почта связана с доменом, её перенос требует отдельной подготовки.
• Задания планировщика. Cron-задачи могут отвечать за рассылки, обмен с CRM, обновление каталога и автоматические резервные копии.
• Служебные настройки. К ним относятся версии PHP, параметры веб-сервера, права доступа, переменные окружения и ключи интеграций.

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

Что проверить до переноса

Определите текущую конфигурацию

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

Проверьте наличие дополнительных сервисов:

• почта на домене;
• система аналитики;
• онлайн-оплата;
• CRM и телефония;
• обмен с учётной системой;
• CDN;
• внешнее хранилище изображений;
• автоматические задачи;
• защита от атак и фильтрация трафика.

Эту информацию удобно оформить в отдельную таблицу или чек-лист. Для каждой функции укажите, где она настроена и что потребуется сделать на новом сервере.

Составьте список важных URL

До переноса полезно сохранить перечень ключевых страниц сайта. В него стоит включить главную страницу, разделы каталога, карточки товаров, страницы услуг, статьи, формы, страницы входа и оформления заказа.

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

Проверьте текущий сайт

Не стоит переносить сайт, не понимая его исходного состояния. Зафиксируйте ошибки, которые уже существуют: неработающие ссылки, проблемы с формами, медленные страницы, ошибки в корзине и предупреждения в панели CMS.

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

Резервная копия перед переносом

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

Минимальный набор резервных данных включает:

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

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

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

Подготовка нового хостинга

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

Проверьте требования к серверу

Новый хостинг должен соответствовать требованиям сайта. Обратите внимание на:

• поддерживаемую версию серверного языка;
• тип и версию базы данных;
• доступный объём диска;
• оперативную память и процессорные ресурсы;
• ограничения на размер загружаемых файлов;
• возможность запуска фоновых задач;
• доступ к журналам ошибок;
• наличие автоматических резервных копий;
• поддержку SSL-сертификатов;
• возможность использовать нужные расширения.

Слишком старая версия серверного окружения может быть несовместима с современными компонентами CMS. Слишком новая версия также иногда вызывает ошибки в старом коде. Поэтому переносить сайт нужно не на «самую новую» конфигурацию, а на совместимую и поддерживаемую.

Создайте базу данных и пользователя

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

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

Настройте технический адрес

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

Для тестовой версии можно применить пароль на уровне сервера или запретить доступ посторонним пользователям. Файл robots.txt сам по себе не является надёжной защитой от просмотра тестового сайта, поэтому для закрытой копии лучше использовать авторизацию.

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

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

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

После загрузки проверьте:

• сохранилась ли структура каталогов;
• не изменились ли имена файлов;
• не потерялись ли файлы с точкой в начале имени;
• перенесены ли конфигурационные файлы;
• доступны ли изображения и документы;
• имеет ли веб-сервер права на чтение нужных файлов;
• не стали ли архивы и служебные файлы общедоступными.

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

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

Для переноса базы данных обычно создают экспорт на старом сервере, затем импортируют его в базу на новом хостинге. Способ зависит от размера базы и доступных инструментов.

После импорта необходимо проверить:

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

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

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

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

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

Также проверьте настройки:

• адреса сайта;
• пути к файлам;
• режима отладки;
• почтового сервера;
• ключей API;
• подключения к платёжным системам;
• связи с CRM;
• кэша;
• очередей фоновых задач.

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

Не переносите без проверки старые временные файлы, логи и доступные из браузера резервные копии. Они могут содержать пароли, токены и другую служебную информацию.

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

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

Проверьте основные страницы

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

Проверьте формы и уведомления

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

Если сайт использует отправку писем с сервера, после переноса сообщения могут перестать доходить из-за другой почтовой конфигурации. При необходимости настройте SMTP и проверьте адрес отправителя, доменную авторизацию и правила почтового сервиса.

Проверьте мобильную версию

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

Проверьте ссылки и изображения

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

Если сайт переехал в другую структуру каталогов, нужно заранее подготовить перенаправления. При сохранении прежних URL большинство внутренних адресов продолжит работать без изменений.

Как подготовить DNS к переключению

DNS связывает доменное имя с сервером. Для сайта обычно важна A-запись, а для почты — записи MX и связанные с ними настройки. Перед изменением сохраните текущую DNS-зону целиком.

Нельзя переносить только A-запись, не проверив остальные записи. Иначе сайт может открываться, но перестанет работать почта, проверка домена внешним сервисом или интеграция с платёжной системой.

Заранее определите:

• какие записи отвечают за сайт;
• какие записи используются почтой;
• есть ли отдельные поддомены;
• подключены ли сервисы аналитики и рекламы;
• используются ли TXT-записи для подтверждения домена;
• нужны ли CNAME-записи для внешних сервисов.

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

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

SSL и HTTPS после переноса

На новом сервере нужно установить SSL-сертификат и убедиться, что сайт открывается по HTTPS. Если сертификат не настроен, посетители могут увидеть предупреждение о небезопасном соединении.

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

• адрес с HTTP;
• адрес с HTTPS;
• вариант с www, если он используется;
• вариант без www.

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

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

Переключение домена на новый сервер

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

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

Порядок действий может выглядеть так:

1. Создать финальную резервную копию старого сайта.
2. Проверить актуальность файлов и базы данных на новой площадке.
3. Убедиться, что SSL и почта подготовлены.
4. Зафиксировать текущие DNS-записи.
5. Изменить записи, отвечающие за сайт.
6. Проверить доступность нового сервера.
7. Оставить