Сайт начал медленно открываться, хостинг регулярно сообщает о превышении нагрузки, а во время обновления каталога появляются ошибки. Решение кажется очевидным: найти новый сервер и перенести проект.
Но для SEO-специалиста переезд — это не просто копирование файлов. Достаточно забыть про robots.txt, SSL-сертификат или часть базы данных, чтобы поисковый робот вместо страниц получил ошибки.
Сама смена хостинга не должна привести к потере позиций. Основные риски связаны с недоступностью сайта, изменением URL и неправильной настройкой новой площадки.
Не меняйте всё одновременно
Одна из самых частых ошибок — совместить переезд с обновлением дизайна, сменой CMS и переработкой структуры сайта.
Если после запуска упадёт трафик, будет сложно понять причину. Проблема может находиться в сервере, шаблоне, редиректах, новых URL или закрытых от индексации страницах.
Безопаснее разделить работу:
- Перенести действующую версию сайта без изменения адресов.
- Убедиться, что трафик и сканирование восстановились.
- Только после этого менять дизайн, CMS или структуру.
Если домен и URL страниц остаются прежними, отправлять заявку на смену адреса в Google Search Console или Яндекс Вебмастере не нужно. Это обычная смена инфраструктуры, а не переезд на новый домен.
Подготовьте копию сайта заранее
Нельзя сначала переключить домен, а потом начинать устанавливать CMS, загружать базу и искать потерянные изображения.
На новом сервере должна находиться полностью работоспособная копия проекта. До переключения DNS проверьте:
- главную страницу;
- рубрики и карточки товаров;
- изображения и загружаемые файлы;
- поиск по сайту;
- формы обратной связи;
- регистрацию и авторизацию;
- оформление заказа;
- административную панель;
- отправку уведомлений;
- задания, запускаемые по расписанию.
Проверить копию можно через временный технический адрес или локальную настройку компьютера. Тестовую версию желательно закрыть паролем либо запретить её индексацию.
Главное — не перенести этот запрет на рабочий сайт. Случаи, когда после переезда на всех страницах остаётся noindex, происходят чаще, чем хотелось бы.
Что сравнить на старом и новом сервере
Внешне две версии сайта могут выглядеть одинаково, но по-разному отвечать поисковым роботам. Поэтому перед переключением нужно проверить несколько технических элементов.
URL страниц
Адреса должны остаться прежними. Если старая страница находилась по адресу /catalog/phone/, она должна открываться по этому же адресу и после переезда.
Случайное изменение постоянных ссылок способно создать сотни ошибок 404.
Коды ответа
Рабочие страницы должны возвращать код 200. Удалённые — 404 или 410. Постоянные перенаправления — 301.
Особое внимание следует уделить ошибкам 500, 502, 503 и 504. Они означают, что сервер не смог нормально обработать запрос.
Robots.txt
На новом сервере должен находиться правильный файл robots.txt. Проверьте, что в нём случайно не закрыт весь сайт или его важные разделы.
Сам файл также должен открываться без ошибок.
Sitemap
Карта сайта должна быть доступна по прежнему адресу и содержать актуальные страницы. После переезда не нужно создавать новую карту только из-за смены IP.
Canonical
Проверьте канонические адреса на нескольких страницах. Они не должны вести на временный домен, тестовый сервер или старую версию сайта.
HTTPS
SSL-сертификат необходимо установить до переключения трафика. Проверьте основной домен, версию с www и используемые поддомены.
Системы аналитики
Счётчики аналитики и подтверждение прав в панелях вебмастера должны сохраниться. Если для подтверждения использовался HTML-файл или метатег, убедитесь, что он присутствует на новом сервере.
Подготовьте DNS
Посетители и поисковые роботы находят сервер через DNS. После изменения IP часть пользователей некоторое время может продолжать попадать на старую площадку из-за кеширования записей.
Перед переездом желательно уменьшить TTL — время хранения DNS-записи. Сделать это лучше заранее, а не за пять минут до переключения.
Непосредственно перед сменой IP:
- Создайте свежую резервную копию.
- Перенесите последние изменения базы данных.
- Проверьте новый сервер ещё раз.
- Измените DNS-запись.
- Не отключайте старый сервер.
Для интернет-магазина особенно важно не потерять заказы, появившиеся между созданием копии и переключением. Поэтому окончательную синхронизацию базы лучше проводить в период небольшой активности.
Что проверить сразу после переключения
Не ограничивайтесь открытием главной страницы. Она часто кешируется и продолжает работать, даже если остальные разделы уже выдают ошибки.
Проверьте:
- несколько страниц из разных разделов;
- карточки товаров;
- страницы с параметрами и фильтрами;
- изображения и документы;
- robots.txt и sitemap;
- формы и оформление заказа;
- вход в административную панель;
- мобильную версию;
- загрузку сайта через разные интернет-сети.
В Google Search Console можно использовать проверку URL, чтобы увидеть страницу так, как её получает поисковый робот.
Если защита от ботов или DDoS настроена слишком жёстко, она может возвращать Googlebot ошибку 403. При этом сайт будет нормально открываться у владельца, но окажется недоступным для поисковой системы.
Следите за серверными ошибками
Кратковременное изменение активности Googlebot после смены хостинга считается нормальным. Поисковому роботу требуется время, чтобы проверить новую инфраструктуру.
Опаснее повторяющиеся ошибки 5xx и 429. Если сервер регулярно не справляется с запросами, Google начинает сканировать сайт реже. При продолжительной недоступности отдельные страницы могут со временем исчезнуть из индекса.
После запуска необходимо наблюдать за:
- ошибками сервера;
- временем ответа;
- загрузкой процессора;
- использованием оперативной памяти;
- свободным местом на диске;
- статистикой сканирования;
- количеством проиндексированных страниц;
- органическим трафиком.
Оценивать результат переезда по позициям в первое утро после переключения не стоит. Сначала нужно убедиться, что новый сервер стабильно отвечает пользователям и роботам.
Не выключайте старый сервер слишком рано
DNS обновляется у разных провайдеров не одновременно. Пока в журналах старого сервера остаются обращения, его отключать нельзя.
Оставьте прежнюю площадку доступной ещё на несколько дней и наблюдайте за журналами обоих серверов. Старый хостинг можно закрывать, когда запросы на него практически перестанут поступать, а новая версия будет работать без ошибок.
Обязательно сохраните резервную копию, сделанную непосредственно перед переездом. Если обнаружится критическая проблема, она позволит быстро вернуть рабочую версию сайта.
Когда более мощный сервер действительно поможет
Новый сервер не исправит тяжёлую тему WordPress, неоптимизированные изображения, плохие запросы к базе или десятки ненужных плагинов. Поэтому сначала нужно понять, что именно ограничивает проект.
Переезд оправдан, если прежняя площадка:
- регулярно возвращает серверные ошибки;
- не справляется с обычной посещаемостью;
- замедляется во время импорта или резервного копирования;
- не позволяет увеличить память или процессорные ресурсы;
- мешает работе нескольких размещённых сайтов;
- не даёт нормально настроить кеширование и окружение.
Если измерения подтверждают нехватку ресурсов, у HSTQ можно подобрать VPS/VDS или выделенный сервер и запросить помощь с переносом. Небольшому контентному проекту обычно достаточно VPS с разумным запасом, а выделенный сервер имеет смысл при постоянной высокой нагрузке, большой базе данных или размещении нескольких крупных сайтов.
Смена сервера сама по себе не поднимет сайт в поиске. Её задача — убрать технические ограничения, из-за которых страницы медленно открываются, периодически становятся недоступными или плохо сканируются.
Короткий план безопасного переезда
- Создать полную резервную копию.
- Развернуть сайт на новом сервере.
- Проверить страницы, формы, базу и файлы.
- Сравнить robots.txt, sitemap, canonical и коды ответа.
- Установить SSL-сертификат.
- Снизить TTL и выполнить окончательную синхронизацию.
- Переключить DNS.
- Проверить сайт через разные сети и инструменты вебмастера.
- Наблюдать за ошибками, нагрузкой и сканированием.
- Отключить старый сервер только после прекращения обращений к нему.
Правильно выполненный переезд почти незаметен. Пользователи продолжают открывать те же страницы, поисковые роботы получают прежние URL, а трафик постепенно переходит на новую инфраструктуру без длительных ошибок и аварийного восстановления.