Миграция сайта без потери позиций: полный разбор для Яндекса и Google

Миграцией называют любую смену, после которой поисковик заново узнаёт адреса сайта или его окружение: новый домен, переход на HTTPS, другую CMS, новую структуру URL, редизайн шаблонов, перенос на другой хостинг. Технически большинство таких переездов делается за день. Поисковой системе на то же самое нужны недели, а иногда и месяцы: Googlebot должен посетить каждый старый и каждый новый адрес, а Яндекс — признать новый адрес главным.

Обещание «переедем без потерь» в этой теме звучит чаще, чем выполняется. Яндекс в справке пишет: при смене главного адреса он «не гарантирует сохранение количества страниц сайта в результатах поиска, его позиций или посещаемости». Google говорит мягче — колебания видимости во время переезда «нормальны», позиции со временем стабилизируются. Самая большая независимая выборка — 1 052 смены домена (SALT, 2026) — даёт медиану возврата к прежнему трафику 304 дня, то есть около десяти месяцев.

Поэтому цель стоит сформулировать иначе: не потерять ничего по вине самого переезда. Аккуратный переезд снимает технические риски, но не обещает ни короткой просадки, ни полного возврата: после смены домена медиана возврата к прежнему трафику — 304 дня (раздел 2). Сайт с ошибками в редиректах, забытым noindex или закрытым robots.txt теряет трафик надолго, и такие ошибки описывают почти все публичные разборы неудачных переездов, которые я собрал для этой статьи. Я переносил сайты несколько раз, и после переезда трафик либо оставался прежним, либо рос. Держались эти переезды на двух документах, которые я собираю до начала работ: реестре всех страниц сайта и блочном макете с ТЗ на SEO-блоки. Оба описаны в разделе 4. Ниже — всё, что нужно, чтобы потери не случились по вине самого переезда.

Порядок переезда

1. Решениечто меняем и когда
2. Подготовкареестр, макет, точка отсчёта
3. Карта редиректовкаждому URL — аналог
4. Тестовая копияпроверка до запуска
5. Запускпорядок одного дня
6. УведомленияGoogle, Яндекс, Bing
7. Мониторингсутки, неделя, месяц, год

Какие бывают миграции и чем они рискуют

Слово «миграция» объединяет очень разные операции. Для поисковика смена хостинга без изменения адресов почти незаметна, а смена домена вместе с CMS и структурой URL — это фактически новый сайт, которому предстоит заново заслужить позиции. В Яндексе после смены домена, зоны, www или протокола «по каждому адресу находятся разные сайты». Пока Яндекс их не склеит, то есть не объединит в группу и не выберет главный адрес, они «могут участвовать в поиске отдельно друг от друга и конкурировать в выдаче».

Две закономерности видны сразу. Риск растёт с числом сигналов, которые поисковик должен пересчитать: адрес, контент, шаблон, внутренние ссылки. А вот когда нужны инструменты поисковиков, Google и Яндекс расходятся: Google просит «Изменение адреса» только при смене домена или поддомена, Яндекс — при любой смене главного адреса, включая HTTPS и www. Когда главный адрес не меняется (структура URL, CMS, редизайн на том же домене), всю работу делают редиректы.

Сочетания складывают риск. Google в справке инструмента «Изменение адреса» пишет: если совместить переезд с переделкой контента и структуры URL, вы «вероятно, увидите потерю трафика», потому что Google придётся заново изучать отдельные страницы. Отсюда первое правило: меняйте одно за раз (что делать, если совместить всё же приходится, — раздел 3).

Сколько трафика теряют при переезде и как долго он возвращается

Поисковики называют сроки уклончиво. Google пишет, что для сайта среднего размера может пройти «несколько недель или больше», прежде чем в выдаче появятся новые адреса вместо старых, для крупных — дольше. У Яндекса смена главного адреса происходит «в течение нескольких недель», а выполнение заявки на переезд может занять «от нескольких недель до месяцев». В 2018 году Яндекс оценивал склейку в «от нескольких дней до 3 недель» — сейчас формулировка осторожнее.

Независимые данные есть только по англоязычным сайтам, и все они построены на оценках сторонних инструментов, а не на Search Console. Но порядок величин они показывают.

Из этой же выборки видно, что риск зависит от исходной платформы и размера сайта. Сайты, уходившие с Magento, сохранили в медиане 57,2% трафика, а уходившие с Webflow и Next.js — 98–99%. Малые сайты (до тысячи визитов в месяц) удержали 57,5%, крупные (от 10 тысяч) — 84,1%. Подгруппы там небольшие, по 46–200 сайтов, поэтому это ориентир, а не прогноз для конкретного проекта.

Решение до начала: переезжать ли, когда и в каком порядке

Перед планом работ стоит ответить на четыре вопроса.

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

Одним шагом или поэтапно. Google рекомендует менять одно за раз: сначала домен, потом дизайн. Малые и средние сайты Google советует переносить целиком, крупные можно переносить по разделам, начиная с раздела, который меняется реже других — он станет тестом (Google оговаривается, что такой раздел не обязательно показателен). Если бизнес требует сменить домен и CMS одновременно, сохраните хотя бы пути URL и содержимое страниц: тогда меняется хост и шаблон, а не вся страница.

