Переезд сайта без потери позиций: полный SEO-чек-лист

Короткий ответ: переезд без потери позиций начинается не в день переключения домена, а с полной инвентаризации старого сайта. Для каждого ценного URL заранее определяют новый эквивалент, сохраняют контент и поисковые элементы, настраивают постоянный серверный редирект в один переход, открывают новый сайт для обхода и контролируют обе версии после запуска. Временные колебания возможны даже при корректной миграции, но хаотичное падение большинства кластеров обычно указывает на ошибку, а не на обязательный «период ожидания».

Главная идея этой инструкции — управлять не переносом файлов, а передачей поисковой ценности на уровне каждого URL. Для этого удобно разделить проект на четыре контура: инвентаризация, карта соответствий, технический запуск и контроль восстановления.

Что в SEO считается переездом сайта

Миграция — любое изменение, способное поменять доступный поисковой системе адрес, содержимое или способ обработки страницы. Масштаб риска зависит не столько от названия проекта, сколько от количества одновременно изменяемых сигналов.

Смена хостинга без изменения URL обычно проще, чем переход на новый домен. Google рассматривает эти сценарии отдельно: при смене инфраструктуры нужно подготовить новый сервер, переключить DNS и следить за трафиком, а при изменении адресов дополнительно требуется карта URL и постоянные перенаправления.

Переход на HTTPS тоже является изменением адресов. Его нельзя считать только установкой сертификата. Внутренние ссылки, canonical, Sitemap и другие сигналы должны указывать на HTTPS-версию. Подробная последовательность разобрана в материале HTTP или HTTPS: в чём разница и как перейти правильно.

Почему после переезда могут просесть позиции и трафик

Во время миграции поисковая система должна обнаружить новые адреса, пройти по редиректам, обработать страницы и заменить старые URL в своих системах. Это не происходит синхронно для всего сайта. Часть документов может обновиться раньше, часть — позже.

Умеренные колебания сами по себе не доказывают ошибку. Опасный сигнал — когда вместе с падением появляются технические аномалии:

• резко растёт число ответов 404;
• старые URL ведут на главную или нерелевантные разделы;
• новые страницы закрыты через noindex или robots.txt;
• canonical указывает на тестовый домен или старый адрес;
• внутренние ссылки продолжают вести через редирект;
• в Sitemap находятся старые URL;
• пропали важные тексты, товары, метаданные или структурированные данные;
• новый сервер отвечает медленно или нестабильно;
• аналитика не фиксирует часть посещений и конверсий.

Google прямо рекомендует составить соответствие старых и новых URL, настроить серверные постоянные редиректы и контролировать трафик обеих версий. Яндекс для смены домена предлагает отдельный инструмент «Переезд сайта», но он дополняет техническую настройку, а не заменяет её.

Главное правило: не объединяйте несколько больших изменений без необходимости

Одновременная смена домена, CMS, дизайна, структуры и текстов создаёт слишком много переменных. Если трафик снизится, команда не сможет быстро определить причину: редиректы, новый шаблон, удалённый контент, скорость, мобильная версия или изменившийся интент.

По возможности разделите проект на этапы. Например:

1. Сначала подготовьте и протестируйте новую CMS при сохранении структуры и содержания.
2. Затем выполните миграцию адресов.
3. После стабилизации индексации обновляйте архитектуру и контент отдельными итерациями.

Для крупного сайта полезен пилот на ограниченном разделе, который не зависит от резкой сезонности. Он показывает, как работают шаблоны, редиректы, логирование и мониторинг, пока ошибка ещё не затронула весь каталог.

Это не означает, что любой проект обязан растягиваться на месяцы. Если бизнесу нужен единый запуск, риски компенсируют более строгой подготовкой: полным архивом данных, автоматизированными проверками, тестовой средой и заранее утверждённым планом отката.

Шаг 1. Зафиксируйте исходное состояние

До разработки сохраните базовую линию. Без неё после запуска невозможно доказательно ответить, что именно потеряно и насколько сильное изменение произошло.

Выгрузите поисковые данные

Минимальный период — последние 3–6 месяцев, а для сезонного бизнеса полезно сравнение год к году. Сохраните:

• URL, клики, показы, CTR и среднюю позицию из Google Search Console;
• запросы и страницы из Яндекс Вебмастера;
• органические входы и конверсии из аналитики;
• брендовый и небрендовый трафик, если такое разделение настроено;
• регионы, устройства и поисковые системы;
• доход, заявки или другие бизнес-метрики по посадочным страницам.

