Смена домена — это миграция сайта с одного доменного имени на другое, при которой меняются адреса всех или большинства документов. Для поисковой системы это не косметическое переименование: https://old.example/page/ и https://new.example/page/ — разные URL, поэтому новый адрес нужно обнаружить, обойти, обработать и связать со старым.
Google рекомендует при такой миграции заранее подготовить соответствие старых и новых URL, настроить постоянные серверные редиректы и контролировать оба сайта после запуска. Google также предупреждает о возможных временных колебаниях видимости, пока страницы переобходятся и новый адрес заменяет старый в индексе.
Яндекс рассматривает изменение доменного имени как переезд сайта и требует, чтобы старый и новый адреса были доступны роботу, соответствующие страницы совпадали по содержанию, а со старых URL работало перенаправление на новые. При этом Яндекс прямо не гарантирует сохранение прежнего количества страниц в поиске, позиций или посещаемости после смены главного адреса.
До смены домена нужно зафиксировать не сайт, а его URL-карту
Самая опасная ошибка — сначала переключить домен, а потом выяснять, куда должны вести старые страницы.
Перед миграцией собирают список текущих URL минимум из нескольких источников:
- Sitemap;
- результатов технического краула;
- страниц с органическим трафиком;
- серверных логов;
- Search Console и Яндекс Вебмастера;
- URL, на которые ведут внешние ссылки.
После этого каждой старой странице назначается новый адрес.
Простейший вариант:
https://old.example/catalog/item-1/
→
https://new.example/catalog/item-1/
Если структура одновременно меняется:
https://old.example/products/item-1.html
→
https://new.example/catalog/item-1/
Google отдельно рекомендует создавать такую карту соответствий до запуска миграции и учитывать не только HTML-страницы, но и изображения, видео, JavaScript, CSS и другие ресурсы, адреса которых меняются.
Если новый домен ранее кому-то принадлежал, до запуска стоит проверить его история домена. Google в инструкции по миграции рекомендует для недавно приобретённого домена проверить ручные санкции и оставшиеся запросы на удаление URL от предыдущего владельца.

Постоянные редиректы должны вести сразу на конечный URL
Для постоянной смены домена Google рекомендует серверные постоянные редиректы, в первую очередь HTTP 301 или 308. Такие перенаправления являются сильным сигналом, что целевой URL должен рассматриваться как канонический.
Например:
https://old.example/catalog/item/
301
https://new.example/catalog/item/
Нежелательный вариант:
http://old.example/catalog/item/
→ https://old.example/catalog/item/
→ https://www.new.example/catalog/item/
→ https://new.example/catalog/item/
Лучше сразу вести исходный адрес на конечный вариант. Google советует избегать цепочек и по возможности делать прямое перенаправление.
Проверить маршрут можно через:
curl -I https://old.example/catalog/item/
или:
curl -IL https://old.example/catalog/item/
Во втором случае будет видна вся цепочка.
Google рекомендует сохранять миграционные редиректы как можно дольше и в общем случае не менее одного года, чтобы система успела переобойти URL и переназначить связанные сигналы. С пользовательской точки зрения старые редиректы часто разумно сохранять ещё дольше.
Яндекс для переезда на новое доменное имя в своей актуальной инструкции допускает 301 или 302, однако для заведомо постоянной смены домена семантически понятнее использовать постоянный 301: именно он сообщает клиентам и поисковым системам, что старый адрес заменён окончательно.
Что изменить на новом сайте кроме редиректов
Одних перенаправлений недостаточно. На новом домене сам сайт тоже должен перестать ссылаться на старый.
После подготовки необходимо проверить:
- внутренние ссылки;
- self-referencing canonical;
- Sitemap;
hreflang, если он используется;- structured data, если внутри неё присутствуют абсолютные URL;
- ссылки на изображения и другие собственные ресурсы;
robots.txt;- настройки аналитики и систем мониторинга.
Google рекомендует, чтобы каждая новая страница имела canonical на новый URL, внутренние ссылки были обновлены, а Sitemap содержал новые адреса.
В этом смысле домен seo — это не только вопрос названия домена. При миграции поисковой системе нужно получить непротиворечивый набор сигналов: редирект, canonical, Sitemap и внутренняя перелинковка должны указывать на одну и ту же новую версию.