Когда. Не перед сезоном пиковых продаж и не во время заметных апдейтов поиска: по пересказу испанского исследования 175 миграций (MJ Cachón, по данным SISTRIX), 92% переездов в выборке пришлись на 90-дневное окно после апдейта Google, и разделить два эффекта задним числом почти невозможно. Совет не зависит от точности цифры: переезд удобнее оценивать в спокойный период.

Кто за что отвечает. На переезде одновременно работают разработчик, SEO-специалист, маркетолог и владелец доступов. Заранее соберите доступы: регистратор домена и DNS, хостинг старый и новый, Google Search Console и Яндекс Вебмастер для всех вариантов адреса, Метрика и Google Analytics, Merchant Center и Яндекс Товары, рекламные кабинеты, Яндекс Бизнес и Google Business Profile. Отсутствие одного доступа в день запуска откладывает уведомление поисковика на дни.

Подготовка: что собрать и сохранить до переезда

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

Данные за год важны из-за сезонности: страница новогодних подарков в октябре может не иметь ни одного визита, но в декабре кормит магазин. Google в руководстве советует брать логи за период, который учитывает сезонность, и не забывать изображения, видео, файлы CSS и JavaScript.

Не делите страницы на «важные» и «неважные» на глаз. В одном разборе переноса магазина электроники на Яндекс KIT страницы с драйверами и инструкциями за три месяца принесли 4 870 визитов, а каталог — 3 149. Без выгрузки из Метрики их бы сочли второстепенными.

Мой метод: два документа до начала работ

1. Реестрвсе страницы сайта и их новые адреса
2. Обход боевого сайтакраулер по полному списку старых URL
3. Сравнение404, редирект не туда, пропавший 301
4. Правка редиректовсразу, пока сигналы не ушли

Зафиксируйте точку отсчёта. За 2–4 недели до запуска снимите и сохраните:

• трафик из поиска по страницам и по типам страниц (Search Console, Вебмастер, Метрика) — и за тот же период прошлого года;
• позиции по ядру запросов в обеих поисковых системах, с телефона и с компьютера, лучше за несколько дней подряд;
• число страниц в индексе Google и Яндекса;
• конверсии и цели в Метрике;
• скорость загрузки по типам шаблонов.

Позиции в одном замере шумят сильнее, чем кажется. Автор разбора смены домена на Хабре (октябрь 2026) сделал два замера по 27 запросам с интервалом в час — у 13 запросов позиции разошлись больше чем на 10 мест. Его вывод: делать три прогона и брать медиану.

Сохраните старый сайт. Полная резервная копия файлов, базы и настроек сервера — само собой. Для SEO отдельно сохраните сырой и отрендеренный HTML каждой страницы из финального краула, robots.txt, все sitemap, выгрузки Search Console и Вебмастера: данные в консолях хранятся ограниченное время, а после переезда старый сайт уже не покажет, как выглядел title страницы, которая просела.

Предупредите хостинг нового сайта. После запуска Google обходит новый сайт интенсивнее обычного — Google пишет об этом в руководстве и советует проверить запас мощности сервера. Если сервер отвечает ошибками 5xx или 429, робот снижает скорость обхода, и переезд затягивается.

Не забудьте про сертификат старого домена. Если старый сайт работал по HTTPS, редирект со старых адресов сработает, только пока у старого домена действует сертификат: без него браузер и робот упрутся в ошибку соединения раньше, чем увидят 301. То же касается заголовка HSTS: если старый домен его отдавал, браузеры будут сами открывать его по HTTPS ещё долго после переезда. Продлевайте сертификат старого домена столько же, сколько держите редиректы.

Перечислите интеграции, завязанные на адрес. Авторизация через соцсети и OAuth, вебхуки CRM и платёжных систем, коллтрекинг, виджеты чатов, cookies согласия, политики CSP и CORS — всё это настроено на конкретный домен и после переезда молча перестаёт работать. Список составляют до запуска, а не по жалобам клиентов.

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

Карта редиректов: каждому старому адресу — свой новый

Карта редиректов — таблица из двух колонок: старый URL и новый URL. На ней держится весь переезд, и её качество определяет, сохранятся ли сигналы страниц. Принцип у Google и Яндекса общий: редирект ведёт со страницы старого сайта на аналогичную страницу нового.

Что делать с разными страницами.

Чего не делать — вести все старые адреса на главную нового сайта. Google пишет, что массовый редирект на одну нерелевантную страницу «может быть расценён как soft 404», то есть как страница, которая отвечает «всё в порядке», хотя нужного содержимого на ней нет. Яндекс формулирует иначе, но к тому же выводу: такой редирект неудобен пользователям и «снижает скорость индексации нового сайта». Для удалённого контента Google советует отдавать 404 или 410: Джон Мюллер в 2024 году говорил, что разница между ними для Google минимальна.

