Перенос сайта на другой хостинг без потери SEO начинается с сохранения того, что уже работает: адресов страниц, контента, доступности и пользовательских сценариев. Копирование файлов — только часть задачи. После переезда должны приходить заявки, сохраняться заказы, открываться документы и корректно работать HTTPS.
В этой инструкции рассматриваем смену сервера или провайдера без изменения домена, протокола и URL страниц. Переезд на новый домен, переход с HTTP на HTTPS или перестройка адресов требуют отдельного плана. Абсолютное сохранение позиций обещать нельзя, но технические риски можно заранее обнаружить и уменьшить.
Что может пойти не так при смене хостинга
Удобно разделить риски на три группы: доступность сайта, целостность данных и работа отдельных функций. Например, главная страница может открываться из кэша, пока форма заявки уже возвращает ошибку. Поэтому проверка только первого экрана не подтверждает успешный перенос.
| Риск | Как проявляется | Что включить в проверку |
|---|---|---|
| Несовместимость окружения | Ошибки страниц или административной панели | Версии PHP и базы данных, расширения, лимиты ресурсов |
| Неполная копия | Пропали изображения, документы, свежие записи | Файлы, базу данных и изменения после первого копирования |
| Проблемы с HTTPS | Предупреждение браузера или цикл перенаправлений | Сертификат, доменные имена, настройки прокси и HTTPS |
| Нарушение интеграций | Заявка не попадает в CRM, заказ не обновляется | Полный путь тестового обращения и обработку ответов |
| Изменение SEO-настроек | Закрытые страницы, неверные canonical, новые 404 | Сравнение контрольных URL до и после переноса |
До начала работ назначьте ответственного за техническую часть и человека, который проверит бизнес-сценарии. Разработчик видит успешный ответ сервера; менеджер может заметить, что в заявке отсутствует выбранная услуга или файл клиента.
Подготовка: доступы, резервная копия и план отката
Составьте список сервисов, от которых зависит сайт: регистратор домена, DNS, хостинг, почта, CDN, CRM, платёжная система, аналитика. Уточните, кто управляет каждым из них. Доступ к панели нового хостинга ещё не означает возможность изменить DNS или перенести почтовые ящики.
Сохраните рабочую конфигурацию: используемые версии программ, фоновые задания, настройки отправки писем, каталог загрузок, внешние хранилища и правила перенаправлений. Согласуйте окно работ и ограничения для сотрудников: когда можно редактировать каталог и в какой момент изменения временно прекращаются.
Что должно быть в резервной копии
Для WordPress нужны и файлы, и база данных. В файлах находятся тема, плагины и загрузки, а в базе — записи и многие настройки. Храните копию отдельно от переносимого аккаунта и убедитесь, что её можно восстановить. Это соответствует рекомендациям WordPress по резервному копированию.
Зафиксируйте дату и время копии. Для сайта, где постоянно появляются заказы, архив вчерашней базы не заменяет финальную синхронизацию. В плане переноса отдельно укажите, какие данные способны измениться и как они попадут на новый сервер.
Когда нужен откат
Заранее определите стоп-сигналы: не работает оформление заказа, массово возвращаются ошибки, нельзя войти в личный кабинет или подтвердить целостность данных. Запишите, кто принимает решение, куда возвращается трафик и как сохраняются записи, созданные после переключения.
Копирование и тестирование до переключения
Подготовьте новое окружение и перенесите файлы, базу и конфигурацию. При сохранении домена не нужно массово заменять адреса сайта на технический поддомен. В WordPress проверьте подключение к новой базе и пути, зависящие от сервера. Сценарии с неизменными URL отдельно описаны в инструкции по переносу WordPress.
Проверять копию можно через локальное сопоставление рабочего домена с новым IP на компьютере специалиста. Для остальных посетителей продолжит открываться старый сервер. Такой способ позволяет тестировать сайт с привычным доменным именем, но не заменяет проверку реального маршрута после запуска, особенно при использовании CDN.
Тестовая среда не должна отправлять клиентам настоящие уведомления или повторно проводить платежи. Используйте тестовые режимы интеграций, отдельного получателя писем и ограниченный доступ. Фоновые задания копии должны быть настроены так, чтобы не дублировать работу основного сайта.
Закрывайте служебную копию авторизацией или ограничением доступа. Если доступная извне копия использует noindex, помните: это указание для поисковой системы, а не защита данных. Робот должен прочитать страницу, чтобы увидеть запрет; одного Disallow в robots.txt для гарантированного исключения URL из поиска недостаточно. Подробнее — в документации Google о noindex.
Проверяйте сценарий целиком
- Откройте главную, услугу, категорию, карточку товара, статью и несколько старых посадочных страниц.
- Отправьте тестовую заявку и проверьте её содержание у получателя, включая файлы и выбранные значения.
- Проверьте поиск, фильтры, вход, восстановление пароля и другие используемые функции.
- Для магазина проверьте корзину, доставку, создание заказа и тестовый сценарий оплаты без реального списания.
- Проверьте сохранение контента в административной панели, загрузку изображения и скачивание документа.
DNS, HTTPS и почта: порядок переключения
Подготовьте DNS заранее
DNS связывает доменное имя с инфраструктурой сайта. TTL задаёт срок кэширования записи: уменьшение значения не очищает уже существующие кэши мгновенно. Поэтому подготовку делают заранее, учитывая прежний TTL. Даже после изменения записи разные пользователи некоторое время могут попадать на разные серверы. Принцип описан в документации Cloudflare о TTL.
Смена хостинга не всегда требует смены NS-серверов. Если DNS остаётся у прежнего провайдера, обычно меняют нужные записи сайта. Проверьте A и, если используется IPv6, AAAA, а также вариант с www. При работе через CDN отдельно проверяют его сервер-источник: публичные IP могут принадлежать CDN и не совпадать с адресом хостинга.
Если меняется именно DNS-провайдер, сначала воспроизведите всю зону, включая почтовые и проверочные записи. При включённом DNSSEC согласуйте перенос подписей и записи DS у регистратора: несогласованная конфигурация способна нарушить разрешение домена.
HTTPS должен быть готов к приёму посетителей
До направления трафика убедитесь, что новый сервер обслуживает рабочий домен по HTTPS с корректным сертификатом. Заранее уточните, как хостинг выпускает и продлевает его. Например, подтверждение DNS-01 позволяет подтвердить управление доменом через DNS; HTTP-01 проверяет специальный ресурс веб-сервера. Условия различаются — они описаны у Let’s Encrypt.
Проверяйте не только наличие сертификата в панели, но и реальное открытие страницы без предупреждений. Отдельно проверьте основной вариант домена, перенаправления и отсутствие смешанного содержимого. За прокси неверное определение HTTPS может вызвать циклический редирект.
Почту проверяют отдельно от сайта
При сохранении почтового провайдера не заменяйте его записи настройками нового хостинга автоматически. MX определяет направление входящей почты, а SPF, DKIM и DMARC связаны с проверкой отправителей и обработкой писем. Их назначение разобрано в справке по почтовым DNS-записям.
Перенос сайта не переносит содержимое почтовых ящиков. Если почта находилась на старом хостинге, её миграцию нужно включить в отдельный план. После переключения отправьте письмо с внешнего адреса на корпоративный и обратно, затем проверьте уведомление из формы сайта. Это три разных проверки.
Синхронизируйте свежие данные
Перед окончательным переключением выполните согласованную синхронизацию. Для небольшого проекта может подойти короткое окно обслуживания, для активного магазина нужен способ избежать записи в две независимые базы. Нельзя рассчитывать, что все посетители одновременно начнут использовать новый сервер.
Практический контроль: зафиксируйте последний заказ до переключения, затем первый заказ после него и проверьте, что между ними нет пропусков. Аналогично сверьте заявки, загрузки и изменения остатков. Способ сверки зависит от CMS и интеграций; один только размер архива ничего не доказывает.
Какие SEO-параметры сравнить после переноса
Подготовьте контрольную выборку заранее: страницы с поисковым трафиком, основные услуги, категории, товары и несколько исторических URL с редиректами. Сохраните результаты до переноса, чтобы сравнивать конкретные изменения, а не оценивать сайт по памяти.
| Проверка | Ожидаемый результат |
|---|---|
| Адреса и содержание | Рабочие URL, основные тексты, заголовки и метаданные сохранены |
| Ответы сервера | Рабочие страницы доступны; старые перенаправления ведут куда нужно; несуществующий URL не маскируется под главную |
| Canonical | Указывает на правильный рабочий адрес, без технического домена |
| Индексация | На нужных публичных страницах не осталось тестового noindex или запрета доступа |
| Robots.txt и sitemap | Файлы доступны и содержат актуальные настройки и адреса |
| Ресурсы и скорость | Загружаются изображения, стили и скрипты; нет заметной деградации относительно замеров до переноса |
| Аналитика | Счётчики и цели работают, тестовая заявка отражается ожидаемым образом |
При неизменных URL создавать новые перенаправления «из-за переезда сервера» не требуется, но ранее действовавшие правила нужно сохранить. Инструменты смены адреса не заменяют настройку хостинга: Яндекс описывает переезд как изменение адреса сайта. Если одновременно меняются домен или протокол, это уже другой сценарий.
Контроль после запуска и отключение старого сервера
Сразу после переключения проверьте сайт на рабочем домене из разных сетей и повторите ключевой сценарий заявки. Следите за ошибками приложения, доступностью страниц и поступлением данных во внешние системы. В последующие дни сравнивайте поисковый трафик и обращения с сопоставимыми днями до переноса, учитывая рекламу и сезонность.
Google рекомендует наблюдать за трафиком на старой и новой инфраструктуре и отключать прежнюю, когда она больше не обслуживает пользователей и роботов. Временное изменение частоты обхода Googlebot после смены хостинга возможно; само по себе оно ещё не доказывает потерю позиций. См. руководство Google по смене хостинга.
Не прекращайте оплату старого аккаунта только потому, что новый сайт открылся у вас. Проверьте, не остались ли там почта, DNS, резервные копии, служебные поддомены или задания. После завершения наблюдения сохраните итоговую копию и обновите описание инфраструктуры для следующего специалиста.
Чек-лист для ответственного за перенос
- Определены границы: хостинг меняется, адреса страниц сохраняются.
- Доступы и зависимости перечислены, ответственные назначены.
- Резервная копия создана и проверена, правила отката согласованы.
- Новое окружение готово, закрытая копия протестирована.
- Проверены сертификат, DNS, почта и внешние интеграции.
- Согласованы финальная синхронизация и порядок приёма новых данных.
- После переключения проверены страницы, заявки, заказы и SEO-настройки.
- Результаты наблюдения сохранены, старые сервисы отключаются только после проверки зависимостей.
Частые вопросы
Влияет ли смена хостинга на позиции?
Риск связан прежде всего с последствиями переноса: недоступностью, ошибками, замедлением или изменившимися страницами. Сохранение URL и корректная работа сайта уменьшают технические риски, но не дают гарантии неизменных позиций.
Сколько может длиться перенос?
Срок зависит от объёма данных, состояния проекта, интеграций и способа синхронизации. Разделяйте время подготовки, окно переключения и период наблюдения. Обещание «перенести за час» без осмотра проекта не объясняет, какие проверки входят в работу.
Когда менять DNS?
Когда копия проверена, HTTPS готов, свежие данные синхронизированы и понятен порядок возврата при ошибке. Понижение TTL заранее помогает управлять кэшированием, но не гарантирует мгновенного переключения всех посетителей.
Что передать специалисту для оценки?
Адрес сайта, CMS, текущий и новый хостинг, примерный объём данных, список интеграций и ограничения по простою. Отдельно сообщите, где размещена почта и продолжают ли поступать заказы во время работ.
Как организовать перенос сайта
Если нужна помощь с переездом, начните с описания проекта и ограничений. В рамках технической поддержки сайта можно обсудить подготовку, перенос и последующий контроль. Результат, этапы и критерии проверки стоит закрепить заранее — подход разобран в статье об организации работ на действующем сайте.