Как сообщить о смене домена Google и Яндексу
В Google Search Console сначала нужно подтвердить права на старый и новый ресурсы. Для перехода с одного домена или субдомена на другой применяется Change of Address.
Google в актуальной документации уточняет: при доменной миграции запрос Change of Address нужно отправить для всех подтверждённых вариантов старого домена, включая используемые субдомены и варианты с www и без www, если они существуют.
Сам инструмент доступен в настройках свойства Search Console.
После запуска нужно отправить новый Sitemap.
В Яндекс Вебмастере общий сценарий такой:
- добавить старый и новый сайты;
- подтвердить права;
- проверить доступность обоих адресов;
- настроить перенаправления;
- на старом сайте открыть
Индексирование → Переезд сайта; - выбрать новый адрес и отправить заявку.
Яндекс сообщает, что смена главного адреса обычно занимает несколько недель, но в отдельных случаях обработка может продолжаться дольше — в зависимости от типа переезда, скорости обхода и обновления поисковых данных.
Сам переезд сайта при этом не заканчивается нажатием кнопки в Вебмастере или Search Console. Инструменты только дополняют техническую миграцию, а не заменяют работающие URL-сопоставления и редиректы.
Смена протокола сайта — похожая, но не идентичная задача
Переход:
http://example.com/
→
https://example.com/
тоже меняет URL каждой страницы, поэтому с точки зрения миграции нужны HTTPS-версии страниц, внутренние ссылки на HTTPS, корректные canonical и перенаправления HTTP → HTTPS.
Google прямо относит переход HTTP→HTTPS к миграциям с изменением URL. Но Change of Address для такого перехода не требуется — этот инструмент используется для смены домена или субдомена, а не протокола.
Яндекс, напротив, предлагает для смены протокола собственный сценарий через инструмент «Переезд сайта»: обе версии добавляются в Вебмастер, затем для старой HTTP-версии выбирается переход на HTTPS.
Поэтому смена протокола сайта технически похожа на смену домена, но действия в интерфейсах поисковых систем отличаются.
Как проверить миграцию после запуска
Сразу после переключения нужно проверять не позиции, а техническую целостность.
Для выборки старых URL:
curl -IL https://old.example/page/
Ожидаемый результат:
old URL
→ 301
→ new URL
→ 200
Затем краулером проверяются:
- старые URL без редиректа;
- цепочки и циклы;
- новые
404и5xx; - canonical на старый домен;
- старые внутренние ссылки;
- URL старого домена в новом Sitemap;
- страницы с
noindex; - случайно закрытые разделы в
robots.txt.
В Google Search Console отслеживают индексирование, Sitemap, запросы и URL Inspection. Google описывает нормальную динамику как снижение количества индексируемых старых URL и рост количества новых. Также рекомендуется следить за access- и error-логами сервера.
В Яндекс Вебмастере результат можно отслеживать через Индексирование → Страницы в поиске: старые адреса должны постепенно исчезать, а новые — появляться.