Код 200 на конце — ещё не проверка. Редирект может вести на существующую, но чужую по смыслу страницу. Перед запуском просмотрите выборку пар «старый → новый» по каждому типу страниц: товар ведёт на тот же товар или на замену, статья — на ту же статью, а не на раздел. Отдельно отберите адреса, куда сходится много старых URL: десяток товаров, переадресованных на одну категорию, — кандидат в soft 404.

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

1. ПравилаЕсли адреса меняются по шаблону (/catalog/item-123/ → /products/123/), карта строится регулярным выражением, а не построчно.
2. Точное совпадениепо идентификатору товара, артикулу, slug.
3. Нечёткое совпадениепо slug и заголовку — с порогом схожести и проверкой, что лучший кандидат заметно опережает второй.
4. Сходство содержимогоtitle, H1 и начало текста переводятся в числовые векторы (эмбеддинги), и программа ищет на новом сайте страницу с самым близким смыслом. Screaming Frog умеет это в режимах Near Duplicates и Embeddings; Марк Уильямс-Кук в Search Engine Land описывал скрипт, который сопоставляет 10 тысяч URL за несколько минут.
5. Ручная очередьдля всего, что осталось.

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

RewriteEngine On
RewriteRule ^catalog/item-([0-9]+)/$ /products/$1/ [R=301,L]

location ~ ^/catalog/item-([0-9]+)/$ {
    return 301 /products/$1/;
}

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

Двойной редирект в Яндексе. Если меняются и домен, и пути, Яндекс в справке описывает «двойной редирект»: старый адрес ведёт на новый домен со старым путём, а оттуда — на новый путь (сайт.рф/стр/ → example.ru/стр/ → example.ru/page/). Google, наоборот, советует вести сразу на конечный адрес. Противоречие снимается так: прямой редирект сайт.рф/стр/ → example.ru/page/ подходит обоим поисковикам, а промежуточный шаг Яндекс описывает как допустимый, а не обязательный. Если по техническим причинам проще сделать два шага, оба поисковика их пройдут, но лишний переход замедляет обход.

Редиректы: какие, где ставить и сколько держать

Какой код ответа. Здесь у поисковиков есть расхождения, и их стоит знать.

Для переезда во всех трёх системах подходит постоянный серверный 301 или 308. Утверждение «Яндекс не склеивает по 302» — миф: справка Вебмастера разрешает для переезда и 301, и 302. Но 302 сообщает «это временно», и при нём в индексе может дольше оставаться старый адрес, поэтому для постоянного переезда разумно ставить 301.

Отдельный случай — Next.js и некоторые CDN. Параметр permanent: true в next.config.js отдаёт 308, а не 301. Для Google и Яндекса 308 — тоже постоянный редирект, так что это не ошибка. Ошибка — клиентский редирект в одностраничном приложении: он вообще не отдаёт HTTP-код, и робот видит страницу с ответом 200.

Передают ли 301 «вес». Google в руководстве по переезду: «301 и другие постоянные редиректы не приводят к потере PageRank». Яндекс пишет, что при переезде «внешние ссылки старого сайта будут учитываться как внешние ссылки нового», а при переходе на HTTPS редиректы передают и показатели оригинальных текстов. Представление, что каждый редирект «съедает» часть веса и цепочка из трёх оставляет от страницы половину, в первоисточниках подтверждения не находит.

Цепочки. Googlebot проходит до 10 переходов, но Google советует вести на конечный адрес напрямую, а если не получается — держать цепочку короче трёх, в крайнем случае короче пяти переходов. На практике цепочки появляются не при переезде, а через год-два после него: старые редиректы с прошлого переезда ведут на адреса, которые теперь тоже редиректят. При новом переезде пересоберите старые правила так, чтобы каждое вело на финальный адрес.

server {
    listen 80;
    server_name example.ru www.example.ru;
    return 301 https://example.ru$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.ru;
    # здесь нужен действующий сертификат для www.example.ru
    return 301 https://example.ru$request_uri;
}

Где ставить. Лучше всего — на сервере или CDN: .htaccess для Apache, return 301 в конфигурации nginx, правила редиректов в Cloudflare. Плагины и модули CMS подходят, пока CMS работает: если сайт переехал на другой движок, редиректы из админки старого уйдут вместе с ним. Конструкторы — отдельная история: у Tilda и Wix правила редиректов перестают работать, как только DNS домена переключён на другой сервер (подробно — в разделе 15). Правила редиректов на старом домене должны жить там, где этот домен будет отвечать после переезда.

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old\.ru$ [NC]
RewriteRule ^(.*)$ https://new.ru/$1 [R=301,L]

server {
    listen 80;
    listen 443 ssl;
    server_name old.ru www.old.ru;
    # сертификат old.ru обязателен: без него HTTPS-запрос не дойдёт до редиректа
    return 301 https://new.ru$request_uri;
}

