Переезд сайта при ребрендинге: как сменить домен и снизить риск потери SEO-трафика

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

1. Соберите старые URL и зафиксируйте исходные SEO-показатели;

2. Проверьте новый домен и тестовую версию сайта;

3. Составьте постраничную карту соответствия URL;

4. Настройте и протестируйте прямую серверную переадресацию с кодом 301;

5. Обновите canonical (предпочтительный адрес страницы для поиска), внутренние ссылки, Sitemap (файл со списком страниц сайта) и остальные сигналы;

6. Откройте новый сайт для поисковых роботов и включите редиректы;

7. Отправьте Sitemap и уведомления в Google Search Console (сервис Google для контроля поиска) и Яндекс Вебмастер (сервис Яндекса для контроля сайта);

8. Проверьте аналитику, индексацию, трафик, конверсии и серверную нагрузку.

Что происходит с SEO при смене домена

Доменная SEO-миграция — это перенос страниц со старого домена на новый с передачей поисковым системам сигналов о смене адресов. Для робота URL документов меняются, даже если дизайн, контент и структура сайта остались прежними. Поэтому копирования файлов и переключения DNS (система привязки домена к серверу) недостаточно.

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

Какие изменения лучше разделить на этапы

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

Google рекомендует проводить крупные изменения поэтапно: сначала перенести сайт на новый домен, затем менять оформление или платформу. Если разделить релизы невозможно, команда проводит дополнительные проверки в рамках QA (проверка качества перед выпуском) и отдельно сравнивает рендеринг (формирование страницы для показа), метатеги, контент, перелинковку (связывание страниц сайта ссылками), производительность и функциональность двух версий.

Какие данные и показатели зафиксировать до переезда

Исходный срез станет точкой сравнения после запуска. Для каждого показателя укажите дату, источник, период и сегмент. Если смешать органические сеансы (визиты из бесплатной поисковой выдачи) со всем трафиком или объединить данные разных поисковых систем, сравнение потеряет смысл.

Откуда собрать старые URL

Одного источника обычно мало. Краулер видит адреса, доступные по внутренним ссылкам, но может пропустить страницы-сироты (без внутренних ссылок). Sitemap иногда содержит устаревшие URL, а аналитика — посещаемые страницы, которые уже исчезли из навигации:

• Результаты полного краулинга (автоматического обхода страниц сайта) действующего сайта;

• Все файлы Sitemap;

• Посадочные страницы из веб-аналитики;

• URL из Google Search Console и Яндекс Вебмастера;

• Адреса с обратными ссылками (ссылками на сайт с других ресурсов);

• PDF, изображения и другие индексируемые файлы;

• URL из рекламных кабинетов, писем, QR-кодов и управляемых профилей бренда.

Во время аудита нужно провести краулинг действующего сайта, проверить тестовую версию по карте URL и повторно просканировать сайт после запуска. Такой порядок описан в руководстве Screaming Frog.

Какие метрики сохранить

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

В таблицу можно добавить шаблон страницы, брендовый и небрендовый спрос (поиск бренда и общих запросов), выручку или лиды, обратные ссылки и сезонность. По этим данным команда расставляет приоритеты QA: сначала проверяет адреса, от которых зависят заявки и продажи.

Кто отвечает за миграцию

Как проверить новый домен до его открытия для поисковых систем

Новый домен должен разрешаться через DNS, иметь действующий SSL/TLS-сертификат и стабильно отдавать страницы. На тестовой версии проверяют шаблоны, навигацию, формы, поиск, личные кабинеты, оплату, изображения и скачиваемые файлы. Для динамических сайтов дополнительно сравнивают серверный и клиентский рендеринг.

Как защитить тестовую версию от индексации

Для доступного роботу временного хоста можно использовать директиву noindex (запрет страницы для поисковой индексации) в meta robots (HTML-тег с указаниями поисковым роботам) или HTTP-заголовке X-Robots-Tag (HTTP-заголовок с указаниями поисковым роботам). При таком способе URL обязательно должен быть доступен роботу. Для закрытого стенда надежнее использовать авторизацию или IP-фильтр (ограничение доступа по сетевому адресу).

Все ограничения тестовой среды заносят в пусковой чек-лист. При запуске публичных страниц отключают авторизацию и IP-фильтры, а также удаляют noindex. Забытый X-Robots-Tag может закрыть от поиска целый тип документов.

Критерии готовности нового домена

• Сертификат действителен для всех используемых хостов;

• Главная и контрольные страницы открываются без ошибок;

• Формы, корзина, авторизация и скачивание файлов работают;

• Контент, title (заголовок страницы для поисковых систем), description (описание страницы для поисковой выдачи) и заголовки перенесены корректно;

• Изображения и PDF доступны на новых адресах;

• robots.txt (файл с правилами для поисковых роботов) подготовлен для публичного сайта;