Не ограничивайтесь общей посещаемостью. После переезда один кластер может восстановиться, а другой — исчезнуть. Сравнение по разделам и типам страниц обнаружит проблему раньше.

Чтобы будущий замер был воспроизводимым, заранее зафиксируйте регион, устройство, набор запросов и целевые URL. Для этого используйте единую методику из статьи как правильно проверить позиции сайта.

Сделайте технический снимок сайта

Полный обход должен сохранить не только список HTML-страниц, но и:

• код ответа каждого URL;
• Title, Description, H1 и canonical;
• директивы index/noindex и правила robots;
• внутренние входящие и исходящие ссылки;
• hreflang, пагинацию и структурированные данные;
• изображения, PDF, видео и другие индексируемые файлы;
• Sitemap и списки URL из CMS;
• скорость ответа и ключевые шаблоны.

Особенно важно объединить данные краулера с аналитикой и поисковыми кабинетами. Страница, которую обходчик не нашёл из-за слабой перелинковки, всё равно может получать трафик или внешние ссылки.

Сохраните резервную копию и доступы

Нужны резервные копии файлов, базы данных, конфигурации сервера, DNS, редиректов и тегов аналитики. Отдельно проверьте права владельца в Search Console и Яндекс Вебмастере, доступ к домену, хостингу, CDN, аналитике и менеджеру тегов.

Если покупается новый домен, до миграции проверьте его прошлое. Архивные версии, старые тематики, санкции и ссылочный профиль могут повлиять на запуск. Пошаговая проверка описана в руководстве как проверить историю домена.

Шаг 2. Соберите единый реестр старых URL

Один источник почти всегда неполон. В итоговый реестр нужно объединить:

• адреса из краулинга;
• URL из Google Search Console и Яндекс Вебмастера;
• посадочные из аналитики;
• страницы из XML Sitemap;
• URL с внешними ссылками;
• товары и категории из базы или фида;
• файлы и изображения, которые получают органические переходы;
• страницы рекламных кампаний, писем и партнёрских размещений.

После объединения удалите технические дубли, но не теряйте варианты протокола, www, регистра, слэша и параметров, если они реально доступны. Они понадобятся при тестировании правил.

Присвойте приоритет. Условная модель может выглядеть так:

Приоритет URL = органический трафик + конверсии + показы + внешние ссылки + бизнес-ценность

Это не формула ранжирования. Она помогает понять, какие адреса нужно проверить вручную в первую очередь и какие ошибки нельзя оставлять до следующего релиза.

Шаг 3. Создайте карту соответствий URL

Карта миграции — центральный документ проекта. В каждой строке находится старый адрес, его назначение и ожидаемое поведение после запуска.

Самая частая ошибка — массово перенаправить все удалённые URL на главную страницу. Пользователь ожидал конкретный товар, услугу или статью и попадает в общий раздел. Такой маршрут не восстанавливает содержание старого документа и усложняет диагностику.

Правильное соответствие строят по интенту и содержанию, а не по похожим словам в адресе. Если категория «офисные кресла» разделена на «эргономичные кресла» и «кресла для руководителя», старую страницу нельзя автоматически направить на первый найденный URL. Нужно определить, какая новая страница продолжает прежнее назначение, либо сохранить общую категорию.

Карту согласуют SEO-специалист, разработчик и владелец структуры до запуска. После релиза она становится основой автоматической проверки редиректов.

Шаг 4. Подготовьте новый сайт к запуску

Тестовая среда должна быть закрыта от индексации, но доступна команде и инструментам проверки. Одного запрета в robots.txt недостаточно для защиты конфиденциальной версии. Для staging-среды надёжнее ограничение доступа на сервере, например пароль или разрешённые IP.

Перед публикацией сравните старые и новые шаблоны. На эквивалентных страницах должны сохраниться:

• основной контент и важные смысловые блоки;
• Title, Description и H1 либо их обоснованно улучшенные версии;
• изображения и alt-тексты;
• хлебные крошки и внутренняя навигация;
• структурированные данные;
• языковые и региональные связи;
• авторы, даты и другие значимые атрибуты;
• формы, телефоны, корзина, оплата и события аналитики.

