Как перенести сайт на другой хостинг без потери данных
Чтобы перенести сайт на другой хостинг без потери данных, сначала подготовьте и проверьте копию на новой площадке, затем остановите или согласованно перенаправьте изменения, выполните финальную синхронизацию и переключите трафик. Старый хостинг сохраняют до подтверждения результата. Копирования файлов недостаточно, если сайт принимает заказы, хранит данные в базе, отправляет письма и выполняет фоновые задания.
Успешный переезд сохраняет страницы, заявки и заказы. Ниже — последовательность переноса работающего сайта: подготовка, проверка копии, переключение DNS, приёмка и план возврата. Отдельно рассмотрим WordPress и ограничения экспорта Tilda.
Что означает перенос сайта на другой хостинг
При смене хостинга приложение и его данные переходят на новую площадку, а посетителей направляют к ней. Домен может остаться прежним, как и компания, у которой он зарегистрирован. Перенос регистрации домена — отдельная процедура; для обычного переезда сайта она не обязательна.
DNS может обслуживаться у независимого поставщика. Иногда достаточно изменить адреса веб-сайта в действующей зоне. Смена NS означает передачу обслуживания DNS другому оператору и может затронуть почту и другие сервисы, поэтому требует отдельной подготовки.
Почему важно определить состав проекта
Статическому сайту нужны опубликованные файлы и работающий обработчик формы, если он есть. CMS обычно требует файлов, базы и совместимой среды. У приложения могут быть отдельные API, очереди, хранилище изображений и база вне веб-сервера. Перенос одного каталога не заменяет перенос этих компонентов.
Определите цель: устранить ограничения, улучшить сопровождение или получить совместимую среду. Переезд не исправляет автоматически ошибки кода и медленные запросы к базе: проблемы приложения могут сохраниться на новом тарифе.
Что лучше сохранить на время переезда
Сохраните домен, пути страниц и поведение сайта. Обновление CMS и переработку каталога удобнее планировать отдельно: так проще найти причину ошибки. Необходимые изменения для совместимости проверьте до переключения.
Что собрать до начала переноса сайта
Паспорт проекта показывает, что переезжает и кто управляет настройками. Доступ в CMS не всегда позволяет получить файлы, выгрузить базу или изменить DNS.
| Что проверить | Что зафиксировать | Зачем это нужно |
|---|---|---|
| Файлы и публикация | Рабочий каталог, загрузки пользователей, скрытые файлы, способ сборки и развёртывания | Перенести действующий проект вместе с нужными ресурсами |
| Базы и внешние хранилища | Тип, версия, объём, связи между компонентами, способ экспорта | Подготовить совместимое восстановление и согласовать состояние данных |
| Домены и DNS | Основное имя, www, поддомены, A, AAAA, CNAME, NS, TXT и MX | Изменить нужные направления и сохранить остальные сервисы |
| HTTPS и CDN | Сертификаты, способ выпуска, проксирование, origin, правила кеша и перенаправлений | Проверить защищённое соединение и путь запроса до приложения |
| Почта и интеграции | Почтовый сервис, SMTP, CRM, платежи, вебхуки, разрешённые IP | Сохранить доставку данных и доступ внешних систем |
| Фоновые процессы | Cron, очереди, импорт каталога, рассылки, обработка платежей | Исключить пропуск или двойное выполнение операций |
| Управление | Владельцы аккаунтов, ответственный за переключение, контакты поддержки | Принимать решения и устранять проблемы во время переезда |
Сохраните конфигурацию DNS и проверьте срок оплаты старой услуги: его должно хватить для тестов и наблюдения. Если сайт и почта входят в один пакет, отмена пакета затронет обе услуги.
Согласуйте окно работ и критерии готовности
Выберите период с небольшой нагрузкой и доступной поддержкой. Назначьте ответственных за переключение и проверку заявок. Отсутствие связи с базой или ошибка тестового заказа — основания не открывать новую площадку покупателям.
Заранее измерьте на копии длительность экспорта, передачи, импорта и проверки. Подготовку и репетицию переключения рекомендует руководство AWS по подготовке миграции; для небольшого сайта составьте список действий с ответственными.
Как подготовить новую площадку и перенести первую копию
Новую среду готовят до изменения публичного DNS, пока старый сайт работает. Первичная копия служит для тестов; перед запуском её данные обновляют.
Проверьте окружение и создайте отдельные ресурсы
Сопоставьте требования приложения и модулей с версиями языка, расширениями, базой, веб-сервером и лимитами. Проверьте фоновые процессы, исходящие соединения и журналы. Одной поддержки PHP для совместимости CMS недостаточно.
Добавьте сайт и домены в панель новой услуги. Проверьте публичный каталог: его назначение зависит от платформы. Создайте отдельную базу и пользователя с нужными правами. Не подключайте тестовую копию к старой рабочей базе, иначе изменения при испытаниях попадут в действующий проект.
Сохраните комплект и восстановите его на новой стороне
Получите файлы, экспорт базы и необходимые настройки. Для обычного WordPress нужны обе части: официальное руководство по резервным копиям отдельно описывает файлы и базу. Убедитесь, что комплект соответствует рабочей версии приложения и что его можно восстановить. Копию храните также вне старой услуги, с доступом для ответственного за перенос.
Передавайте данные через поддерживаемый защищённый способ: SFTP, FTPS, SSH или инструмент панели. Проверьте скрытые файлы, загрузки, размеры архивов и результат распаковки. Архив сайта и SQL-дамп не должны оставаться доступными посетителям в публичном каталоге. Для больших объёмов заранее уточните лимиты импорта и способ передачи у нового провайдера.
Импортируйте базу в подготовленный ресурс и укажите его параметры в конфигурации приложения. Имена базы, пользователя, адрес сервера и файловые пути могут отличаться от прежних. Эти этапы — файлы, база и исправление конфигурации — описаны, например, в инструкции Beget по переносу. Конкретные каталоги и действия в панели берите из документации своей услуги.
Не запускайте рабочие операции из тестовой копии
Отключите в новой копии реальные рассылки, списания и автоматические выгрузки; используйте тестовые режимы интеграций. Фоновые задания включайте по плану, чтобы две копии не выполняли одну бизнес-операцию одновременно.
Как проверить новый хостинг до переключения DNS
Проверка должна показать, что работает новая площадка. Открытие домена обычным способом до переключения часто продолжает вести на старый сервер, поэтому зелёная главная страница ещё ничего не подтверждает.
Проверяйте с правильным именем сайта
Временный адрес подходит для части проверок, но сайт может перенаправлять на основной домен. Для точной проверки направьте рабочее имя на новый адрес только на компьютере проверяющего либо используйте предпросмотр провайдера. Сервер должен быть настроен для этого имени.
Запись в hosts действует только на компьютере проверяющего. Настройте её по инструкции своей ОС для нужных имён и удалите после тестов. Внешние сервисы используют публичный DNS: открытая у разработчика форма ещё не подтверждает доставку платёжного вебхука.
Для проверки HTTP-заголовков без правки системного файла подходит curl --resolve. Команда ниже показывает синтаксис; IP из документационного диапазона необходимо заменить адресом своей новой площадки:
curl --head --resolve example.com:443:192.0.2.20 https://example.com/По документации curl, параметр задаёт адрес для конкретной пары имени и порта. URL остаётся example.com, что важно для выбора сайта и проверки сертификата. Команда проверяет ответ на HEAD, а не всю работу приложения. Перенаправление на www требует отдельной проверки этого имени; не считайте автоматически проверенной конечную страницу.
Подготовьте HTTPS до приёма посетителей
Новой площадке нужен действующий сертификат для используемых имён и корректная конфигурация HTTPS. Возможность выпустить его до переключения зависит от способа подтверждения домена. Например, DNS-01 у Let’s Encrypt подтверждает контроль через DNS, а HTTP-01 требует доступности проверочного файла по нужному домену. Согласуйте поддерживаемый способ с провайдером.
Ошибка сертификата требует исправления: отключение валидации не подтверждает нормальную работу HTTPS. При CDN отдельно проверьте соединение посетителя с CDN и соединение CDN с новым исходным сервером.
Пройдите действия реального пользователя
Проверьте внутренние страницы, изображения, поиск, вход, форму, загрузку файла и важные интеграции. Сопоставьте результат в браузере с записью в базе или CRM и доставкой уведомления. Не заменяйте этот маршрут проверкой «сервер отвечает 200»: приложение способно вернуть такой код вместе с неверным содержимым.
Ограничьте доступ к тестовой копии. Перед запуском проверьте временные запреты индексации, правила доступа и получателей писем. После настройки обновите нужные слои кеша, чтобы они не скрывали состояние сервера.
Как перенести сайт без потери новых заявок и заказов
Основной риск возникает между первой копией и переключением. Пока вы тестируете новый сервер, старый сайт принимает заказы, комментарии и загрузки. Если открыть подготовленную вчера базу, сегодняшние изменения в ней не появятся сами.
До переключения источником актуальных данных остаётся старая площадка; после согласованного запуска — новая. Две независимые базы, одновременно принимающие рабочие изменения, требуют специального механизма согласования. Обычное копирование файлов такой механизм не создаёт.
Практический вариант: согласованная пауза записи
Для многих сайтов подходит окно обслуживания: приостановить изменения, синхронизировать данные и открыть проверенную новую площадку. Пауза затрагивает отдельные функции или весь сайт в зависимости от архитектуры.
- Зафиксируйте начало окна. Предупредите редакторов и сотрудников, остановите публикации и импорты, которые изменяют переносимые данные.
- Приостановите источники записи. Учтите формы, заказы, API, фоновые задания и внешние уведомления. Надпись «технические работы» на главной не блокирует автоматически эти каналы.
- Дождитесь завершения текущих операций. Выясните состояние начатых платежей и заданий. Заранее определите, где сохраняются события, пришедшие во время паузы.
- Сделайте финальную согласованную копию. Перенесите актуальную базу и изменившиеся файлы, включая загрузки пользователей. Состояние файлов должно соответствовать ссылкам и записям в базе.
- Проверьте восстановленные данные. Сопоставьте последние реальные записи, их статусы и связанные файлы. Одно совпадение числа строк не доказывает полноту переноса.
- Переключите трафик и откройте запись на новой стороне. Старую копию сохраните без самостоятельного приёма новых данных; включите фоновые операции только в выбранной рабочей среде.
Непрерывно изменяемой системе могут понадобиться репликация или перенос приращений с контролем отставания. В руководстве AWS по миграции баз данных рассмотрены разные подходы; выбор зависит от допустимой паузы и устройства приложения.
Что делать с платежами, очередями и формами
Начатый до работ платёж может завершиться при закрытом интерфейсе. Проверьте правила доставки уведомлений и обработку накопленных событий у конкретного сервиса. Не предполагайте, что любой запрос повторится или его повторная обработка безопасна.
Если временное сохранение не подготовлено, согласуйте ограничение функций и ручную сверку. После запуска сопоставьте оплаченные операции с заказами, а заявки — с CRM. Ответственный должен разобрать расхождения по идентификаторам.
Как обслуживать посетителей со старым DNS
Часть клиентов некоторое время будет попадать на прежний адрес. Старое приложение должно оставаться без независимой записи: например, показывать сообщение об обслуживании либо передавать запросы новой системе через заранее настроенную и проверенную схему. Последний вариант требует корректной работы HTTPS, сессий и методов запросов.
Обычный редирект на то же доменное имя проблему не решает: клиент с прежним DNS снова может прийти на старый сервер. Поэтому обещание «простоя не будет» должно опираться на архитектуру и испытания. Короткая запланированная пауза для небольшого магазина часто управляемее, чем одновременный приём заказов двумя несогласованными копиями.
Как переключить домен, CDN и почту на новую площадку
DNS меняют после приёмки новой среды и финальной синхронизации. До начала работ сохраните старые значения и список имён, которые относятся к веб-сайту. Адрес, выданный в панели хостинга, проверяйте вместе с инструкцией подключения: одна услуга требует A/AAAA, другая — CNAME на имя платформы.
Если DNS остаётся у прежнего оператора
Измените нужные A и AAAA либо целевое имя CNAME. Проверьте корневой домен, www и рабочие поддомены. Старый AAAA способен оставить пользователей IPv6 на прежнем сервере, даже если A уже обновлён. Если IPv6 новая площадка не предоставляет, согласуйте удаление устаревшего адреса вместо сохранения неработающего маршрута.
TTL можно уменьшить заранее в пределах возможностей DNS-провайдера. Но снижение значения не отменяет уже сохранённые ответы с прежним сроком. Cloudflare поясняет зависимость обновления от предыдущего TTL. Универсального обещания «все увидят новый сайт через пять минут» нет: учитывайте прежнее кеширование и проверяйте фактический переход.
Если одновременно меняются NS
Сначала подготовьте полную зону на новой стороне: веб-записи, поддомены, MX, TXT для почты и подтверждения сервисов, остальные используемые записи. Только затем меняйте делегирование в управлении доменом. При включённом DNSSEC согласуйте перенос подписанной зоны и сведений о ключах по инструкции DNS-провайдеров: несогласованность проверки может нарушить разрешение имени.
Если перед сайтом работает CDN
При проксировании публичные IP могут принадлежать CDN и вообще не меняться после переноса исходного сервера. Меняют адрес origin или соответствующую конфигурацию в панели CDN, сохраняя нужное проксирование. Такое различие объясняет документация Cloudflare о режиме записей. Дополнительно проверьте TLS до origin, правила доступа, передаваемое имя и обновление кеша.
Что проверить, чтобы не потерять почту
Перенос веб-сайта не переносит автоматически почтовые ящики и письма. Если почтовый сервис остаётся прежним, сохраните его записи и действующую услугу. Если он меняется, составьте отдельный план переноса содержимого ящиков, настроек клиентов и переключения MX. Проверьте входящие и исходящие письма, а не только наличие адресов в панели.
Отдельно проверьте отправку уведомлений сайта через SMTP и соответствие DNS-настроек требованиям почтового провайдера, включая SPF, DKIM и DMARC. Рабочая форма без доставленного уведомления может выглядеть исправной для посетителя и при этом оставлять отдел продаж без заявки.
Как перенести WordPress на другой хостинг
WordPress можно переносить вручную, инструментом провайдера или подходящим миграционным плагином. Выбор зависит от размера проекта, ограничений импорта и состава сайта. Для магазина, Multisite и проекта с нестандартными интеграциями проверьте поддержку именно этих особенностей.
Если домен и адреса страниц сохраняются
Перенесите файлы и базу, обновите параметры подключения в wp-config.php, проверьте пути и настройки веб-сервера. Сам факт смены хостинга не требует заменять home и siteurl новым временным доменом. В руководстве WordPress по миграции перенос сервера отделён от изменения адреса сайта.
После восстановления проверьте постоянные ссылки, медиатеку, загрузку изображений, вход, отправку писем и задачи плагинов. Сопоставьте конфигурацию базы с фактическим ресурсом. В документации wp-config.php описаны параметры окружения и адресов; значения констант могут перекрывать сохранённые настройки CMS.
Если адрес всё же меняется
Замена домена или пути — дополнительная задача. Простая глобальная замена текста в SQL способна повредить сериализованные значения. Применяют инструмент, который понимает формат данных, после резервной копии и проверки области изменений. Например, WP-CLI search-replace поддерживает сериализованные данные и режим --dry-run, показывающий результат без записи.
Сначала определите изменившиеся URL, нужные таблицы и поля. Учитывайте структуру Multisite и сторонних плагинов. После замены проверьте изображения, ссылки, виджеты и интеграции.
Можно ли перенести сайт с Tilda на другой хостинг
У Tilda предусмотрен экспорт кода при наличии соответствующей возможности в текущем тарифе. Однако экспорт страниц не равен переносу всей платформы в самостоятельную CMS. По официальной справке Tilda, CRM и личный кабинет пользователей не экспортируются; каталог и ленты также остаются сервисами платформы со своими условиями работы.
Формы требуют отдельного внимания. Tilda указывает, что штатные приёмщики данных зависят от активной подписки; для экспортированного сайта важен настроенный домен. При отказе от таких сервисов нужен собственный подходящий обработчик. HTTPS на внешней площадке тоже настраивают отдельно.
Перед решением составьте список функций: формы, каталог, личный кабинет, платежи, шрифты и сторонние интеграции. Сверьте его с актуальными условиями экспорта. Если цель — полностью отказаться от платформы, может понадобиться разработка функций на другой системе; стоимость такой работы отличается от загрузки готового архива.
Что проверить после переключения сайта
Приёмку выполняют после перехода на новую среду, повторяя важные сценарии уже через обычный публичный адрес. Уберите локальные подмены hosts у проверяющих, иначе результаты будут описывать только их компьютеры. Проверяйте также свежие реальные события, появившиеся после запуска.
| Область | Проверка | Что подтверждает результат |
|---|---|---|
| Маршрутизация | Нужные имена, A/AAAA, CDN и журналы запросов | Посетители приходят в запланированную среду |
| Страницы | Главная, категории, карточки, поиск, изображения и файлы | Сохранились содержание, ссылки и пользовательские маршруты |
| Данные | Последние записи до переноса и первые после него | Изменения не потеряны и продолжают сохраняться в рабочей системе |
| Заявки и заказы | Отправка, запись в CMS/CRM, уведомление, тест платежа по правилам сервиса | Проверен весь процесс, а не только сообщение «успешно» |
| Обслуживание | Фоновые задания, очереди, резервные копии и журналы | Рабочая среда выполняет операции один раз и доступна для диагностики |
| Поисковая доступность | HTTPS, коды ответа, canonical, robots, временный noindex | После испытаний не осталось случайных ограничений для рабочих страниц |
Сравните ошибки и время ответа на одинаковых сценариях до и после переноса: это точнее впечатления от загрузки главной страницы.
Google рассматривает смену хостинга при сохранении URL как отдельный сценарий. В его рекомендациях есть проверка копии, снятие временных ограничений и наблюдение за журналами обоих серверов. Сохраните подтверждение прав в Search Console и доступность страниц. Смена площадки сама по себе не требует создавать новые URL или ставить редиректы на них.
Когда можно отключать старый хостинг
Ориентируйтесь на завершённые проверки, журналы и отсутствие нужных зависимостей от старой услуги. Убедитесь, что там не остались действующие почтовые ящики, DNS, задания, интеграции и единственная пригодная копия. Случайные обращения ботов к старому IP отличайте от запросов реальных клиентов и ваших сервисов.
Зафиксируйте, где теперь создаются резервные копии и кто отвечает за обновления. Отмена старой услуги завершает техническую и финансовую часть переезда; её выполняют после приёмки и сохранения необходимых данных, а не сразу после открытия новой главной страницы.
Как подготовить откат и не потерять данные при возврате
План возврата составляют до переключения. Запишите условия его запуска: недоступность критичной функции, повреждение данных или ошибка, которую нельзя устранить в согласованное время. Укажите ответственного за решение и сохраните прежние настройки маршрутизации.
| Ситуация | Что учитывать | Порядок решения |
|---|---|---|
| Новая площадка ещё не принимала рабочие изменения | Старая система может оставаться актуальной | Подтвердить состояние данных, вернуть маршрут и согласованно открыть прежнюю систему |
| После запуска появились новые заказы или загрузки | Старая база уже отстаёт | Остановить расхождение, сохранить новые данные и подготовить их перенос либо исправить новую среду |
| Обе копии принимали изменения | Возможны конфликтующие записи и повторные действия | Выбрать рабочий источник, сопоставить события и выполнить согласование с учётом бизнес-правил |
AWS отдельно различает откат без новых данных и возврат после новых транзакций. Для сайта это означает: переключить DNS обратно недостаточно, если на новой площадке уже появились оплаченные заказы. Сначала требуется сохранить и согласовать актуальные изменения.
Возврат DNS тоже подвержен кешированию. На период отката должен действовать понятный маршрут для посетителей и единый порядок записи. Перед повторным импортом сохраните текущее состояние обеих сторон; не перезаписывайте новую рабочую базу старым дампом без анализа изменений.
Сколько стоит перенести сайт и от чего зависят сроки
Стоимость зависит от объёма данных, совместимости, почты, интеграций, синхронизации и допустимой паузы. Информационный сайт и магазин с постоянными заказами требуют разной работы даже при одинаковом размере архива.
Уточните у нового провайдера, входит ли помощь в условия услуги и что именно она покрывает. Например, Beget описывает возможность обратиться за переносом в поддержку. Но наличие такой услуги у компании не означает, что любая нестандартная интеграция, перенос почты и непрерывная синхронизация автоматически входят в один объём.
- Кто получает копии и проверяет их восстановление?
- Кто отвечает за новые данные между первой копией и переключением?
- Какие домены, почтовые ящики и интеграции включены в работу?
- Кто меняет DNS, проверяет HTTPS и проводит приёмку?
- Что происходит при обнаружении ошибки и сколько длится наблюдение?
Учтите параллельную оплату двух площадок. Общий срок включает подготовку, тесты, переключение и наблюдение. Оценку разумно получать после инвентаризации и пробного восстановления.
Частые вопросы о переносе сайта
Можно ли сменить хостинг, сохранив домен?
Да. Домен и его регистратор могут остаться прежними. Нужно подготовить сайт на новой стороне и изменить соответствующее направление трафика. Убедитесь, что у владельца есть доступ к актуальному управлению DNS, а прежняя услуга не является единственным местом обслуживания нужной зоны.
Можно ли перенести сайт совсем без простоя?
Иногда архитектура позволяет переключиться без заметного перерыва. Но это зависит от хранения данных, сессий, интеграций и маршрутизации. Для обычного сайта с независимыми базами короткое окно обслуживания может быть надёжнее. Обещание должно опираться на проверенный способ синхронизации, а не только на быстрое копирование.
Почему после переезда часть посетителей видит старую версию?
Причиной могут быть прежние DNS-ответы в кеше, оставшийся AAAA, отдельные записи www, кеш CDN или браузера. Сравните точное имя, маршрут и журналы серверов. Обновление страницы в одном браузере не подтверждает, что все клиенты уже используют новую площадку.
Почему после переноса открывается главная, но не работают внутренние страницы?
Проверьте обработку URL, правила перенаправлений, конфигурацию веб-сервера, путь публикации и настройки CMS. У разных серверов правила маршрутизации могут задаваться разными способами. Восстановите ожидаемое поведение по документации приложения и провайдера, затем проверьте несколько типов страниц.
Нужно ли переносить почту вместе с сайтом?
Только если вы меняете и почтовую услугу. Почта может продолжить работать у прежнего поставщика при сохранении нужных записей и оплаты. Если ящики входят в старый хостинг, отдельно решите их судьбу до отмены этого пакета.
Чек-лист завершённого переноса
Считайте переезд завершённым, когда подтверждена работа проекта и определено дальнейшее обслуживание. Сохраните короткий итог: новая услуга, выполненные проверки, дата переключения, ответственные и оставшиеся действия.
- Файлы, база и нужные внешние компоненты восстановлены в совместимой среде.
- Последние изменения перед переключением и первые после него сверены.
- Рабочие данные принимает одна согласованная система; задания не дублируются.
- Проверены домены, IPv4/IPv6, CDN, HTTPS, формы, уведомления и почта.
- Рабочие страницы доступны по прежним URL без случайных тестовых ограничений.
- Резервное копирование и наблюдение действуют уже для новой площадки.
- Старая услуга отключается после проверки её зависимостей и сохранения данных.
Если планируете сменить хостинг сайта, начните с паспорта проекта и критериев приёмки. Познакомьтесь с SiteGuard и обсудите задачи вашего сайта: какие функции должны сохраниться, кто контролирует данные и как будет проверяться результат. Такое описание помогает предметно согласовать работу и дальнейшее сопровождение.