map $uri $new_path {
    default "";
    /catalog/drills/              /instrumenty/dreli/;
    /articles/kak-vybrat-drel/    /blog/kak-vybrat-drel/;
}
server {
    server_name old.ru www.old.ru;
    # listen и ssl — как в примере выше
    if ($new_path) { return 301 https://new.ru$new_path; }
    return 301 https://new.ru$request_uri;
}

curl -sIL http://www.old.ru/catalog/drills/ | grep -iE "^HTTP|^location"

HTTP/1.1 301 Moved Permanently
Location: https://new.ru/instrumenty/dreli/
HTTP/2 200

while read url; do
  curl -s -o /dev/null -L -w "%{http_code} %{num_redirects} %{url_effective} <- $url\n" "$url"
done < old-urls.txt

Сколько держать. У Google здесь две цифры. Справка инструмента «Изменение адреса»: держать редиректы «не меньше 180 дней», дольше — если на старые адреса ещё приходит трафик из поиска, а домен продлевать минимум год, чтобы его не перехватили для злоупотреблений. Руководство по переезду: «как можно дольше, как правило, не меньше года», а с точки зрения пользователей — бессрочно. Мюллер говорил, что три месяца — заведомо мало. Ориентируйтесь на год как минимум. Отключать редиректы стоит, когда в логах старого домена почти не осталось визитов людей и роботов. Если через год по старым адресам всё ещё много переходов, найдите, откуда они: забытая ссылка в рассылке, закладки, внешний сайт.

Тестовая копия: как проверить новый сайт и не пустить его в индекс

Новую версию собирают на тестовом домене или поддомене. Её нужно проверить целиком до запуска и при этом не дать поисковикам проиндексировать дубль.

Закрывайте паролем. HTTP-авторизация надёжнее всего: робот получает ответ 401 и не видит содержимого. Закрытие через Disallow в robots.txt не мешает URL попасть в индекс по внешним ссылкам, а noindex робот прочитает, только если страница не запрещена в robots.txt — иначе он её просто не скачает. Мюллер в 2019 году рекомендовал пароль по этой причине.

location / {
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

AuthType Basic
AuthName "Staging"
AuthUserFile /var/www/.htpasswd
Require valid-user

Не закрывайте рабочий сайт, пока он отвечает людям. Если люди уже ходят на новую версию, роботы должны видеть её в том же виде. Иначе можно повторить случай крупной розничной сети, которая три месяца держала новый сайт закрытым от роботов и почти потеряла трафик из Яндекса (раздел 18).

Что проверить на тестовой копии. Краулер умеет проходить авторизацию — в Screaming Frog и Sitebulb это настраивается. Проверка идёт в три слоя.

1. Редиректы — по полному списку старых URL, а не по выборке. Самый близкий к реальности тест — URL, которые Googlebot и Яндекс-бот запрашивали в последние 30–60 дней по логам. Ожидаемый результат: почти все отвечают 301 с одним переходом на страницу с кодом 200, ни одного ответа 200 по старому адресу без редиректа, 404 и 410 только там, где они записаны в реестре, и ноль ошибок 5xx.
2. Новый сайт — обходом краулером и сравнением со старым. В Screaming Frog режим сравнения краулов с сопоставлением URL показывает добавленные, удалённые и пропавшие страницы, изменения title, H1, canonical, числа слов и внутренних ссылок.
3. Шаблоны — по каждому типу страницы. Главная, раздел, карточка, статья, фильтр, пагинация, поиск по сайту.

День запуска: порядок действий

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

Можно ли запускать. Запуск идёт, только если на каждую строку ответ «да». Критерии — пример внутренних правил приёмки, а не требования Google или Яндекса.

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

1. Ещё раз выгрузить все URL старого сайта и сверить с картой редиректов: за время разработки могли появиться новые страницы.
2. Выложить новый сайт на боевой адрес.
3. Снять все временные запреты: HTTP-авторизацию, noindex в метатегах и заголовках X-Robots-Tag, Disallow: / в robots.txt. Постоянные запреты для служебных страниц (корзина, поиск, личный кабинет) оставьте. Забытый запрет — одна из самых частых причин в разборах неудачных переездов.
4. Включить редиректы и сразу прогнать краулером полный список старых URL.
5. Проверить robots.txt старого и нового сайта. Старый домен не закрывать: робот должен видеть редиректы. Для Яндекса файлы старого и нового доменов должны совпадать по содержимому и разрешать индексирование — иначе заявка на переезд не пройдёт.
6. Проверить canonical, hreflang, микроразметку на боевом адресе: в шаблонах часто остаётся адрес тестового домена. Если подаёте заявку в Яндекс, уберите rel="canonical" с новых страниц на время её проверки (раздел 10).
7. Выложить новый sitemap только с каноническими URL нового сайта и указать его в robots.txt.
8. Проверить счётчики Метрики и Analytics на новом домене, цели, электронную коммерцию, а также интеграции из списка подготовки: формы, оплату, CRM, коллтрекинг, вход через соцсети. В одном кейсе на ratingruneta.ru после переезда Метрика отсутствовала на сайте 12 дней — эти дни выпали из сравнения.
9. Подать уведомления поисковикам (разделы 9–11) и, если на сайте настроен протокол IndexNow, отправить через него новые адреса: его поддерживают Яндекс и Bing, Google в число участников протокола не входит.
10. Обновить адрес в рекламных кампаниях, фидах товаров, карточках организаций, рассылках, соцсетях, QR-кодах на упаковке. В одном разборе агентства VIPRO реклама после переезда месяцами вела на несуществующие страницы и стоила 200 тысяч рублей.
11. Следить за ошибками сервера и нагрузкой: обход роботами в первые дни вырастет.

curl -s https://example.ru/ | grep -i "noindex"
curl -sI https://example.ru/ | grep -i "x-robots-tag"
curl -s https://example.ru/robots.txt

User-agent: *
Disallow: /

Если меняется только сервер, а адреса остаются прежними, порядок проще — см. раздел 14, «Смена хостинга без изменения адресов».

Google Search Console: «Изменение адреса» и что ещё сделать

Когда инструмент нужен. Только при смене домена или поддомена. Для перехода с HTTP на HTTPS, переключения между www и версией без www на одном домене, переноса путей внутри домена и смены хостинга без изменения адресов инструмент не нужен — Google обходится редиректами и canonical.

Условия. Вы должны быть владельцем обоих ресурсов в Search Console под одним аккаунтом Google. Со старой главной должен стоять 301 на новую главную, и Google рекомендует 301 для всех канонических страниц. Перед приёмом заявки инструмент выборочно проверяет редиректы на нескольких страницах.

Ограничения, о которых узнают поздно. - Инструмент работает только на уровне домена: example.com, m.example.com, http://example.com. Перенести папку example.com/shop/ им нельзя. Зато можно перенести весь домен в папку другого: example.com → example3.com/new/. - Поддомены, включая www, инструмент не переносит. Если указать example.com, www.example.com и m.example.com останутся как есть. Подтвердите в Search Console все варианты старого домена и подайте заявку для каждого — даже для тех, которыми вы не пользуетесь. Это же Мюллер посоветовал владельцу сайта из истории с возвратом старого домена. - Протоколы переносятся вместе: заявка для http://example.com переносит и https://example.com. - Нельзя строить цепочку переездов: после заявки A → B нельзя сразу подать B → C. - Несколько сайтов в один лучше переносить последовательно (подробнее — раздел 14, «Слияние»).

Сколько длится. Заявка и уведомления в Search Console действуют 180 дней, и в течение этого срока переезд можно отменить (раздел 13). После него, по справке инструмента, Google «не видит никакой связи» между старым и новым сайтом и считает старый домен посторонним, если он доступен. Это срок действия заявки, а не редиректов: сами 301 после него не перестают работать, и Google советует держать их не меньше года (раздел 6). Старый сайт из индекса Google не удаляет: старые URL без аналога на новом сайте могут продолжать показываться в выдаче.

Что ещё сделать в Search Console: - подтвердить все варианты нового сайта (HTTP и HTTPS, www и без www) и, удобнее всего, ресурс-домен; - отправить новый sitemap; старый можно удалить, но на время мониторинга полезно держать оба файла, чтобы видеть, как старые адреса уходят из индекса, — Google упоминает это в разделе мониторинга; - перенести на новый ресурс файл отклонения ссылок, если он был; - проверить главную и несколько ключевых страниц через «Проверку URL» и запросить индексирование.

Яндекс Вебмастер: «Переезд сайта», главное зеркало и регион

В Яндексе переезд — это склейка: старый и новый адреса объединяются в группу, и новый становится главным. В разговорах SEO-специалистов живо и старое название — «склейка зеркал». Директиву Host в robots.txt Яндекс перестал учитывать в марте 2018 года — её заменил постраничный 301-редирект, и прописывать её сейчас бессмысленно.

Порядок. 1. Добавить в Вебмастер оба адреса и подтвердить права на оба. 2. Проверить, что оба сайта доступны. 3. Настроить редиректы со старых страниц на аналогичные новые. 4. Отправить заявку в разделе «Индексирование → Переезд сайта» для старого сайта. Для перехода на HTTPS там же включается опция «Добавить HTTPS».

Почему Яндекс отклоняет заявку. Справка перечисляет причины, и одна из них противоречит советам Google, поэтому на ней спотыкаются.

Сроки и что будет в выдаче. О сроках — в разделе 2. Пока новый адрес не стал главным, старые адреса остаются в выдаче, пока их аналоги на новом сайте не проиндексируются, а затем исчезают за несколько обновлений поисковой базы. После смены главного адреса справка допускает «заметное изменение» числа страниц в поиске, позиций и посещаемости в течение нескольких обновлений. Следить за процессом — в разделе «Индексирование → Страницы в поиске»: старые адреса постепенно сменяются новыми.

Что ещё не забыть в Яндексе. - Регион. При переезде регион нужно задать заново. Его можно указать для нового адреса заранее — он применится, когда адрес станет главным. Модерация занимает от нескольких дней до нескольких недель. Для сайтов с местным спросом это критично. - ИКС. При переходе на HTTPS индекс качества переносится, хотя правильное значение может отобразиться не сразу. Про смену домена справка такого обещания не даёт: ИКС главного и неглавного адресов с разными доменными именами считаются отдельно и могут различаться. - Яндекс Бизнес. Обновите сайт в карточке организации: заявка на изменение контактов проходит модерацию до трёх дней, ссылка должна вести на главную, а формат адреса (с www или без, HTTP или HTTPS) должен совпадать с главным адресом в Вебмастере. - Переобход страниц. Важные новые страницы и старые с редиректами можно отправить на переобход — по справке, они попадут в поиск в течение двух недель. Дневной лимит переобхода небольшой, поэтому отправляйте приоритетные адреса.

Ловушки API и отчётов. Тем, кто следит за переездом через API Вебмастера, пригодятся наблюдения из того же разбора смены домена на Хабре: main_mirror: null у нового домена значит, что он сам главный адрес; статус UNDEFINED значит «не проверялось», а не «ошибка».

Bing: Site Move

Для Bing достаточно 301-редиректов, инструмент Site Move в Bing Webmaster Tools только ускоряет процесс и не заменяет редиректы. В отличие от Google, Bing принимает переезд не только домена, но и поддомена и папки. Повторно переносить те же адреса можно не раньше чем через 180 дней, а срок, за который переезд отразится в индексе, Bing не гарантирует. Условия взяты из архивной версии справки, сверьте их в интерфейсе. В гостевом посте на официальном блоге Bing (2020) рекомендуют держать редиректы 1–2 года.

После запуска: что смотреть в первые сутки, неделю, месяц и год

Мониторинг — это не «посмотреть трафик через месяц». У каждого окна свои вопросы.

1. Первые часы и суткивсе старые URL отвечают 301 на страницы с кодом 200; нет 5xx и 404 на важных адресах; нет noindex и запретов; счётчики пишут визиты; формы и оплата работают; нагрузка на серверкраулер по полному списку старых URL, логи, Метрика в реальном времени
2. Первая неделяиндексация новых адресов; ошибки сканирования; доля ответов 301, 404, 5xx в логах; переход обхода роботов на новые адреса; позиции по ядруSearch Console: «Страницы», «Статистика сканирования»; Вебмастер: «Страницы в поиске», «Статистика обхода»; логи
3. 2–4 неделинаправление тренда видимости и трафика по типам страниц; страницы, которые не вернулисьнедельные срезы, сравнение с прошлым годом
4. 1–3 месяцаконтрольная точка: идёт ли возврат; страницы-аутсайдеры и их причинымесячные отчёты
5. 6–12 месяцевсколько трафика ещё приходит на старые адреса; живы ли внешние ссылки на старый доменлоги старого домена

grep -E "Googlebot|YandexBot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

  48210 301
  31544 200
    412 404
     37 503

Трафик упал: с чего начать. Таблица задаёт порядок первичной проверки, а не ставит диагноз.

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

Как отличить переезд от фона. Сравнение «до и после» обманывает: за те же месяцы меняются сезон, выдача и спрос. Сравнивайте с тем же периодом прошлого года и с контрольной группой страниц, которые при переезде не менялись (например, раздел, перенесённый 1:1, против раздела, где менялись адреса). Зачем это нужно, видно по контрольной группе PageSpeed Matters из раздела 2: у сайтов, которые вообще не переезжали, трафик за то же окно тоже снизился.

Клики из Яндекса после смены домена, разбор на Хабре

Правило первого месяца. Испанское исследование 175 миграций (в пересказе, см. раздел 3) даёт единственное найденное мной количественное правило решения: если видимость за первые четыре недели растёт, итоговый успех наступал в 83% случаев, если падает — в 30%; две трети восстановлений пришлись на первые два месяца, а без признаков улучшения за три месяца шансы резко падали. Из него стоит взять порядок контрольных точек: четвёртая неделя и третий месяц.

Откат: когда возвращаться и как

Откат — крайняя мера, но план отката нужен до запуска: решать его в панике дороже.

1. 1
   В первые сутки вскрылась ошибка, которую нельзя быстро исправить на новом сайте?

   Массовые 5xx, неработающие редиректы, потерянный контент, сломанная оплата.

   даОткатывайте, и чем раньше, тем лучше. Гэри Илш в 2016 году говорил: если страница выпала из индекса на несколько дней, сигналы сохраняются, за недели и месяцы часть из них теряется. Это давнее высказывание в пересказе, но оно объясняет, почему у отката есть окно.

   нетпереходите к шагу 2.

2. 2
   Переезд прошёл технически чисто, а трафик идёт ниже ожиданий?

   даОткат обычно не нужен: возврат на старый адрес — ещё один переезд с тем же периодом пересчёта. Мюллер в 2018 году предупреждал, что «чистого листа» при возврате на старый домен не будет. Ищите причину по окнам мониторинга (раздел 12).

3. →
   Если откатываете

   С резервной копией старого сайта и старыми настройками DNS с коротким TTL откат занимает часы, без них — дни. Порядок в Google и Яндексе — ниже.

Виды переезда: что важно в каждом случае

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

Смена домена

Самый рискованный вид: меняются все адреса, а поисковикам нужно перенести на новый домен ссылки, историю и поведенческие данные. Всё из разделов 4–13 относится к нему полностью.

Что перейдёт на новый домен, а что нет, официально описано лишь частично. Google обещает, что 301 не теряет PageRank. Яндекс обещает передать новому адресу «некоторые накопленные показатели» и называет среди них внешние ссылки и оригинальные тексты, но не позиции и не трафик. О переносе поведенческих данных и истории домена Яндекс не пишет ничего, и у практиков на этот счёт противоположные мнения. Поэтому не стройте прогноз на допущении, что «всё накопленное переедет».

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

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

Переход на HTTPS

Один из самых безопасных переездов, если выполнить три условия: постраничный 301 с HTTP на HTTPS, обновлённые внутренние ссылки и ресурсы, и никаких смешанных ресурсов (картинки, скрипты и стили по HTTP на HTTPS-странице).

Google не требует для HTTPS «Изменения адреса». Яндекс оформляет его через «Переезд сайта» с опцией «Добавить HTTPS» (раздел 10) и утверждает, что при соблюдении его инструкции трафик не теряется. По справке Яндекса обновить нужно:

• внутренние ссылки;
• ссылки в sitemap;
• ссылку на sitemap в robots.txt;
• альтернативные ссылки на языковые версии (hreflang).

Заголовок HSTS полезен для безопасности, но на ранжирование, по словам Мюллера (2023), не влияет.

www и без www

Для поисковиков это разные хосты. Выберите один и поставьте постраничный 301 со второго. Canonical на выбранный хост Google примет как дополнительный сигнал, но на время проверки заявки в Яндексе его с новых страниц снимают (раздел 10). В Google инструмент «Изменение адреса» здесь не нужен, в Яндексе переезд оформляется через «Переезд сайта». Отдельно проверьте, что редирект на выбранный хост срабатывает на всех страницах, а не только на главной, — и при открытии по HTTP, и по HTTPS.

Смена хостинга без изменения адресов

Для поисковиков это почти невидимая операция. Google советует заранее снизить TTL записей DNS (раздел 4), перенести на новый сервер файл подтверждения Search Console, снять временные блокировки с копии и держать старый сервер, пока на него идёт трафик.

После переключения скорость обхода может временно упасть — Google называет это нормальным. Риски здесь в основном технические: другая версия PHP, кодировка базы, потерянные скрытые файлы .htaccess при копировании по FTP, сертификат, который не успели выпустить.

Смена CMS или конструктора

Если домен остаётся, инструменты поисковиков не нужны, но риск остаётся средним или высоким: новая CMS меняет адреса, шаблоны, внутреннюю перелинковку и иногда — сам HTML, который видит робот. Лучшее, что можно сделать, — сохранить прежние URL. Если не получается, нужны карта 301 и проверка шаблонов по таблице 5.

Особенности 13 популярных платформ — в разделе 15.

Редизайн и смена структуры URL

Редизайн без смены адресов кажется безопасным, но меняет то, что поисковик оценивает на странице: объём и расположение текста, заголовки, блоки, внутренние ссылки, скорость. Самые частые потери при редизайне — вырезанный «лишний» текст, пропавшие FAQ и таблицы, ссылки из меню на важные разделы, которые убрали ради «чистоты» дизайна.

Сравните старые и новые шаблоны по таблице 5 и выкатывайте редизайн отдельно от смены адресов.

При смене структуры на том же домене Яндекс советует:

• ставить 301 со старого адреса на новый — робот проиндексирует цель и удалит старые страницы из поиска;
• если вместе со структурой меняется тематика, отдавать на прежних страницах 404.

Переобход в Вебмастере ускоряет процесс (раздел 10).

Слияние нескольких сайтов

Основа слияния — постраничные 301 со всех присоединяемых сайтов на релевантные страницы основного; совпадающий контент объединяют. «Изменение адреса» подают по каждому присоединяемому домену, но не одновременно: Google предупреждает, что перенос нескольких сайтов в одно место сразу «может вызвать путаницу и потерю трафика», и советует присоединять их по одному. Перед слиянием сравните, по каким запросам ранжируется каждый сайт: два сайта, которые занимали в топе две позиции, после слияния могут занять одну.

Поддомен ↔ подпапка

В Яндексе поддомен — отдельный сайт со своим ИКС и своей историей. Для Google поддомен — отдельный ресурс в Search Console. Перенос блога с blog.example.com в example.com/blog/ внутри одного домена делается постраничными 301 и новым sitemap. «Изменение адреса» здесь применимо, только если вы переносите весь поддомен целиком: Google позволяет перенести ресурс в папку основного домена, но не отдельные разделы.

Обещать рост позиций от такого переезда не стоит: исследований с контрольной группой, которые бы его показали, я не нашёл. Испанская выборка (в пересказе, см. раздел 3) называет перенос с поддомена в папку одним из самых безопасных видов миграции — но безопасный не значит выгодный.

Смена зоны или региона

Переезд с .ru на .com, .рф или национальный домен другой страны меняет не только адрес, но и геосигнал.

• Google. Для общих зон вроде .com задаётся целевая страна. Порядок полного переезда — 301 и «Изменение адреса».
• Яндекс. «Переезд сайта» и регион заново, заранее для нового адреса (раздел 10).
• Отказ заявки. Яндекс отклоняет заявку, если сайт переезжает в другую доменную зону без редиректа.

CMS и конструкторы: где ставить редиректы и на чём ошибаются

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

Подробнее по платформам

wp search-replace 'http://old.test' 'https://new.com' --skip-columns=guid --dry-run

RewriteEngine On

# правила переезда — выше блока Битрикса
RewriteRule ^old-section/(.*)$ /new-section/$1 [R=301,L]

# стандартный блок Битрикса
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$
RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]

/oldpage    →  /newpage
/blog/*     →  /articles/

Redirect from,Redirect to
/catalog/item-123.html,/products/makita-hp457
/catalog/drills/,/collections/dreli

// next.config.js
module.exports = {
  async redirects() {
    return [
      { source: '/catalog/:slug', destination: '/products/:slug', permanent: true }, // ответ 308
    ];
  },
};

Типы сайтов: что добавить к общему плану

Подробности по двум типам — в отдельных разборах: hreflang: ошибки и проверка для мультиязычных сайтов и краулинговый бюджет Google и Яндекса для больших.

Спорные вопросы: что говорят первоисточники

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

Как переезды проваливаются: разборы с цифрами

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

И случаи, где всё прошло хорошо. Агрегатор недвижимости вырос с 30 тысяч до 100 тысяч страниц: подготовка заняла два года, сам переезд — несколько часов, визиты за 3,5 месяца выросли со 132 до 188 тысяч в месяц. Магазин, переехавший с Joomla и Diafan на Битрикс, потерял трафик на неделю, а за год вырос на 53%. Общее у удачных переездов — долгая подготовка и постраничная карта редиректов.

В моих переездах трафик после запуска оставался на прежнем уровне или рос. Общее у них то же, что у удачных случаев выше: полный реестр страниц, который всегда под рукой для сверки с боевым сайтом и правки редиректов, и ТЗ на SEO-блоки, составленное по блочному макету старого сайта до разработки нового (раздел 4).

Чек-лист миграции сайта

Тот же порядок, что в статье, одним списком. У каждого пункта — как убедиться, что он выполнен. Отмечайте пункты на странице или скачайте чек-лист таблицей.

Источники

Страницы справок и исследований открыты 29 октября 2026 года. Где у страницы есть дата обновления или публикации, она указана. Данные исследований — оценки трафика сторонними инструментами, не данные владельцев сайтов; ограничения каждого описаны в разделе 2.

Google

• Site moves with URL changes (обновлено 20.08.2026)
• Справка Search Console: инструмент «Изменение адреса»
• Site moves without URL changes (обновлено 10.12.2025)
• Redirects and Google Search (обновлено 14.04.2026)
• Indexing API Quickstart (обновлено 16.10.2026)
• JavaScript SEO basics

Яндекс

• Переезд сайта на новое доменное имя
• Переезд сайта: общий сценарий и разгруппировка
• Переход сайта на HTTPS
• Главный и неглавные адреса сайта
• Региональность сайта
• Обработка редиректов
• Изменение структуры сайта
• Поддержка протокола IndexNow
• Блог Вебмастера: 301-й редирект полностью заменил директиву Host (март 2018)
• Яндекс Бизнес: изменение контактов

Bing и IndexNow

• Bing Webmaster: Site Move tool (архивная копия 2016)
• Bing Webmaster Blog: Website Migration with Bing (17.12.2020)
• Участники протокола IndexNow

Исследования и случай с возвратом домена

• SALT: 1 052 смены домена (26.06.2026)
• Search Engine Journal: 892 смены домена (январь 2025)
• PageSpeed Matters: 982 смены платформы (19.10.2026)
• TotalMedios: пересказ исследования MJ Cachón, 175 миграций (28.01.2026)
• Search Engine Journal: Google Says Why Site Migrations Can Exceed 4 Months (13.10.2026)
• Search Engine Roundtable о том же случае (13.10.2026)

Документация платформ

• WordPress: Moving WordPress
• WP-CLI: search-replace
• 1С-Битрикс: резервное копирование
• 1С-Битрикс: возможные ошибки при переносе
• Tilda: экспорт кода
• Tilda: переадресация
• Wix: импорт редиректов
• Shopify: URL redirects
• Shopify: миграция
• Webflow: редиректы
• OpenCart: SEO URL
• MODX: перенос сайта
• Joomla: редиректы
• Drupal: trusted host settings
• uCoz: редиректы
• Next.js: redirects

Разборы переездов

• Хабр: разбор смены домена (октябрь 2026)
• Хабр: переезд с Tilda на PHP (октябрь 2026)
• Хабр: Промо Эксперт, удачный и неудачный переезды
• Webit: миграция сайта розничной сети
• aweb.ua: восстановление после просадки
• ratingruneta.ru: смена CMS и домена
• VIPRO: антикейс переноса сайта
• vc.ru: SEO при редизайне и смене CMS
• vc.ru: смена структуры сайта
• vc.ru: перенос магазина на другую CMS
• Havit: переезд на Яндекс KIT