Редизайн нередко делает страницу визуально чище, но одновременно удаляет текст категории, ссылки на подкатегории и полезные ответы. Для пользователя интерфейс выглядит современно, а для поиска документ становится беднее и меняет назначение. Такие изменения нужно оценивать до запуска, а не объяснять ими падение после него.

Шаг 5. Настройте постоянные редиректы без цепочек

При окончательной смене адреса используйте постоянный серверный редирект — обычно 301 или 308. Google рекомендует постоянные серверные перенаправления, когда URL должен быть заменён в результатах поиска.

Проверка должна подтверждать четыре условия:

1. Старый адрес отвечает редиректом, а не страницей с сообщением и кодом 200.
2. Переход ведёт сразу на финальный URL.
3. Финальная страница отвечает кодом 200 и доступна для индексирования.
4. Цель соответствует содержанию и интенту исходной страницы.

Избегайте маршрутов вида:

http://old.example/page → https://old.example/page → https://new.example/page/

Лучше, чтобы все варианты старого URL сразу вели на единственный новый адрес. Цепочки увеличивают количество запросов, затрудняют обход и часто скрывают ошибку в одном из промежуточных правил.

Сохраняйте редиректы долго. Google советует держать их не менее года, а для пользователей и внешних ссылок разумно сохранять столько, сколько это практически возможно. Старый домен также нельзя сразу отпускать: иначе перестанут работать перенаправления, а адрес может приобрести другой владелец.

Шаг 6. Обновите сигналы на новом сайте

Редирект не должен компенсировать старые ссылки внутри новой версии. После запуска все управляемые сигналы должны указывать непосредственно на финальные URL:

• внутренние ссылки;
• canonical;
• XML Sitemap;
• hreflang;
• структурированные данные;
• Open Graph и карточки соцсетей;
• изображения и ресурсы;
• навигация, хлебные крошки и пагинация;
• фиды товаров и рекламные посадочные;
• ссылки в письмах, профилях и партнёрских кабинетах.

На каждой индексируемой новой странице обычно нужен самоссылочный canonical на её финальный адрес. Не оставляйте canonical на старом или тестовом домене и не направляйте все страницы на главную.

Внутренняя перелинковка должна работать без промежуточных перенаправлений. После замены URL полезно повторно проверить глубину клика, страницы-сироты и количество входящих ссылок. Практическая схема приведена в статье как сделать внутреннюю перелинковку сайта.

Шаг 7. Проверьте robots.txt, noindex и Sitemap

Одна из самых дорогих ошибок миграции — перенос ограничений тестовой среды на рабочий сайт. В момент запуска проверьте:

• нет ли общего Disallow: / или закрытых важных разделов;
• удалены ли временные noindex из HTML и HTTP-заголовков;
• доступны ли CSS, JavaScript и изображения, необходимые для рендеринга;
• содержит ли Sitemap только финальные канонические URL с кодом 200;
• нет ли в Sitemap старого домена, редиректов, 404 и закрытых страниц;
• указан ли актуальный адрес Sitemap в robots.txt;
• открываются ли файлы поисковым роботам без авторизации.

Sitemap помогает обнаружению адресов, но не отменяет внутренние ссылки и не гарантирует индексацию. После отправки нужно проверять фактическую обработку страниц. Разницу между обходом, включением в индекс и показами подробно объясняет статья как проверить индексацию сайта.

Шаг 8. Сообщите о смене домена поисковым системам

Для переезда на новый домен добавьте и подтвердите права на старый и новый ресурс в поисковых кабинетах.

В Google Search Console инструмент Change of Address используют при переходе с одного домена или субдомена на другой. Он не предназначен для обычного перехода с HTTP на HTTPS или изменения путей внутри того же домена. До отправки должны работать перенаправления и быть подтверждены обе версии.

В Яндекс Вебмастере на странице Индексирование → Переезд сайта указывают новый адрес при смене домена или доменной зоны. Новый сайт также должен быть добавлен и подтверждён.

После этого отправьте актуальный Sitemap для новой версии. Не удаляйте старые ресурсы из кабинетов: они нужны для контроля обхода, ошибок и остаточного трафика.

Шаг 9. Проведите запуск по протоколу

Лучшее время запуска — период, когда техническая, SEO- и бизнес-команды доступны для проверки. Выбор «тихой ночи» бессмысленен, если до утра никто не сможет исправить критическую ошибку.

Сразу после переключения