• На индексируемых страницах нет noindex;

• Аналитические и рекламные теги прошли тестирование;

• Сервер выдерживает ожидаемую нагрузку от пользователей и роботов.

Как составить карту старых и новых URL

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

Какие поля включить в карту миграции

Адрес назначения выбирают по смыслу и задаче пользователя. Даже если слова в URL или title совпадают, это еще не значит, что страницы эквивалентны.

Куда направлять страницы без точного аналога

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

Как настроить и проверить постоянную переадресацию

Google документирует серверные ответы 301 и 308 как постоянные переадресации и использует их как сигнал для выбора конечного URL в качестве канонического. Для необратимого междоменного переезда настройте прямой постраничный редирект 301 на соответствующий новый URL.

Правила можно настроить на веб-сервере, CDN (сеть серверов для быстрой доставки контента), балансировщике (системе распределения запросов между серверами) или в приложении. Нет единого безопасного фрагмента конфигурации: синтаксис и порядок выполнения зависят от инфраструктуры. Готовую конфигурацию проверяют в рабочем окружении до переключения всего трафика.

Как проверить маршрут одного URL

https://old.example/services/brand-strategy → https://new.example/services/brand-strategy

• Старый адрес возвращает редирект 301;

• Location (адрес назначения в ответе сервера) содержит конечный новый URL;

• Новый URL возвращает 200 OK (успешный ответ сервера);

• Тег canonical на новой странице указывает на нее саму;

• Внутренняя ссылка сразу ведет на новый URL;

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

Какие ошибки искать при массовой проверке

Все старые URL проверяют краулером или собственным тестом. В отчете ищут циклы, лишние переходы, редиректы на нерелевантные страницы, массовые ответы 4xx и 5xx (группы клиентских и серверных ошибок), расхождения протоколов и хостов, потерянные параметры и страницы, закрытые от индексации.

Одновременно следят за временем ответа, CPU (процессор сервера), памятью, соединениями, очередями и серверными ошибками. Редиректы меняют объем запросов к старому и новому контурам (отдельным частям серверной инфраструктуры), поэтому мониторинг инфраструктуры входит в процедуру запуска.

Какие сигналы обновить на новом сайте

Canonical, внутренние ссылки и навигация

В canonical-тегах новых страниц указывают выбранный канонический URL на новом домене. Ссылки в меню, хлебных крошках (навигационной цепочке разделов сайта), пагинации (разбиении списка на страницы), карточках, текстах и шаблонных блоках обновляют напрямую. Переходы внутри сайта через старый домен создают лишнюю нагрузку и мешают аудиту.

Отдельно проверяют Open Graph (разметка превью ссылки в соцсетях), метатеги с абсолютными URL, alternate-ссылки (ссылки на альтернативные версии страницы), AMP-связи (связи с ускоренными мобильными страницами) при их наличии и адреса в структурированных данных.

Sitemap, robots.txt и noindex

В Sitemap включают новые канонические URL, которые возвращают 200 OK и разрешены для индексации. Старые адреса и редиректы туда не добавляют. После изменения URL Яндекс рекомендует добавить новые адреса в Sitemap или создать новый файл — это указано в справке об изменении структуры сайта.

После открытия сайта проверяют фактический robots.txt на новом домене и директивы robots в HTML и HTTP-заголовках. Контрольные страницы должны возвращать 200 OK, оставаться доступными роботам и не содержать noindex.

Hreflang, структурированные данные и файлы

В hreflang заменяют старый домен во всех взаимных ссылках и проверяют, как отвечает каждая языковая версия. В JSON-LD (формат структурированных данных на странице) и другой структурированной разметке обновляют идентификаторы, URL организации, логотипов, изображений, товаров и хлебных крошек.

PDF, изображения и другие файлы переносят так же, как HTML: обновляют ссылки на них и выбирают подходящее действие для старого URL. Если файл удален и замены нет, сервер возвращает статус отсутствия.

В какой последовательности запускать переезд

1. Подтвердить готовность нового сайта, карты URL, аналитики и плана отката;

2. Снять тестовую авторизацию, IP-ограничения и noindex с публичных страниц;

3. Проверить выборку новых URL на доступность для пользователей и роботов;

4. Включить постраничную переадресацию 301 со старого домена;

5. Проверить контрольные маршруты и массовую выборку URL;

6. Проверить canonical, robots.txt, внутренние ссылки и коды ответа;

7. Отправить новый Sitemap в панели веб-мастеров;

8. После технической проверки уведомить Google и Яндекс о смене домена;

9. Проверить сбор аналитики, события, цели, конверсии и интеграции;

10. Запустить регулярный мониторинг обоих доменов.

Когда остановить запуск или применить план отката

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

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

Как сообщить Google и Яндексу о новом домене

Инструмент Google «Изменение адреса»

