Как перенести сайт на новый домен, CMS или хостинг и не потерять позиции в поиске. Пошаговое руководство по безопасной миграции: 301 редиректы, сохранение URL-структуры, проверка индексации, мониторинг трафика и типичные ошибки.
Введение: миграция — это операция на живом организме
Перенос сайта на новый домен, смена CMS или переезд на другой хостинг — это не техническая рутина. Это хирургическая операция на живом проекте, который приносит трафик, лиды и деньги. Одна ошибка — и позиции в поиске обрушиваются. Трафик падает до нуля. Бизнес теряет клиентов. По статистике SerpMax, около 40% самостоятельных миграций заканчиваются просадкой трафика на 30-70% в первые месяцы. И восстановление может занять от 3 до 12 месяцев.
Но миграция может пройти и гладко. Если следовать чек-листу, делать всё поэтапно и ничего не пропускать. В этом руководстве — полный алгоритм безопасной миграции сайта в 2026 году. От подготовки до постмиграционного мониторинга. Для любого типа миграции: смена домена, смена CMS, переезд на HTTPS, смена хостинга, изменение структуры URL.
Типы миграции сайта: что считается миграцией, а что нет
Не каждое изменение на сайте — миграция. Поисковики по-разному реагируют на разные типы изменений. Важно понимать разницу.
Смена домена (site.ru → new-site.ru). Самая рискованная миграция. Поисковики должны перенести весь ссылочный вес, историю и авторитет со старого домена на новый. Требует постраничных 301 редиректов и смены адреса в панелях вебмастеров. Риск потери трафика: высокий (20-50% временно, восстановление 3-6 месяцев).
Смена CMS (WordPress → Битрикс, самописная → WordPress). Средний риск. Если структура URL сохраняется — миграция проходит легче. Если URL меняются — фактически двойная миграция (CMS + URL). Требует постраничных 301 редиректов со старых URL на новые.
Переезд на HTTPS (HTTP → HTTPS). Низкий риск при правильной настройке. Структура URL та же, только протокол меняется. Нужен редирект HTTP→HTTPS и обновление sitemap. Трафик может временно просесть на 5-10% на 1-2 недели, затем восстанавливается.
Смена хостинга (тот же домен, та же CMS). Минимальный риск для SEO. URL, контент, структура — всё остаётся прежним. Меняется только сервер. Единственный риск — увеличение TTFB или снижение аптайма на новом хостинге.
Изменение структуры URL (/old-url/ → /new-url/). Средний риск. Массовое изменение URL даже без смены CMS требует постраничных 301 редиректов. Поисковики должны переиндексировать все страницы по новым адресам.
Подготовка к миграции: что сделать до переезда
Хорошая подготовка — 80% успеха миграции. Не начинайте переезд, пока не выполнены все пункты этого раздела.
1. Полный бэкап текущего сайта. Файлы сайта (все, включая скрытые), база данных (полный дамп), конфигурационные файлы (.htaccess, nginx.conf, wp-config.php), SSL-сертификаты, почтовые ящики, cron-задачи. Сделайте минимум две копии бэкапа в разных местах: на локальном компьютере и в облаке.
2. Аудит текущего сайта. Составьте карту всех страниц сайта с их URL (краулером типа Screaming Frog или через sitemap). Зафиксируйте текущие позиции в поиске по основным запросам (Яндекс.Вебмастер, Google Search Console, Топвизор). Запишите текущий трафик (Яндекс.Метрика, Google Analytics) — общий, по страницам, по источникам. Запишите текущие показатели Core Web Vitals (PageSpeed Insights). Сохраните все отчёты — они будут точкой сравнения после миграции.
3. Подготовка карты редиректов. Если URL меняются (новый домен, новая структура) — нужна таблица соответствия старых и новых URL. Каждая строка: старый URL → новый URL. Для каждого старого URL должен быть новый. Если страница удаляется — редирект на ближайшую релевантную страницу или на главную. Не оставляйте 404 ошибки для страниц, на которые есть внешние ссылки или трафик.
4. Подготовка нового сайта. Новый сайт должен быть полностью готов и протестирован на тестовом домене или локальном сервере. Проверьте: все страницы работают, формы отправляются, корзина функционирует, мобильная версия адаптивна, скорость загрузки не хуже текущей (желательно лучше), мета-теги заполнены, микроразметка настроена, SSL-сертификат работает, sitemap генерируется корректно.
Пошаговый план миграции: день X
День миграции — это чёткая последовательность действий. Ничего не пропускайте.
Шаг 1: Включите режим обслуживания на старом сайте. Посетители не должны видеть процесс переезда. Покажите заглушку: «Сайт переезжает на новый адрес. Мы вернёмся через час». Для поисковых роботов заглушка должна отдавать HTTP-статус 503 (Service Unavailable) с заголовком Retry-After: 3600.
Шаг 2: Перенесите файлы и базу данных. Скопируйте все файлы на новый сервер. Импортируйте базу данных. Проверьте, что новый сайт открывается по IP или временному домену.
Шаг 3: Настройте 301 редиректы. Это самый критичный шаг. Каждый старый URL должен 301-редиректить на соответствующий новый URL. Редиректы должны быть постраничными (не все на главную!). Для Apache: используйте .htaccess с RewriteRule или RewriteMap для массовых редиректов. Для Nginx: карта редиректов в конфигурации сервера. Проверьте несколько редиректов вручную: откройте старый URL и убедитесь, что он перенаправляет на правильный новый URL с HTTP-статусом 301.
Шаг 4: Настройте новый sitemap.xml. В sitemap должны быть только новые URL. Проверьте, что sitemap проходит валидацию и отдаёт 200 OK. Отправьте sitemap в Яндекс.Вебмастер и Google Search Console.
Шаг 5: Обновите внутренние ссылки. Все ссылки внутри контента должны вести на новые URL (не через редирект). Пройдитесь поиском по базе данных и замените старые URL на новые.
Шаг 6: Обновите канонические теги. Все canonical должны указывать на новые URL (не на старые и не на редиректы).
Шаг 7: Смените DNS на новый сервер. Измените A-запись домена на IP нового сервера. DNS обновляется от 1 до 48 часов. В это время часть пользователей будет видеть старый сайт, часть — новый. Это нормально.
Шаг 8: Сообщите поисковикам о смене адреса. В Яндекс.Вебмастер: Индексирование → Переезд сайта → укажите новый адрес. В Google Search Console: Настройки → Смена адреса → укажите новый домен (если меняется домен).
Постмиграционный мониторинг: что проверять после переезда
Миграция не заканчивается в день переезда. Следующие 2-3 месяца нужно пристально следить за показателями.
День 1-3 после миграции. Проверьте, что старый сайт больше не доступен напрямую (только через редирект). Проверьте выборочно 20-30 редиректов — все должны работать. Проверьте, что sitemap принят поисковиками без ошибок. Проверьте, что новый сайт доступен и работает корректно. Настройте мониторинг доступности нового сайта.
Неделя 1-2. Ежедневно проверяйте Google Search Console и Яндекс.Вебмастер на предмет ошибок. Мониторьте индексацию: старые URL должны постепенно заменяться новыми. Мониторьте трафик: допустима просадка до 20-30% в первые 2 недели. Если падение больше — ищите проблему. Проверяйте логи сервера на 404 ошибки — если есть, настройте недостающие редиректы.
Месяц 1-3. Трафик должен начать восстанавливаться. К концу 3-го месяца желательно выйти на 90-100% от домиграционного уровня. Продолжайте мониторить позиции и трафик еженедельно. Проверяйте Core Web Vitals — не ухудшились ли после переезда. Анализируйте поведение пользователей на новом сайте: глубина просмотра, отказы, конверсия.
Типичные ошибки при миграции и как их избежать
Ошибка 1: Все старые URL → на главную нового сайта. Это убивает ссылочный вес. Поисковики не понимают, куда делся контент, и обнуляют позиции. Решение: постраничные 301 редиректы. Каждая старая страница → на соответствующую новую.
Ошибка 2: Забыли про внутренние ссылки. Все ссылки внутри контента остались старыми. Пользователи переходят по ним и попадают на редирект (лишняя задержка) или на 404. Решение: заменить все внутренние ссылки в базе данных на новые URL.
Ошибка 3: Не настроили редирект HTTP→HTTPS. После переезда на HTTPS старые HTTP-URL не редиректят. Поисковики видят дубли: HTTP и HTTPS версии. Трафик делится между ними. Решение: обязательный 301 редирект HTTP→HTTPS для всего сайта.
Ошибка 4: Закрыли новый сайт в robots.txt. На тестовом сервере robots.txt был Disallow: / чтобы поисковики не проиндексировали тестовую версию. При переносе на production забыли изменить. Решение: всегда проверяйте robots.txt после миграции. Disallow должен быть снят.
Ошибка 5: Поторопились отключить старый сайт. Отключили старый хостинг через день после смены DNS. Но не все пользователи и поисковики обновили DNS-кеш. Часть аудитории видит мёртвый сайт. Решение: держите старый сайт с редиректами минимум 2 недели после смены DNS, лучше месяц.
Ошибка 6: Не отправили смену адреса в панелях вебмастеров. Поисковики не знают, что сайт переехал. Старый домен продолжает ранжироваться, новый — игнорируется. Решение: обязательно используйте инструменты «Смена адреса» в Яндекс.Вебмастер и «Change of Address» в Google Search Console.
Особенности миграции для разных типов сайтов
Интернет-магазин. Самая сложная миграция. Помимо страниц товаров и категорий, нужно перенести: корзину и оформление заказа (не должны сломаться), личные кабинеты пользователей (пароли, история заказов), платёжные системы (интеграция должна работать), складские и учётные системы (API, обмен данными). Мигрируйте магазин в низкий сезон. Закладывайте 2-3 недели на подготовку и тестирование. Обязательно тестируйте полный цикл покупки на новом сайте.
Блог или контентный сайт. Относительно простая миграция. Главное — сохранить все URL статей, мета-теги и внутреннюю перелинковку. Если меняется CMS, проверьте, что новый движок поддерживает старую структуру URL или настройте редиректы.
SaaS или веб-сервис. Критично сохранить: пользовательские сессии (пользователи не должны разлогиниться), API-эндпоинты (обратная совместимость или редиректы), платежи и подписки (не должны прерваться). Миграция SaaS требует координации команды разработки и тщательного тестирования.
Чек-лист миграции: короткая версия
До миграции: бэкап всего (файлы + БД + конфиги), аудит текущего сайта (URL, позиции, трафик, скорость), подготовка карты редиректов (старый URL → новый URL), подготовка нового сайта на тестовой среде, проверка нового сайта (все страницы, формы, скорость, мета-теги). День миграции: режим обслуживания на старом сайте, перенос файлов и БД, настройка 301 редиректов, настройка sitemap, обновление внутренних ссылок, обновление canonical, смена DNS, сообщение в панелях вебмастеров о переезде. После миграции: проверка редиректов (выборочно), проверка sitemap в панелях, мониторинг ошибок (GSC, Вебмастер), мониторинг трафика и позиций, старый сайт держать включённым 2-4 недели.
Часто задаваемые вопросы
Сколько времени нужно, чтобы трафик восстановился после миграции? При идеальной миграции: первая неделя — просадка до 20-30%, конец первого месяца — 80-90% от исходного, конец третьего месяца — 95-100%. При смене домена процесс может занять до 6 месяцев. При миграции с ошибками — год и более.
Нужно ли сохранять старый домен после переезда? Да, минимум на год. На старом домене должны быть настроены 301 редиректы на новый. Если старый домен освободится и его перекупит кто-то другой — вы потеряете весь ссылочный вес.
Как проверить, что все редиректы работают? Используйте краулер (Screaming Frog) в режиме List Mode: загрузите список старых URL, запустите проверку. Все URL должны возвращать 301 и вести на правильные новые страницы. Онлайн-инструменты SEO-аудита (SerpMax) также проверяют цепочки редиректов.
Что делать, если после миграции трафик упал, но ошибок нет? Это может быть временная переоценка сайта поисковиками (особенно при смене домена). Продолжайте мониторить, не делайте резких движений. Если падение затянулось на месяц — проверьте: не потеряна ли микроразметка, не изменилось ли качество контента, не упала ли скорость загрузки.
Можно ли мигрировать сайт по частям? Не рекомендуется. Поисковики видят сайт как единое целое. Часть страниц на старом домене, часть на новом — это два конкурирующих сайта с дублирующимся контентом. Мигрируйте всё и сразу.
