Сайт давно пора переносить, страницы открываются медленно, лимиты заканчиваются, поддержка отвечает через раз, а соседний провайдер предлагает более подходящие условия. Но владелец откладывает переезд по одной причине: «А что будет с позициями в Яндексе?» Если сайт уже получает поисковый трафик, страх вполне понятен. Потерять несколько часов на технические работы неприятно, потерять месяцы SEO-продвижения гораздо страшнее.
Хорошая новость в том, что обычная смена хостинга сама по себе не означает смену сайта. Домен может остаться тем же, адреса страниц тоже, контент никуда не исчезает. Для посетителя проект до и после переезда способен выглядеть совершенно одинаково. Меняется сервер, который отвечает на запросы.
Поэтому грамотно выполненная миграция обычно не должна превращаться в SEO-катастрофу. Опасен не новый хостер как таковой, а ошибки во время переезда: длительная недоступность, потерянные страницы, случайная блокировка индексации, неработающий HTTPS, изменившиеся URL или сервер, который после переключения начинает отдавать ошибки.
Именно здесь проходит граница между «сменили хостинг» и «сломали сайт во время смены хостинга». Для поисковой системы это совершенно разные события.
Что поисковая система увидит после переезда сайта
Представим страницу example.ru/catalog/product/. Вчера она находилась на одном сервере, сегодня находится на другом. Пользователь вводит тот же адрес, получает тот же материал, страница отвечает нормально, внутренние ссылки работают, HTTPS действует. Для поискового робота принципиально важнее доступность и содержимое URL, чем название компании, которой владелец сайта платит за сервер.
Это и есть основа безопасного переезда: сохранить то, что уже знает поисковая система.
Если домен не меняется, нет необходимости создавать новые адреса только из-за смены хостинга. Не нужно добавлять к URL новые папки, менять структуру постоянных ссылок WordPress или перестраивать каталог. Чем меньше лишних изменений происходит одновременно с миграцией, тем проще проверить результат.
По этой же причине не стоит использовать переезд как повод «заодно полностью переделать сайт». Новый хостинг, новая CMS, новый дизайн, новая структура URL и переписанные тексты в один день превращают простую техническую операцию в огромный набор изменений. Если после этого проседает трафик, установить причину становится намного сложнее.
Намного спокойнее сначала перенести существующую версию сайта как есть. Убедиться, что она стабильно работает на новой площадке. А редизайн, изменение структуры и другие крупные работы проводить отдельно.
Сам сервер, конечно, тоже способен косвенно повлиять на результат. Если после переезда страницы стали постоянно отвечать медленнее или сайт начал регулярно падать, это уже проблема для пользователей и обхода сайта роботами. Но обратная ситуация тоже возможна: старый хостинг был нестабилен, а новая площадка работает быстрее и надежнее. В таком случае нет логики держаться за плохой сервер исключительно из страха перед самим фактом миграции.
Важно не впадать и в другую крайность. Переезд на «более быстрый хостинг» не является кнопкой повышения позиций. Если сайт плохо структурирован, контент не отвечает на запросы пользователей, страницы перегружены скриптами или существуют другие проблемы, одна смена провайдера их не исправит.
Поэтому вопрос лучше ставить не «любит ли Яндекс новый хостинг», а «останется ли сайт после переезда таким же доступным и понятным для пользователя и поискового робота».
Самая безопасная миграция та, которую почти никто не замечает
Главная ошибка — сначала направить домен на новый хостинг, а уже потом начинать переносить сайт. В этот момент посетители могут попасть на пустую директорию, стандартную страницу провайдера или недонастроенную копию проекта.
Правильная последовательность обратная. Старый сайт продолжает работать. На новой площадке создается его копия. Переносятся файлы и база данных, настраивается нужная версия PHP и другие параметры. Новая копия проверяется. И только когда она готова принимать настоящих посетителей, переключается домен.
Перед миграцией нужна актуальная резервная копия, причем желательно не единственная копия, которая существует внутри панели старого хостинга. Файлы и база должны быть доступны независимо от старого аккаунта. Это дает возможность восстановиться, если что-нибудь пойдет не по плану.
После разворачивания копии нужно проверить ее до изменения DNS. Способ зависит от хостинга: временный адрес, технический домен, локальная запись hosts или другой вариант, предложенный поддержкой. Смысл один — увидеть будущий сайт на новом сервере, пока обычные пользователи все еще получают старую версию.
Проверять только главную страницу недостаточно. Откройте несколько материалов разных типов: запись блога, категорию, карточку товара, страницу контактов. Проверьте изображения, CSS и JavaScript. Зайдите в административную панель. Отправьте форму. Если есть поиск по сайту, воспользуйтесь им. Для магазина стоит проверить корзину и оформление заказа.
Отдельно полезно посмотреть HTTP-ответы важных страниц. Страница, которая должна существовать, должна нормально открываться, а не маскировать ошибку красивым шаблоном. Старые несуществующие URL не должны неожиданно превращаться в бесконечные перенаправления.
Если используются редиректы в .htaccess или конфигурации веб-сервера, нужно убедиться, что они переехали вместе с сайтом. Особенно это важно для проектов, которые раньше меняли структуру. Пользователь может уже давно не видеть старые адреса, но внешние ссылки и поисковый индекс все еще способны обращаться к ним.
Robots.txt тоже заслуживает отдельной проверки. Во время подготовки копии разработчики иногда закрывают тестовую площадку от индексации. Это правильно. Неправильно забыть такую блокировку после переключения рабочего домена.
С WordPress есть похожая ловушка. В настройках или SEO-плагинах тестовая копия может быть закрыта от поисковых систем. После миграции нужно убедиться, что рабочий сайт не унаследовал временный запрет.
HTTPS должен быть готов. На новом сервере обычно выпускается или устанавливается сертификат для того же домена. Если сайт до переезда работал по HTTPS, после миграции он не должен внезапно возвращаться к HTTP или показывать предупреждение браузера.
Также стоит проверить основной вариант адреса. Если раньше сайт всегда перенаправлял www.example.ru на example.ru, эта логика должна сохраниться. То же относится к перенаправлению с HTTP на HTTPS.
Сама процедура переноса подробно разобрана в статье о бесплатном переносе сайта на другой хостинг. С точки зрения SEO здесь важен принцип: сначала полностью подготовить новое место, а уже потом отправлять туда посетителей и роботов.
DNS создает больше тревоги, чем реальных SEO-проблем
Когда сайт готов, домен нужно направить на новый сервер. Именно этот момент часто описывают фразой «DNS обновляется до 24 или 48 часов», после чего владелец представляет, что сайт двое суток будет недоступен. Это не обязательный сценарий.
DNS-записи кэшируются. После изменения часть пользователей может некоторое время получать старый адрес сервера, а часть уже новый. Поэтому старый хостинг не следует отключать сразу после переключения.
Если обе копии сайта работают, посетитель в переходный период попадает либо на старый рабочий сервер, либо на новый рабочий сервер. Для обычного информационного проекта это может пройти практически незаметно.
Сложнее с сайтами, где данные постоянно меняются. Интернет-магазин получает заказы, форум новые сообщения, личный кабинет новые записи. Если часть пользователей работает со старой базой, а часть с новой, данные могут разойтись.
Для таких проектов миграцию планируют отдельно: выбирают период минимальной активности, выполняют финальную синхронизацию, иногда кратковременно ограничивают операции записи. Здесь уже важна не только SEO-безопасность, но и сохранность бизнес-данных.
После переключения полезно проверить домен из разных сетей или через инструменты проверки DNS. Не нужно паниковать, если на одном устройстве еще некоторое время отображается старая копия. Кэш может отличаться.
Если хочется понимать, что именно меняется при таком переключении, у нас есть отдельный материал про A, AAAA, CNAME, MX, TXT и NS-записи. Для самого переезда достаточно помнить главное: DNS определяет, куда отправляется запрос к домену, а регистрация домена при обычной смене хостинга может вообще оставаться на прежнем месте.
По этой причине не нужно одновременно переносить домен к другому регистратору, если такой задачи нет. Чем меньше независимых операций выполняется в один момент, тем меньше мест, где можно ошибиться.
Нельзя забывать и про почту. Если при смене NS создается новая DNS-зона, в ней должны сохраниться необходимые MX и TXT-записи. Потеря корпоративной почты не является SEO-проблемой в прямом смысле, но для бизнеса это может оказаться намного болезненнее небольшой просадки трафика.
Что действительно способно ударить по позициям после смены хостинга
Первый опасный сценарий — длительная недоступность. Короткий технический сбой и сайт, который систематически не отвечает роботам, не одно и то же. Но устраивать многочасовой или многодневный простой только потому, что перенос был плохо подготовлен, совершенно незачем.
Второй — массовые серверные ошибки. Если после переключения часть страниц отвечает 500, 502, 503 или 504, поисковая система видит уже не обычный переезд, а технически нестабильный ресурс. Причину нужно искать сразу, а не ждать, что «само устаканится».
Третий — потеря URL. Например, на старом сервере работали правила ЧПУ, а на новом забыли перенести конфигурацию. Главная открывается, владелец считает миграцию успешной, но сотни внутренних страниц возвращают 404. Вот это уже реальная угроза поисковому трафику.
Четвертый — случайный запрет индексации. Robots.txt, meta robots, настройки CMS или защитный режим тестовой площадки способны закрыть роботу доступ именно тогда, когда сайт уже считается рабочим.
Пятый — изменение canonical. Если тестовая копия создавалась на временном домене, нужно убедиться, что канонические адреса после переноса указывают на настоящий домен.
Шестой — неправильные редиректы. Цепочки из нескольких перенаправлений, циклы, отправка всех старых страниц на главную вместо соответствующих URL или исчезновение ранее настроенных 301 могут создать проблемы независимо от качества нового хостинга.
Седьмой — резкое ухудшение производительности. Новый тариф может оказаться слабее старого, иметь жесткие ограничения CPU или I/O либо плохо подходить конкретной CMS. Поэтому новый хостинг лучше проверять до окончательного отказа от старого.
Но здесь важно не превращать скорость в магический SEO-показатель. Быстрый сервер полезен прежде всего потому, что сайт быстрее и стабильнее работает для людей и роботов. Нет универсальной формулы «минус 300 миллисекунд равно плюс пять позиций». Поисковая выдача так не устроена.
Не стоит бояться и обычного общего IP виртуального хостинга только потому, что на нем находятся другие сайты. Сам факт соседства с чужими проектами не означает автоматического SEO-штрафа. При выборе площадки намного практичнее смотреть на стабильность, доступные ресурсы, качество поддержки, резервное копирование и работу самого сайта.
География сервера тоже не должна превращаться в суеверие. Сервер стоит выбирать с учетом аудитории, задержки, инфраструктуры, требований проекта и законодательства, если они применимы. Но ожидать, что один только переезд сервера из одного города в другой автоматически поднимет сайт в Яндексе, не стоит.
Вообще, если после смены хостинга позиции заметно изменились, полезно не назначать виновником сам переезд, а проверить факты. Все ли страницы доступны? Не изменились ли URL? Сохранился ли контент? Нет ли 5xx? Не закрыта ли индексация? Работает ли HTTPS? Не совпал ли переезд с обновлением алгоритмов, переделкой сайта или другими изменениями?
Чем меньше вещей менялось одновременно, тем проще ответить на эти вопросы.
Что проверить после переключения и когда можно отключать старый хостинг
После изменения DNS начинается самый недооцененный этап миграции. Владелец видит главную страницу и считает работу законченной. На самом деле именно сейчас стоит пройти сайт еще раз уже по настоящему домену.
Откройте ключевые страницы и несколько глубоких URL. Проверьте HTTP и HTTPS, www и основной вариант домена. Посмотрите формы, изображения, авторизацию и поиск. Если есть интернет-магазин, сделайте тестовый заказ. Проверьте отправку писем.
Затем загляните в Яндекс Вебмастер. Не требуется делать какие-то специальные манипуляции только потому, что сменился физический сервер при неизменном домене, но инструменты вебмастера полезны для наблюдения за доступностью и возникающими ошибками.
Посмотрите логи нового хостинга. Повторяющиеся 404, 500 или ошибки PHP иногда обнаруживаются там раньше, чем их замечают пользователи.
Проверьте sitemap.xml и robots.txt по настоящему адресу. Если карта сайта генерируется CMS или плагином, убедитесь, что она содержит правильный домен и доступна.
Не удаляйте старый аккаунт в тот же вечер. Дайте себе запас времени. Если выяснится, что забыта почтовая папка, отдельная база, Cron или какой-нибудь файл, возможность вернуться к старой площадке сильно упростит жизнь.
Когда DNS уже ведет на новый сервер, сайт стабильно работает, ключевые функции проверены, резервное копирование настроено и ошибок не видно, старый хостинг можно считать отработавшим свою роль.
Если вы только выбираете новую площадку, имеет смысл сравнивать не обещания «SEO-хостинга», а вещи, которые реально важны при эксплуатации: ресурсы, стабильность, резервные копии, техническую поддержку, возможность протестировать услугу и помощь с миграцией. Отправной точкой может стать рейтинг хостингов Hostingi.org, после чего условия понравившихся провайдеров стоит проверить уже под требования конкретного сайта.
Получается довольно простая картина. Если домен остается прежним, URL не меняются, содержимое сохранено, сайт доступен и сервер корректно отвечает на запросы, смена хостинга может пройти для поисковой системы почти буднично.
Бояться нужно не переезда, а переезда вслепую.
Иногда владельцы годами терпят медленный или нестабильный хостинг из опасения потерять позиции, хотя именно постоянные проблемы с доступностью уже мешают сайту. В такой ситуации отказ от миграции не защищает SEO. Он просто сохраняет существующую техническую проблему.
Поэтому хороший перенос не должен выглядеть как событие, после которого поисковику приходится заново знакомиться с сайтом. Адрес тот же, страницы те же, содержание то же. Для посетителя поменялось только одно: сайт теперь отвечает с другого сервера. Если все сделано правильно, большего ему знать и не требуется.