Запрос отправляют после переноса и настройки переадресации. Такой порядок указан в справке Google Search Console. Для отправки подтвердите права на оба ресурса и пройдите проверки инструмента.

«Изменение адреса» не применяют при переходе с HTTP на HTTPS, смене варианта с www на вариант без www, перемещении отдельных страниц внутри сайта и смене инфраструктуры без изменения URL. В этих случаях используют отдельные процедуры.

Инструмент Яндекса «Переезд сайта»

Старый и новый адреса добавляют в Яндекс Вебмастер и подтверждают права. После проверки нового сайта и перенаправлений заявку отправляют через раздел «Переезд сайта». Последовательность приведена в официальной инструкции Яндекса.

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

Как проверить аналитику, конверсии и интеграции

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

• Тег аналитики загружается на всех типах страниц;

• Просмотры, формы, покупки и другие события передаются с нужными параметрами;

• Цели и конверсии отмечаются корректно;

• consent-механизм (управление согласием на сбор данных) сохраняет выбранные настройки;

• Рекламные пиксели получают события, а аудитории формируются на их основе;

• Коллтрекинг, CRM, платежные системы, чаты и вебхуки (автоматические уведомления между системами) работают с новым доменом;

• Реферальные исключения (источники переходов без создания нового сеанса) и списки разрешенных доменов соответствуют новой схеме.

Когда требуется междоменное отслеживание GA4

Настройка нужна, если путь пользователя проходит между разными корневыми доменами (основными доменами без поддоменов): например, основной сайт остается на одном домене, а корзина работает на другом. GA4 (четвертая версия Google Analytics) связывает такие действия с одним пользователем и сеансом; механизм описан в справке Google Analytics.

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

Что контролировать после запуска

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

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

Как диагностировать падение органического трафика

Шаг 1. Исключить ошибку аналитики

Сначала сравнивают просмотры, события и конверсии, затем проверяют загрузку тегов, consent, фильтры, часовой пояс и домен в настройках. После этого данные аналитики сопоставляют с кликами в панелях веб-мастеров и серверными логами.

Шаг 2. Проверить доступность сайта

Проверяют доступность главной, основных посадочных страниц и разных шаблонов, а также DNS, SSL/TLS, ответы 200 OK, robots.txt, noindex, скорость сервера и ошибки 5xx. Ресурсы, необходимые для рендеринга, проверяют отдельно.

Шаг 3. Проверить переадресацию и canonical

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

Шаг 4. Проверить сканирование и индексацию

Отчеты Google Search Console, Яндекс Вебмастера и серверные логи покажут, посещают ли роботы старые и новые адреса, какие статусы получают, принят ли Sitemap и почему нужные URL исключены.

Шаг 5. Сопоставить контент и поисковые задачи

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

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

До запуска

• Зафиксированы исходные показатели и ценные посадочные страницы;

• Собраны URL из краулинга, Sitemap, аналитики, панелей веб-мастеров и данных об обратных ссылках;

• Назначены ответственные, согласованы окно запуска и критерии остановки;

• Проверены новый домен, сертификат, контент, формы и файлы;

• Составлена карта URL с владельцами и приоритетами;

• Подготовлены редиректы 301, canonical, внутренние ссылки, hreflang и структурированные данные (машиночитаемая разметка содержимого страницы);

• Подготовлены robots.txt и Sitemap с новыми URL;

• Старый и новый домены подтверждены в Google Search Console и Яндекс Вебмастере;

• Проверены аналитика, события, consent и интеграции.

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

• Сняты тестовые ограничения;

• Новые страницы доступны роботам и возвращают 200 OK;

• Включена постраничная переадресация 301;

• Проверены контрольные и массовые маршруты;

• Исключены циклы, лишние переходы и системные 4xx/5xx;

• Проверены canonical, robots.txt, noindex и внутренние ссылки;

• Отправлен новый Sitemap;

• После технического QA отправлены уведомления Google и Яндексу;

• Подтвержден сбор событий и конверсий.

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

• Трафик, клики, показы и конверсии сравниваются с исходным срезом;

• Контролируются индексация, обход и замена старых URL новыми;

• Повторяется краулинг карты миграции;

• Отслеживаются серверные ошибки и нагрузка;

• Обновляются старые ссылки в управляемых профилях и рекламных системах;

• Старый домен остается под контролем, переадресация регулярно проверяется.

Заключение

Перенос можно начинать после проверки тестовой выборки URL. Каждый старый адрес, для которого есть подходящая новая страница, должен вести прямо на нее по 301-редиректу. Если замены нет, сервер должен возвращать нужный код ответа, например 404. Новые URL должны открываться без ошибок, а canonical и другие поисковые сигналы — содержать согласованные адреса. До переключения назначьте ответственного, который по результатам проверки разрешит или остановит запуск либо начнет откат.