Переезд сайта становится SEO-риском не потому, что поисковые системы «штрафуют» за миграцию. Проблема возникает, когда вместе со сменой домена, CMS или структуры меняются адреса страниц, исчезают внутренние связи, ломаются canonical, появляются цепочки редиректов или новая версия сайта оказывается недоступной роботу.
Поэтому задача состоит не в том, чтобы любой ценой сохранить старую техническую конфигурацию. Нужно дать поисковой системе понятную связь между прежними и новыми страницами и убедиться, что после переключения новая версия действительно доступна, индексируема и функционально заменяет старую.
Если переезд затрагивает страницы, которые уже получают органический трафик и заявки, миграция становится частью постоянной SEO-работы, а не только техническим релизом. Комплексное продвижение сайта после миграции здесь включает контроль редиректов, canonical, Sitemap, внутренних ссылок, переобхода и поискового трафика, чтобы после переключения быстро отличить нормальную переиндексацию от технической ошибки, которую нужно исправлять.
Что именно меняется при переезде и где возникает SEO-риск
Под «переездом» часто объединяют несколько разных сценариев. Для SEO между ними есть существенная разница.
При переходе с old-site.ru на new-site.ru меняется домен. При переходе с /catalog/item.php?id=15 на /catalog/item/ меняется структура URL. При переносе WordPress на другой сервер домен и URL могут вообще остаться прежними. А при редизайне адреса страниц иногда сохраняются, но меняются шаблоны, навигация, контент и способ рендеринга.
Самая чувствительная ситуация — изменение уже известных поисковым системам URL. В этом случае прежний адрес и новый адрес технически являются разными ресурсами, пока поисковый робот не обнаружит перенаправление и другие сигналы миграции.
Если меняется только хостинг, а URL, контент и HTTP-ответы остаются прежними, классической URL-миграции нет. Но SEO всё равно можно повредить: например, оставить закрывающий robots.txt от тестовой среды, получить 5xx из-за недостаточной мощности нового сервера или потерять часть изображений и скриптов.
При полном переносе на другой домен заранее проверьте зеркала сайта, варианты с www и без него, HTTP/HTTPS и используемые поддомены. Несогласованные версии адресов способны усложнить диагностику уже после запуска.
SEO при редизайне
Редизайн сам по себе не требует менять URL. Если задача — только обновить интерфейс, безопаснее сохранить существующие адреса страниц и отдельно протестировать новый шаблон.
Наибольший риск появляется, когда в один запуск объединяют новый домен, CMS, структуру каталога, дизайн и переписывание контента. При падении трафика становится сложно понять, какое именно изменение стало причиной.
Для крупного проекта полезно разделять такие работы хотя бы логически: сначала подготовить и проверить миграцию адресов, затем оценивать последствия редизайна и изменений контента.
Как подготовить переезд сайта до переключения
Первый рабочий документ миграции — не список задач разработчика, а таблица соответствия URL.
Для старой версии нужно собрать как минимум адреса из XML Sitemap, краула сайта, аналитики, Search Console или других поисковых панелей, внутренних ссылок и доступных данных о внешних ссылках. Особенно важно не потерять страницы, которые получают поисковый трафик, имеют внешние ссылки или служат важными точками навигации.
После этого для каждого адреса определяется результат.
| Старый URL | Решение после переезда | Проверка |
|---|---|---|
| Страница сохраняет смысл | Редирект на её новый URL | Старый URL → 301/308 → новый URL 200 |
| Несколько страниц объединяются | Редирект на новую объединённую страницу | Цель действительно заменяет старый контент |
| Контент удалён без аналога | 404 или 410 | Нет искусственного редиректа на нерелевантную страницу |
| URL не меняется | Оставить 200 | Контент, canonical и индексируемость сохранены |
Критическая ошибка — направить сотни удалённых страниц на главную только ради того, чтобы «не было 404». Редирект должен вести на содержательно подходящую замену. Если такой замены нет, корректный ответ о том, что ресурс удалён, зачастую точнее для пользователя и поискового робота.
На новой версии до запуска нужно проверить внутренние ссылки, canonical, hreflang при его наличии, Sitemap, robots.txt, meta robots, ссылки на изображения, CSS и JavaScript. Внутренние ссылки должны вести сразу на новые конечные адреса, а не проходить через собственные редиректы сайта.
Для новых индексируемых страниц canonical должен соответствовать их новой версии. Особенно опасна ситуация, когда после копирования тестовой среды в production остаётся noindex или canonical продолжает ссылаться на старый домен.
Если переезжает WordPress, одного изменения полей WordPress Address и Site Address недостаточно для любого сложного проекта: старый домен может оставаться в контенте, настройках темы, виджетах и данных плагинов. При массовой замене URL необходимо учитывать сериализованные значения; для WP-CLI разумнее сначала выполнять --dry-run, а при замене не менять guid записей.
Редиректы при переезде: что должно происходить на сервере
Для постоянного изменения адреса Google рекомендует серверные постоянные перенаправления, в том числе 301 и 308. Практически это означает простое правило: старый адрес должен как можно быстрее приводить к окончательному новому адресу.
Нормальная схема:
https://old.example.ru/services/seo/
→ 301
https://new.example.ru/services/seo/
→ 200Плохая схема:
old http URL
→ https old
→ www old
→ new domain
→ new path
→ 200Даже когда робот способен пройти такую цепочку, она создаёт дополнительные запросы, задержку и лишние точки отказа. Поэтому после запуска нужно проверить не только наличие редиректа, но и число переходов до конечной страницы.
То же относится к смена домена: правило «весь старый домен отправить на новый» недостаточно, если реальные внутренние страницы не получают адресного соответствия.
Проверьте отдельно параметры URL, пагинацию, языковые версии, изображения и документы, если они раньше получали трафик или внешние ссылки. Миграция не заканчивается HTML-страницами.
Как сообщить поисковым системам о миграции
После включения редиректов поисковому роботу всё равно требуется время, чтобы повторно посетить старые URL, обнаружить новые и обработать изменения.
При смене домена в Google Search Console используется Change of Address. Этот инструмент нужен именно для перехода между доменами или поддоменами. Для обычного изменения путей внутри одного домена или только перехода с HTTP на HTTPS он не применяется.
В Яндекс Вебмастере для смены основного адреса предусмотрен инструмент «Переезд сайта». Старый и новый адреса должны быть добавлены в Вебмастер, а новая версия — доступна роботу.
Одновременно отправляется актуальная Sitemap с новыми URL. Для нескольких отдельных приоритетных страниц можно использовать проверку URL и запрос переиндексации, но это не заменяет корректную архитектуру миграции большого сайта.
Что проверять сразу после запуска
В первые часы полезнее смотреть не на среднюю позицию сайта, а на техническую целостность новой версии.
Сначала повторите краул по сохранённому списку старых URL. Для каждой строки сравните запланированное состояние с фактическим. Старые переносимые адреса должны возвращать постоянный редирект, конечные страницы — 200, удалённые без замены материалы — корректный статус удаления.
Затем сделайте отдельный краул уже по новому сайту. Ищите внутренние ссылки на старый домен, 404, 5xx, лишние редиректы, страницы с noindex, конфликтующие canonical и URL, которые есть во внутренней навигации, но отсутствуют в Sitemap или наоборот.
На уровне поисковых систем контролируйте динамику старых и новых адресов. Нормальная миграция выглядит не как мгновенное исчезновение старого домена, а как постепенное замещение его URL новыми.
Падение позиций после переезда
Умеренные колебания после крупной миграции сами по себе ещё не доказывают ошибку. Google указывает, что после существенных изменений требуется время на повторный обход и индексирование URL.
Тревожнее не сам факт колебания, а технические симптомы рядом с ним: важная страница исчезла из индекса, старый URL перестал перенаправлять, новый URL закрыт от обхода, сервер выдаёт ошибки или поисковая система выбирает неожиданный canonical.
Поэтому сравнивать нужно группы URL. Например, если весь каталог просел одновременно и краулер показывает, что его страницы получили noindex, причина почти очевидна. Если технических ошибок нет, а изменения происходят неравномерно, одного факта миграции недостаточно, чтобы объявлять конкретную причину падения.
Потеря трафика после переезда
Трафик после переноса оценивают одновременно по старой и новой версии. На старом адресе органические входы должны постепенно сокращаться, на новом — появляться и расти по мере обработки новых URL.
Важно сравнивать не только общую сумму визитов. Разбейте данные по посадочным страницам и проверьте страницы, которые до переезда давали основную долю органического трафика.
Если одна из них потеряла трафик, откройте её строку в карте миграции и пройдите весь маршрут: старый HTTP-ответ → редирект → конечный URL → статус 200 → canonical → индексируемость → наличие внутренних ссылок → состояние в поисковой панели. Так проблема превращается из абстрактного «после переезда всё упало» в конкретную техническую проверку.
Практический сценарий: каталог переносится на новый домен
Представим сайт-каталог, где меняется домен, но основная структура разделов и содержание страниц сохраняются.
До запуска команда выгружает старые URL и обнаруживает три группы: страницы с прямым аналогом, несколько объединяемых материалов и устаревшие страницы без замены. Для первой группы составляются прямые соответствия, для второй выбираются реальные объединённые страницы, для третьей не создаются искусственные редиректы.
Новую версию краулят ещё до переключения и находят две проблемы: часть внутренних ссылок ведёт на старый домен, а тестовый noindex остался в одном шаблоне. Обе ошибки устраняются до публикации.
После переключения серверные редиректы активируются одновременно с открытием новой версии для роботов. Затем отправляется Sitemap, оформляется переезд в поисковых панелях и выполняется повторный краул списка старых URL.
Через некоторое время в поисковых системах старые страницы начинают заменяться новыми. Если отдельный раздел не переносится, команда проверяет именно его карту URL, шаблон и HTTP-ответы, а не меняет редиректы всего сайта вслепую.
В этом и состоит практический смысл миграционного чек-листа: он не гарантирует неизменные позиции, но позволяет знать, что должно произойти с каждым важным URL, и быстро находить отклонения.
Когда переезд можно считать технически завершённым
Дата переключения DNS или включения редиректов — только начало миграции. Технически спокойным состояние становится тогда, когда основные старые URL стабильно ведут на правильные новые адреса, новые страницы доступны поисковым роботам, не осталось массовых блокировок и цепочек, а индекс постепенно отражает новую структуру.
Редиректы после этого отключать сразу нельзя. Старые URL продолжают существовать во внешних ссылках, закладках и данных поисковых систем. Для Google официальная рекомендация — сохранять перенаправления как можно дольше и в целом не менее года.
Главный критерий успешного переезда — не отсутствие единого дня с просадкой в графике. Важнее доказать, что старая структура однозначно сопоставлена с новой, поисковые системы получают непротиворечивые сигналы, а возможные изменения трафика можно разобрать до уровня конкретного URL и конкретной технической причины.
Практика
Как безопасно перенести сайт с учётом SEO
Зафиксировать состояние сайта
Сделайте резервную копию, полный краул и выгрузки URL, органического трафика, индексируемых страниц и внешних ссылок, чтобы после миграции было с чем сравнивать результат.
Составить карту URL
Для каждого ценного старого URL определите один релевантный новый адрес либо решение 404/410, если материал действительно удаляется без замены.
Подготовить новую версию
На тестовой среде проверьте шаблоны, внутренние ссылки, canonical, robots.txt, meta robots, Sitemap, медиафайлы и HTTP-ответы до открытия сайта поисковым роботам.
Включить постоянные редиректы
Настройте прямые 301 или 308 со старых адресов на соответствующие новые страницы и исключите массовые редиректы на главную и ненужные цепочки.
Сообщить поисковым системам
Отправьте новую Sitemap, при смене домена используйте Change of Address в Google Search Console и «Переезд сайта» в Яндекс Вебмастере, затем выборочно проверьте ключевые URL.
Контролировать миграцию
Сравнивайте краулы, серверные ошибки, индексацию, показы, клики и трафик старых и новых URL; нормальный результат — постепенное исчезновение старых адресов и переход сигналов на корректные новые страницы.
FAQ
Как отличить нормальную миграцию от проблемного переезда
Гарантировать отсутствие колебаний нельзя. Google прямо предупреждает, что после значительных изменений позиции могут временно меняться, пока новые URL переобходятся и переиндексируются. Задача технически правильного переезда — не обещать неизменность позиций, а минимизировать потери сигналов и быстро обнаружить ошибки.
Для постоянного переноса Google рекомендует серверные постоянные редиректы, в том числе 301 или 308. Каждый старый URL лучше направлять сразу на его конечный релевантный аналог, избегая лишних цепочек. Для окончательно удалённого материала без подходящей замены корректнее вернуть 404 или 410, чем отправлять пользователя на главную страницу.
Да, если сайт переезжает с одного домена или поддомена на другой. Инструмент не предназначен для обычного изменения путей внутри того же сайта и не требуется для перехода только с HTTP на HTTPS. Использовать его следует после фактического переноса и настройки редиректов.
Сначала проверьте не позиции отдельных запросов, а технические причины: отсутствующие или ошибочные редиректы, 404/5xx, блокировки robots.txt, оставшийся noindex, canonical на старый адрес, потерянные внутренние ссылки и страницы, не вошедшие в карту миграции. Если технических ошибок нет, часть колебаний может быть связана с естественным переобходом и переиндексацией новых URL.
Google рекомендует сохранять редиректы как можно дольше и в целом не менее года. С пользовательской точки зрения постоянное сохранение корректных редиректов обычно предпочтительнее, особенно если на старые адреса продолжают вести внешние ссылки или сохранённые закладки.
Рейтинг статьи
Материал был полезен?
Оценка помогает понимать, какие материалы стоит обновлять и расширять.
