Перенос сайта на новый хостинг: пошаговая инструкция без потери данных

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

Когда перенос сайта на новый хостинг действительно нужен

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

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

• Сайт периодически недоступен или выдаёт ошибки 500 при обычной нагрузке.
• Поддержка провайдера отвечает с задержкой и не помогает восстановить работу.
• На текущем тарифе не хватает памяти, процессорного времени или места на диске.
• Хостинг не поддерживает нужную версию PHP, Node.js, базы данных или другие требования проекта.
• Резервные копии создаются нерегулярно, хранятся на том же сервере или не проверялись восстановлением.
• Проект вырос: появились каталог, личный кабинет, онлайн-оплата, CRM или постоянный поток заказов.

Сравнивайте не только цену тарифа. Уточните расположение серверов, качество поддержки, доступ к полному бэкапу, ограничения по базе и почте, наличие SSL и порядок восстановления после сбоя. Для посетителей из Казахстана имеет значение фактическое время ответа сервера, а не только заявленные характеристики.

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

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

Составьте короткий паспорт проекта. Он пригодится при смене подрядчика, восстановлении после сбоя и повторной миграции.

• Домен: регистратор, владелец аккаунта, контактные данные и двухфакторная защита.
• Старый сервер: панель управления, FTP или SSH, база данных, резервные копии и срок оплаченного тарифа.
• Новый сервер: IP-адрес, версии PHP или Node.js, доступ к базе, лимиты диска и памяти.
• Сайт: CMS или фреймворк, корневая папка, конфигурационные файлы и список нестандартных модулей.
• Почта: ящики на домене, MX-записи, пересылки, архив важных писем и способ авторизации.
• Интеграции: CRM, телефония, платёжный сервис, формы, карты, аналитика и рекламные кабинеты.

Зафиксируйте список важных URL, число товаров и заказов, работу форм, текущие DNS-записи, состояние SSL и дату последнего заказа. Для интернет-магазина на время переключения лучше ограничить изменения в каталоге или заранее согласовать короткое окно работ. Иначе новые заказы и правки могут остаться только на старой базе.

Как сделать резервную копию файлов и базы данных

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

В панели управления резервная копия часто создаётся через отдельный раздел. Если такой функции нет, скачайте корневую папку через FTP или SSH, а базу выгрузите из инструмента управления базой. Большой SQL-файл может не импортироваться через браузер из-за ограничения времени, поэтому для него используют консоль или помощь администратора.

• Скачайте корневую директорию сайта: public_html, www или папку, указанную в настройках домена.
• Экспортируйте каждую используемую базу данных, включая структуру таблиц и кодировку.
• Сохраните файл настроек CMS, .env, конфигурацию веб-сервера и параметры сборки, если они доступны.
• Запишите имя базы, пользователя, пароль, адрес сервера базы и используемый порт.
• Проверьте размер архива и наличие папок загрузок, изображений, документов и пользовательских файлов.
• Откройте SQL-файл в текстовом редакторе и убедитесь, что он не пустой и не оборван.

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

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

Перенос файлов и базы на новый сервер

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

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

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

• Создайте базу и пользователя на новом хостинге, используя отдельный сложный пароль.
• Импортируйте дамп с той же кодировкой, которая использовалась на старом сервере.
• Перенесите скрытые файлы, включая .htaccess, .well-known и конфигурации сборки.
• Обновите адреса базы и проверьте настройки домена, кэша, загрузок и временных файлов.
• Если изменился абсолютный путь, исправьте его в конфигурации и задачах планировщика.
• Проверьте права на папки и не выдавайте всему сайту разрешение на запись без необходимости.

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

Как проверить сайт до смены DNS

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

В файл hosts на компьютере временно добавляют IP нового сервера и домен. После проверки запись удаляют, иначе компьютер продолжит обращаться к новому серверу независимо от DNS. Если такой способ неудобен, попросите провайдера предоставить временный адрес и инструкцию для тестирования.

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

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

Смена DNS, почта и SSL после переноса

После проверки измените A-запись домена на IP нового сервера либо укажите новые NS, если DNS обслуживает хостинг. Обновление происходит не одновременно у всех пользователей, поэтому старый сервер оставляют доступным. Почту проверяют отдельно: её доставку определяют MX-записи, а не адрес сайта.