Проверьте вручную и автоматически:

• главную, ключевые категории, услуги, товары и статьи;
• случайную выборку URL каждого шаблона;
• приоритетные страницы с трафиком и конверсиями;
• 301/308 со старых адресов и код 200 на новых;
• отсутствие цепочек и циклов;
• canonical, robots и meta robots;
• новый Sitemap;
• мобильную версию и скорость;
• формы, звонки, корзину, оплату и цели;
• доступность для Googlebot и роботов Яндекса;
• логи серверов и всплески 4xx/5xx.

Проверку карты URL автоматизируют: система отправляет запрос к каждому старому адресу, фиксирует всю цепочку и сравнивает финальную цель с утверждённой таблицей. Ручной просмотр десяти страниц не подтверждает корректность десятков тысяч правил.

Шаг 10. Контролируйте восстановление по группам страниц

После запуска нужен отдельный дашборд миграции. Общий график органики слишком грубый: рост брендовых запросов может скрыть потерю категорий, а сезонность — создать впечатление просадки.

Рекомендуемый ритм контроля:

• в день запуска — несколько проверок в течение дня;
• первые 72 часа — ежедневная техническая диагностика;
• первые 2–4 недели — сравнение разделов и приоритетных URL несколько раз в неделю;
• далее — еженедельный мониторинг до устойчивого переноса основных кластеров;
• после стабилизации — обычный регулярный SEO-контроль.

Не устанавливайте единую дату полного восстановления для любого сайта. Скорость зависит от размера, частоты обхода, качества редиректов, масштаба изменений и спроса. В статье сколько времени занимает SEO-продвижение объясняется, почему внедрение, обработка поисковой системой и накопление данных идут с разной скоростью.

Кто отвечает за каждый этап

Миграция проваливается не только из-за неверной настройки, но и из-за размытой ответственности. Фраза «редиректы делает разработчик» недостаточна: разработчику нужна утверждённая карта, а SEO-специалисту — доступ к тестовой среде и срок на проверку.

У каждой критичной задачи должны быть срок, критерий готовности и доказательство проверки. Например, не «редиректы настроены», а «99,8% адресов из утверждённой карты ведут одним постоянным редиректом на ожидаемый URL; оставшиеся ошибки перечислены и имеют срок исправления».

Частые ошибки при переезде

Все страницы направлены на главную

Так проще реализовать правило, но теряется смысл старых документов. Нужны соответствия на уровне страниц или корректный 404/410, если замены действительно нет.

Редиректы начинают готовить после запуска

В первые часы роботы и пользователи уже встречают ошибки. Карта и правила должны быть готовы и протестированы до переключения.

В Sitemap остаются старые URL

Поисковая система получает конфликтующие сигналы: редиректы говорят о новых адресах, карта сайта продолжает предлагать старые.

Canonical ведёт на старый или тестовый домен

Новые страницы сами сообщают, что основной документ находится в другом месте. Это нужно проверять по всем шаблонам, а не на одной странице.

Внутренние ссылки работают через 301

Пользователь обычно не замечает проблему, поэтому она долго остаётся в коде. Все ссылки новой версии должны вести прямо на конечные адреса.

Вместе с миграцией удаляют контент

Поисковая система получает не только новый URL, но и другой документ. Даже идеальный редирект не сохраняет релевантность удалённого материала.

Старый домен отключают слишком рано

Редиректы перестают работать, внешние ссылки ведут в пустоту, а команда теряет возможность анализировать старую версию.

Аналитику считают второстепенной

Если после запуска исчезают цели или меняется атрибуция, бизнес видит «падение SEO», хотя часть проблемы находится в измерении.

Что делать, если после переезда трафик резко упал

Не начинайте с массового переписывания текстов. Сначала локализуйте потерю.

1. Определите масштаб

Падает весь сайт, отдельный каталог, один тип страниц, Google, Яндекс, мобильные устройства или конкретный регион? Сравнивайте с базовой линией и учитывайте сезонность.

2. Найдите первый разрыв

Используйте последовательность:

Старый URL → редирект → новый URL → доступность → canonical → индексирование → показы → клики → конверсии

Если старый URL отвечает 404, дальнейший анализ позиции преждевременен. Если новая страница индексируется и получает показы, но CTR снизился, проблема уже не в редиректе.

3. Сравните потерянные URL с картой

