Как перенести домен, не обрушив поисковые позиции

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

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

Начните с инвентаризации, а не с правила редиректа

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

Прежде чем трогать DNS, составьте список важных URL:

• URL, которые получают органический трафик
• URL с внешними обратными ссылками
• URL, которые конвертируют, генерируют лиды или поддерживают кампании
• Canonical URL, которые сейчас находятся в вашем XML sitemap
• PDFs, изображения и скачиваемые файлы, на которые есть внешние ссылки
• Ценные устаревшие URL, которые могут не отображаться в текущей навигации

Для каждого старого URL назначьте место назначения на новом домене. В большинстве случаев это должна быть та же страница с тем же намерением. Если /pricing становится https://newdomain.com/pricing, все просто. Если три старые страницы продуктов объединяются в один новый гайд, зафиксируйте это решение осознанно.

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

Сохраняйте структуру URL там, где это возможно

Миграция домена проще, когда пути остаются стабильными. Переход с oldsite.com/blog/example на newsite.com/blog/example намного чище, чем одновременная смена домена, CMS, slugs, структуры папок и контента.

Иногда редизайн или миграция CMS делают изменения URL неизбежными. В таком случае разделите решения:

1. Что меняется из-за смены домена?
2. Что меняется из-за изменения структуры сайта?
3. Что удаляется, объединяется или переписывается?

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

Используйте постоянные редиректы в один переход

Для настоящей миграции домена используйте серверные 301 или 308 редиректы со старых URL на их новые эквиваленты. Временные редиректы нужны для временных ситуаций. JavaScript-редиректы, meta refresh и мягкие редиректы — более слабые сигналы, которые легче сломать.

Цели редиректов просты:

• Каждый важный старый URL возвращает постоянный редирект.
• Каждый редирект ведет напрямую к конечному месту назначения.
• HTTP корректно перенаправляется на HTTPS.
• Варианты www и без www обрабатываются последовательно.
• Редиректы не зависят от хрупкого поведения query-string, если это не необходимо.

Плохая цепочка выглядит так:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

В итоге она может привести на правильную страницу, но это медленно, сложнее для обхода и с большей вероятностью скрывает ошибки. Стремитесь к одному переходу от каждого старого варианта к финальному новому URL.

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

Подготовьте DNS и сертификаты до запуска

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

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

Если переезд затрагивает email, не относитесь к этому как к второстепенной задаче. Смена домена часто ломает SPF, DKIM, DMARC, MX records, tracking links и transactional mail. Чтобы освежить в памяти важные записи, посмотрите наш ориентированный на разработчиков гайд по MX, SPF, DKIM и DMARC.

Проверьте canonicals, внутренние ссылки и sitemaps

После запуска новый домен должен вести себя так, будто он всегда был canonical-домом для контента.

Это означает:

• Canonical tags указывают на новые URL, а не на старый домен.
• Внутренние ссылки используют новый домен или root-relative paths.
• XML sitemaps содержат только финальные, индексируемые новые URL.
• Аннотации hreflang, если используются, ссылаются на новые URL.
• Open Graph, structured data и alternate links обновлены.
• Robots.txt не блокирует важные разделы.

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

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

Не меняйте все в день запуска

Миграция сама по себе уже достаточно крупное событие. По возможности не объединяйте ее с масштабной чисткой контента, переписыванием шаблонов, изменениями навигации, изменениями JavaScript rendering или новым профилем производительности.

Это не суеверие. Это дисциплина отладки. Если позиции упадут после запуска, вам нужно понимать, причина в сопоставлении редиректов, доступе для обхода, измененном контенте, более медленном рендеринге, отсутствующих structured data или чем-то еще.

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

Сообщите поисковым системам, что изменилось

В Google Search Console подтвердите и старый, и новый домены. Затем используйте инструмент Change of Address, когда переезд является изменением на уровне домена и контент переносится на новый домен. После запуска отправьте новый sitemap.

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

Для Bing и других поисковых систем используйте их webmaster tools, где они доступны. Также обновите места, которые вы контролируете: социальные профили, бизнес-каталоги, ad destinations, email footers, документацию, партнерские ссылки и canonical references в syndicated content.

Не все внешние ссылки будут обновлены, и это нормально. Но самые важные стоит обновить. Если крупный партнер, app marketplace, портал документации или страница для прессы ссылается на старый домен, попросите обновить ссылку.

После запуска отслеживайте правильные вещи

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

Проверяйте:

• Server logs на предмет активности краулеров на старом и новом доменах
• 404 и неожиданные 5xx errors
• Цепочки и циклы редиректов
• Статус индексирования в Search Console
• Обнаружение и обработку sitemap
• Органические посадочные страницы и паттерны запросов
• Пути конверсии, которые зависят от старых URL
• Analytics filters и referral exclusions

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

Поисковая видимость может колебаться несколько недель. Чего вы не хотите — так это паттерна, при котором ценные старые URL многократно обходятся, но не редиректятся корректно, или новые страницы обнаруживаются, но помечаются как дубликаты старого домена.

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

Сохраняйте старый домен надолго

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

Старые ссылки продолжают существовать в blog posts, bookmarks, документации, PDFs, emails и social posts. Редиректы — это мост между этим историческим следом и новым доменом. Если отключить их слишком рано, вы сломаете пути пользователей и потратите накопленные сигналы.

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

<!-- tool-cta:start -->

💡 Попробуйте это: После переключения проследите свои старые URL-адреса через Redirect Checker, чтобы убедиться, что каждый из них разрешается за один 301-переход на правильную новую страницу.

<!-- tool-cta:end -->

Разумный чек-лист миграции

До запуска:

• Подтвердите оба домена в Search Console.
• Обойдите текущий сайт и экспортируйте важные URL.
• Создайте карту редиректов один к одному.
• Снизьте DNS TTLs.
• Подготовьте TLS-сертификаты для старого и нового доменов.
• Обновите canonicals, внутренние ссылки, hreflang, structured data и sitemaps.
• Протестируйте редиректы в staging или контролируемой среде.

В день запуска:

• Разверните редиректы.
• Подтвердите поведение HTTP to HTTPS.
• Протестируйте важные примеры URL для каждого типа шаблона.
• Отправьте новый sitemap.
• Используйте инструмент Change of Address там, где это уместно.
• Следите за server errors, redirect loops и заблокированными ресурсами.

После запуска:

• Отслеживайте crawl errors и отчеты об индексировании.
• Обновляйте важные внешние ссылки там, где можете.
• Сравнивайте трафик по намерению посадочной страницы, а не только по суммарным данным доменов.
• Держите редиректы активными бессрочно.
• Отложите несвязанный редизайн или эксперименты с контентом, пока переезд не стабилизируется.

Миграции доменов не бывают безрисковыми, но ими можно управлять. Позиции обычно страдают, когда миграция отправляет неясные сигналы: отсутствующие редиректы, измененный контент, противоречивые canonicals, заблокированные краулеры или забытый старый домен. Дайте поисковым системам и пользователям чистую карту, и переезд станет гораздо менее драматичным.