Ошибки, из-за которых смена домена превращается в повторный запуск сайта
Первая ошибка — редиректить всё на главную:
/old-product-1/ → /
/old-product-2/ → /
/old-article/ → /
Google предупреждает, что массовые нерелевантные перенаправления на одну страницу могут восприниматься как soft 404. Яндекс также рекомендует вести старые внутренние страницы на аналогичные новые, а не отправлять весь сайт на главную.
Вторая ошибка — одновременно менять домен, CMS, дизайн, структуру URL и содержимое. Google рекомендует по возможности менять крупные компоненты последовательно, чтобы снизить число неизвестных при диагностике.
Третья — оставить на новом сайте:
<link rel="canonical" href="https://old.example/page/">
Редирект будет говорить «новая страница здесь», а canonical — «основная версия осталась там».
Четвёртая — забыть снять staging-ограничения:
User-agent: *
Disallow: /
или:
<meta name="robots" content="noindex">
Google отдельно включает забытые noindex и блокировки robots.txt в типовые ошибки миграций.
Пятая — выключить старый домен сразу после запуска. Старый адрес ещё нужен для редиректов, переходов пользователей и повторного обхода поисковыми роботами.
Практический сценарий: oldsite.ru переезжает на newsite.ru
Исходные данные:
- около 8 000 индексируемых URL;
- структура каталогов не меняется;
- часть статей имеет внешние ссылки;
- новый домен уже подключён к тому же приложению;
- старый домен будет полностью заменён.
До запуска делается полный краул и выгружается карта URL:
https://oldsite.ru/
→ https://newsite.ru/
https://oldsite.ru/catalog/
→ https://newsite.ru/catalog/
https://oldsite.ru/articles/example/
→ https://newsite.ru/articles/example/
На новом домене проверяются 200, canonical, robots.txt, Sitemap, внутренние ссылки и отсутствие noindex.
Затем включаются прямые постоянные редиректы со старых URL.
Контрольная выборка проверяется:
curl -IL https://oldsite.ru/articles/example/
После технического запуска новый Sitemap отправляется в поисковые системы, в Google Search Console используется Change of Address, а в Яндекс Вебмастере — «Переезд сайта».
Следующие недели контролируются:
- доля старых и новых URL в индексах;
404,5xxи soft 404;- серверные логи;
- органические клики и показы;
- страницы с внешними ссылками;
- скорость замены старых адресов новыми.
Если отдельная страница потеряла видимость, сначала проверяется её собственная цепочка: старый URL → редирект → новый URL → 200 → canonical → индексирование. Общий вывод о провале всей миграции по нескольким страницам делать рано.
Именно поэтому перенос сайта на новый домен — это прежде всего управляемая миграция URL и поисковых сигналов, а не регистрация нового имени в панели хостинга.

Если домен меняет проект с уже накопленным органическим трафиком, при SEO-продвижении сайта после смены домена важно контролировать не только момент переключения, но и последующую передачу сигналов: корректность редиректов, замену URL в индексе, динамику кликов и показов, страницы с внешними ссылками и ошибки обхода. Такой контроль позволяет отличить нормальный период переобхода от конкретной технической проблемы, которую нужно исправлять на уровне отдельных URL.
FAQ
Как понять, что поисковики приняли новый домен и миграция не сломалась
Нет правила, по которому позиции обязательно должны снизиться, но временные колебания возможны. Google прямо предупреждает о них на период переобхода и переиндексации, а Яндекс не гарантирует сохранение прежних позиций, количества страниц и посещаемости при смене главного адреса.
Да, если он используется как источник постоянных редиректов. Google рекомендует сохранять миграционные редиректы минимум около года и по возможности дольше, особенно если на старые адреса продолжают вести внешние ссылки.
Нет. Google указывает, что Change of Address применяется при смене домена или субдомена. Для HTTP→HTTPS он не требуется. В Яндекс Вебмастере для смены протокола используется собственный сценарий инструмента «Переезд сайта».
Технически можно, но диагностировать результат станет сложнее. Google рекомендует по возможности менять крупные элементы последовательно: например, сначала домен, а затем CMS или дизайн.
Не по календарной дате, а по совокупности признаков: старые URL стабильно перенаправляются, новые отвечают 200, canonical и Sitemap используют новый домен, старые страницы уходят из поиска, новые занимают их место, а в логах нет системных ошибок обхода. Для разных сайтов этот процесс занимает разное время.
Рейтинг статьи
Материал был полезен?
Оценка помогает понимать, какие материалы стоит обновлять и расширять.