Для страниц, которые раньше давали трафик, проверьте цель редиректа, сохранность содержания, Title, H1, внутренние ссылки и статус индексации.

4. Исправляйте системную причину

Одна ошибка шаблона способна затронуть тысячи страниц. Исправление десяти URL вручную не решит canonical, который CMS неверно формирует для всей категории.

5. Зафиксируйте изменения

В журнале укажите дату, затронутые шаблоны, исправление и ожидаемый сигнал. Иначе несколько команд начнут менять сайт одновременно, а диагностика снова станет невозможной.

Когда нужен SEO-аудит миграции

Для небольшого сайта с неизменной структурой достаточно аккуратной карты и проверки. Предварительный SEO-аудит сайта особенно важен, если:

• меняются домен, CMS и структура;
• в индексе десятки тысяч URL;
• есть фильтры, параметры и фасетная навигация;
• сайт работает в нескольких странах или языках;
• органика приносит существенную долю выручки;
• объединяются несколько доменов;
• старый сайт уже содержит дубли, цепочки и проблемы индексации;
• после запуска трафик не восстанавливается, а причина не локализована.

Задача аудита — не гарантировать отсутствие любых колебаний, а заранее обнаружить точки потери и создать измеримый протокол запуска.

Чек-лист руководителя перед разрешением на запуск

Миграцию можно выпускать, когда на следующие вопросы есть подтверждённые ответы:

• сохранена базовая линия трафика, позиций, конверсий и индексации;
• собран полный реестр старых URL;
• утверждена карта соответствий;
• приоритетные страницы проверены вручную;
• все правила редиректов прошли автоматический тест;
• новые страницы отвечают кодом 200 и открыты для индексации;
• canonical, внутренние ссылки, hreflang и Sitemap указывают на финальные URL;
• временные запреты staging-среды удалены с рабочей версии;
• аналитика и конверсии работают;
• права в поисковых кабинетах подтверждены;
• старый домен и сервер остаются доступными;
• назначены ответственные за первые 72 часа;
• определены критические ошибки и условия отката;
• подготовлен дашборд сравнения старых и новых разделов.

Если хотя бы карта URL или резервный сценарий отсутствуют, запуск превращается в эксперимент на рабочем трафике.

Частые вопросы

Можно ли переехать совсем без колебаний позиций?

Гарантировать неизменность нельзя: поисковые системы должны обнаружить и обработать новые адреса. Но полная карта, эквивалентный контент, прямые постоянные редиректы и мониторинг значительно уменьшают управляемые риски.

Как долго хранить 301-редиректы?

Google рекомендует сохранять редиректы не менее года. Практически полезно держать их дольше, если старые URL продолжают получать переходы или имеют внешние ссылки.

Нужно ли закрывать старый сайт в robots.txt после запуска?

Нет. Робот должен иметь возможность обратиться к старым URL и увидеть редирект. Блокировка обхода может помешать обработке перенаправлений.

Нужно ли удалять старые URL из поисковых систем вручную?

При корректных постоянных редиректах обычная миграция не требует массового удаления. Инструменты удаления предназначены для других задач и могут скрыть страницы раньше, чем будет обработан перенос.

Можно ли изменить структуру и тексты одновременно со сменой домена?

Технически можно, но диагностика становится сложнее. Если разделить изменения нельзя, сохраните подробное соответствие страниц и тестируйте содержание, метаданные и шаблоны до запуска.

Когда считать переезд завершённым?

Не в момент включения редиректов. Проект можно перевести в обычный режим, когда основные старые URL стабильно перенаправляются, новые страницы обрабатываются поисковыми системами, ключевые кластеры восстановили управляемую динамику, а критические ошибки закрыты.

Вывод

Безопасный переезд строится вокруг соответствия старый URL → новый эквивалент → проверяемый результат. Редирект — только один элемент. Поисковая ценность сохраняется, когда вместе с адресом перенесены смысл страницы, внутренние связи, канонические сигналы, доступность и измерение результата.

Самый надёжный порядок выглядит так:

Инвентаризация → карта URL → тестирование → запуск → контроль → исправление

Если миграция затрагивает домен, CMS, большой каталог или значимую долю органической выручки, включайте SEO в проект до разработки. Услуга комплексного SEO-продвижения помогает связать техническую миграцию с дальнейшей структурой, контентом и ростом, а не ограничивать работу одним днём переключения адресов.