Доступ к домену должен оставаться у владельца бизнеса или ответственного сотрудника. Если домен .kz оформлял прежний подрядчик, заранее восстановите доступ к кабинету регистратора и проверьте контактные данные. Иначе технически готовый перенос может остановиться из-за отсутствия права изменить DNS.

• Сохраните текущие DNS-записи: A, AAAA, CNAME, MX, TXT и записи подтверждения сервисов.
• Поменяйте A-запись, если сайт остаётся на прежних DNS-серверах.
• При переходе на NS нового провайдера вручную проверьте MX и TXT-записи.
• Выпустите SSL на новом сервере и включите перенаправление с http на https после проверки сертификата.
• Отправьте письмо на доменную почту и ответьте с неё, проверив входящие, исходящие и пересылки.
• Не меняйте одновременно DNS, структуру URL и CMS: при ошибке будет трудно определить причину.

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

Проверка SEO и работы бизнеса после миграции

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

Сам перенос сервера не обязан менять поисковую видимость. Риск появляется, если новый сервер отдаёт ошибки, закрывает сайт от роботов, теряет изображения, меняет адреса или не поддерживает HTTPS. Проверьте панели вебмастеров, аналитику и рекламные объявления, чтобы убедиться в передаче целей и корректной работе форм.

• Откройте важные страницы и проверьте код ответа, заголовок, канонический адрес и наличие контента.
• Проверьте robots.txt и sitemap.xml по прежним путям, а также отсутствие случайного запрета индексации.
• Посмотрите сообщения о сканировании и доступности страниц в используемых панелях вебмастеров.
• Сравните скорость загрузки ключевых страниц до и после переезда, включая мобильное соединение.
• Проверьте цели аналитики: звонок, отправку формы, переход в мессенджер, корзину и заказ.
• Убедитесь, что контакты, адрес, карты и ссылки на мессенджеры отображаются без изменений.

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

Когда перенос лучше поручить специалистам

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

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

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

• Какие данные будут скопированы: файлы, базы, почта, SSL, DNS и резервные копии.
• Как проверят новый сервер до переключения домена и кто отвечает за тестовые заявки.
• Как сохранят URL, редиректы, robots.txt, sitemap.xml и настройки аналитики.
• Где будут храниться резервные копии и как долго старый хостинг останется активным.
• Что входит в стоимость, какие работы считаются дополнительными и кто оплачивает новый тариф.
• Какой отчёт или перечень проверок вы получите после завершения миграции.

Мы работаем с клиентами из Алматы и других городов Казахстана удалённо. Для новых проектов рекомендуем разделять доступы владельца и подрядчика: домен, хостинг и почта должны оставаться под контролем бизнеса. Для разработки новых сайтов домен .kz, хостинг и SSL на первый год входят в стоимость проекта, а хостинг мы рекомендуем выбирать у hoster.kz.

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

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

• Можно ли перенести сайт без отключения? Да. Копию разворачивают на новом сервере, тестируют и только затем меняют DNS. Старый хостинг оставляют активным на время обновления записей и контрольной проверки.
• Сколько длится обновление DNS? Изменения становятся заметны не одновременно у всех пользователей. Пока часть сетей обращается к старому IP, нельзя удалять старую копию или принимать необратимые изменения только на одном сервере.
• Пропадут ли позиции сайта после смены хостинга? Сам факт смены сервера не обязан влиять на SEO. Риск создают ошибки 5xx, закрытая индексация, потерянные URL и изображения, проблемы с SSL или неправильные редиректы.
• Нужно ли переносить почту вместе с сайтом? Не всегда. Если почта остаётся у прежнего провайдера, сохраните MX-записи. Если меняется почтовый сервер, заранее создайте ящики и перенесите важную переписку.
• Можно ли перенести интернет-магазин ночью? Можно, если выбранное время соответствует нагрузке и есть план возврата. Нужно учесть заказы, оплаты и изменения в каталоге, которые могут появиться во время переключения.
• Что делать, если после переноса сайт выдаёт ошибку 500? Не удаляйте старую копию. Проверьте версию PHP или Node.js, доступ к базе, права файлов, переменные окружения и серверные логи, затем сравните конфигурацию с рабочей версией.

С чего начать перенос сайта

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

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