Переезд сайта без потери SEO-трафика: пошаговый гайд и чек-лист

Краткое содержание: главные мысли

• Переезд сайта нужно вести как SEO-релиз, а не как обычное обновление дизайна или CMS. До запуска необходимы полный список старых URL, исходные метрики и карта соответствий старый URL → новый URL.

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

• После запуска должны быть согласованы все сигналы: редиректы, canonical, внутренние ссылки, sitemap.xml, hreflang, structured data, аналитика и инструменты вебмастеров.

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

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

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

Поэтому формулировка «без потери трафика» означает не магическое отсутствие любого колебания, а отсутствие технически вызванной просадки из-за забытых редиректов, noindex, ошибок canonical, потери контента, 404, 5xx или сломанной аналитики.

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

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

Google разделяет миграции с изменением видимых URL и переезды инфраструктуры без изменения URL. При смене хостинга нужно контролировать DNS, логи старого и нового серверов, доступность Googlebot и стабильность ответов, но инструмент Change of Address для такого сценария не используется.

Главный принцип безопасной миграции

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

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

На практике roiseo.ru мы используем пять базовых принципов:

• Одна старая страница получает одно обоснованное назначение.

• Редирект ведет непосредственно на конечный URL.

• Интент и основной контент не меняются без необходимости.

• Все технические сигналы указывают на одну каноническую версию.

• Любое изменение измеряется относительно зафиксированной точки до запуска.

Этап 1. Проведите SEO-аудит старого сайта

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

Соберите полный инвентарь URL

Используйте несколько источников одновременно:

• выгрузку из CMS или базы данных;

• полный crawl сайта;

• XML Sitemap и sitemap index;

• Google Search Console;

• Яндекс Вебмастер;

• страницы входа из Метрики и GA4;

• серверные access-логи;

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

• URL рекламных кампаний;

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

• URL с параметрами, фильтрами и пагинацией;

• старые адреса, которые уже перенаправляются;

• страницы, не связанные внутренними ссылками.

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

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

Создайте baseline, с которым будете сравнивать новую версию.

Для бизнес-контроля важно не ограничиваться общей посещаемостью. Отдельно сохраните данные по money pages: категориям, услугам, товарам и материалам, которые приводят заявки. Связать эти данные помогает SEO-аналитика: она показывает не только падение кликов, но и изменение форм, звонков, заказов и качества лидов.

Присвойте URL приоритет

Рекомендуемая классификация:

• P0 — критические: главная, основные услуги, категории с выручкой, страницы с большим трафиком и ссылками.

• P1 — высокие: вторичные категории, популярные статьи, товары-лидеры, региональные страницы.

• P2 — средние: страницы с потенциалом, но ограниченным текущим трафиком.

• P3 — низкие: служебные, устаревшие, дублирующие и не имеющие спроса URL.

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

Этап 2. Подготовьте карту URL и редиректов

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

Рекомендуемая структура redirect map

Правила сопоставления

1. Сохраняйте URL без изменения, когда это возможно

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

2. Используйте соответствие 1:1

Старая страница должна вести на новую страницу с тем же или максимально близким интентом:

/seo-audit-old/ → 301 → /seo-audit/

3. Не перенаправляйте все URL на главную

Массовая схема:

/old-page-1/ → / /old-page-2/ → / /old-page-3/ → /

не сохраняет релевантность документов. Google предупреждает, что переадресация множества старых URL на одну нерелевантную страницу может быть воспринята как soft 404.

4. Объединяйте страницы только при совпадении интента

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

/blog/301-redirect/ /blog/redirect-chain/ /blog/redirect-errors/ ↓ /blog/polnyy-gayd-po-redirektam/

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

5. Возвращайте 404 или 410 для удаленного контента

Если релевантной замены нет, корректный ответ 404 Not Found или 410 Gone лучше, чем редирект на главную или случайную категорию. Google рекомендует возвращать реальные 404/410 для контента, который удален и не переносится.

6. Исключите цепочки

Плохо:

URL A → 301 → URL B → 301 → URL C

Правильно:

URL A → 301 → URL C

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

7. Проверьте старые редиректы

До миграции сайт уже может содержать цепочку:

2019 URL → 2022 URL → текущий URL

После запуска ее необходимо сократить:

2019 URL → новый конечный URL 2022 URL → новый конечный URL текущий URL → новый конечный URL

301, 308 или 302

Для постоянного переноса используйте серверный 301 Moved Permanently или 308 Permanent Redirect. Для Google постоянный редирект является сильным сигналом выбора нового URL как канонического. Google также указывает, что 301 и другие постоянные редиректы сами по себе не вызывают потерю PageRank.

302 и 307 предназначены прежде всего для временных изменений. Яндекс допускает 301 или 302 при заявке на переезд, однако для окончательной смены адреса логичнее формировать однозначный постоянный сигнал через 301/308.

Пример для Nginx

Сохранение пути при смене домена:

server {
    listen 80;
    listen 443 ssl;
    server_name old.example.ru www.old.example.ru;

    return 301 https://new.example.ru$request_uri;
}

Точное перенаправление при изменении пути:

location = /old-service/ {
    return 301 https://new.example.ru/new-service/;
}

Пример для Apache

RewriteEngine On
RewriteRule ^old-service/?$ https://new.example.ru/new-service/ [R=301,L]

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

Этап 3. Подготовьте staging-среду

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

Что проверить на тестовом стенде

• каждый шаблон страницы возвращает 200 OK;

• контент доступен в серверном или корректно отрендеренном HTML;

• есть ровно один основной H1;

• перенесены Title и Meta Description;

• canonical указывает на планируемый production URL;

• отсутствуют случайные noindex;

• не потеряны хлебные крошки;

• сохранены автор, дата публикации и дата обновления;

• перенесены изображения и alt-тексты;

• работают формы и ecommerce-функции;

• сохранены Product, Article, BreadcrumbList и Organization schema;

• нет ссылок на staging-домен;

• hreflang содержит production URL;

• внутренние ссылки не ведут через редиректы;

• OG-теги используют итоговые URL и изображения;

• аналитика не загрязняет production-данные.

Если staging закрывался через noindex, X-Robots-Tag или Disallow: /, эти ограничения необходимо удалить до или в момент запуска. Google отдельно рекомендует после включения редиректов проверить canonical и убрать временные правила noindex, которыми закрывалась новая версия.

Этап 4. Согласуйте canonical, robots.txt и sitemap.xml

Прямой ответ. После миграции поисковик не должен получать противоречивые указания. Редирект, canonical, sitemap, внутренняя ссылка и hreflang должны вести на один и тот же конечный индексируемый URL.

Canonical

Каждая новая индексируемая страница должна иметь self-referencing canonical:

<link rel="canonical" href="https://new.example.ru/catalog/product/">

Ошибки после миграции:

• canonical остается на старом домене;

• все страницы канонизированы на главную;

• HTTP-страница указывает на HTTP вместо HTTPS;

• canonical содержит staging-домен;

• canonical ведет на URL с редиректом;

• canonical конфликтует с hreflang;

• параметрическая страница объявлена канонической ошибочно.

Canonical — это указание предпочтительной версии, но не безусловная команда. Google учитывает совокупность сигналов: HTTPS, редиректы, URL в sitemap и rel="canonical" и может выбрать другой канонический адрес, если сигналы противоречат друг другу.

Robots.txt

После запуска проверьте:

https://example.ru/robots.txt

Критические риски:

User-agent: *
Disallow: /

или блокировка каталогов с CSS, JavaScript, изображениями и серверным рендерингом.

Добавьте актуальную карту:

Sitemap: https://new.example.ru/sitemap.xml

robots.txt управляет обходом, но не является надежным способом удаления уже известных URL из индекса. Для исключения страницы используется noindex, а для постоянного переноса — редирект.

Sitemap.xml

В новую карту должны входить только URL, которые:

• возвращают 200 OK;

• разрешены для обхода;

• не имеют noindex;

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

• не перенаправляются;

• относятся к новому production-домену;

• должны участвовать в поиске.

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

Нужно ли сохранять старый sitemap

Для Google после запуска следует отправить новую карту с новыми URL. В актуальном руководстве Google указано, что после отправки новой карты старую можно убрать, поскольку далее будет использоваться новый sitemap. При этом старые URL все равно должны оставаться доступными для обхода через редиректы.

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

Этап 5. Сохраните контент и релевантность страниц

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

На первом релизе желательно сохранить:

• основной интент;

• H1;

• ключевые Title;

• текстовые блоки;

• характеристики товара или услуги;

• цены и условия;

• FAQ;

• отзывы;

• кейсы;

• изображения;

• таблицы и данные;

• авторство;

• даты;

• исходящие ссылки на первоисточники;

• structured data;

• навигацию и хлебные крошки.

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

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

Этап 6. Перенесите внутреннюю перелинковку

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

Проверьте:

• главное меню;

• footer;

• хлебные крошки;

• ссылки внутри статей;

• блоки «Похожие материалы»;

• карточки категорий;

• фильтры;

• пагинацию;

• HTML-карту сайта;

• ссылки в FAQ;

• изображения и кнопки;

• canonical и hreflang;

• ссылки внутри JSON-LD;

• ссылки из писем и шаблонов уведомлений.

После crawl новой версии в отчете не должно оставаться внутренних ссылок, ведущих на старый домен или на URL с 301.

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

Этап 7. Проверьте скорость, JavaScript и инфраструктуру

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

Core Web Vitals

Сравните старую и новую версии по шаблонам:

• главная;

• категория;

• карточка;

• услуга;

• статья;

• региональная страница;

• поиск или фильтр.

Текущие рекомендуемые пороги Core Web Vitals:

Оценка проводится по 75-му перцентилю загрузок отдельно для мобильных и настольных устройств.

Что часто ломается при смене CMS

• hero-изображение становится LCP-элементом без preload;

• JavaScript-бандл блокирует основной поток;

• SSR заменяется клиентским рендерингом;

• карточки и тексты отсутствуют в исходном HTML;

• изображения теряют width и height, увеличивая CLS;

• шрифты вызывают скачок макета;

• фильтры создают бесконечные комбинации URL;

• CMS добавляет дубли со слешем и без;

• middleware возвращает 302 вместо постоянного редиректа;

• CDN отдает роботу 403 или кэширует старый canonical.

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

При сложной смене платформы целесообразно подключать техническое SEO: проверять не только внешние коды ответа, но и шаблоны CMS, рендеринг, серверные логи, canonical, генерацию sitemap и побочные URL.

Этап 8. Перенесите Schema.org, авторство и E-E-A-T

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

Проверьте следующие типы:

• Organization;

• WebSite;

• Article или BlogPosting;

• BreadcrumbList;

• Product;

• Offer;

• LocalBusiness;

• Service;

• Person;

• FAQPage, если вопросы и ответы видимы на странице.

Для статьи важно перенести:

• headline;

• author;

• datePublished;

• dateModified;

• image;

• mainEntityOfPage;

• publisher;

• канонический URL автора;

• URL изображения;

• хлебные крошки.

Google рекомендует валидировать разметку до публикации, затем проверить несколько внедренных страниц через URL Inspection и продолжать контроль через отчеты Search Console. Корректная разметка помогает понять страницу, но сама по себе не гарантирует расширенного результата.

Почему это важно для GEO

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

После переезда проверьте:

• доступны ли основные материалы без сложного клиентского JavaScript;

• не ведет ли canonical на старый домен;

• сохранены ли автор и дата обновления;

• обновлены ли ссылки между услугой, статьями, исследованиями и страницей автора;

• изменены ли URL в JSON-LD;

• перенесены ли собственные исследования и первичные данные;

• работают ли ссылки из llms.txt, если файл используется;

• не блокирует ли CDN поисковых и AI-роботов;

• не исчезли ли прямые answer-first блоки, таблицы и FAQ.

В методике GEO-продвижения техническая доступность рассматривается как отдельный слой: HTTP-ответы, серверный HTML, robots.txt, sitemap, canonical, внутренние ссылки, schema, авторство и непротиворечивость источников.

Этап 9. Подготовьте аналитику до запуска

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

Проверьте:

• код Метрики и GA4;

• отправку page_view;

• формы и успешные отправки;

• клики по телефону;

• мессенджеры;

• ecommerce;

• CRM-источник;

• call tracking;

• referrer;

• UTM-разметку;

• hostname;

• исключения реферального трафика;

• cross-domain tracking, если домены работают параллельно;

• события дочитывания и переходов на услуги;

• логирование 404;

• серверные логи поисковых роботов.

Создайте аннотацию с точной датой и временем запуска. Сравнивайте одинаковые дни недели и учитывайте сезонность.

Основные KPI миграции

Этап 10. Проведите запуск по регламенту

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

Runbook дня запуска

• Зафиксировать контентный freeze.

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

• Сохранить предыдущие правила редиректов.

• Проверить возможность быстрого rollback.

• Убедиться, что SSL-сертификат нового домена работает.

• Переключить DNS или production-конфигурацию.

• Активировать карту 301/308.

• Удалить staging-ограничения.

• Проверить robots.txt.

• Проверить sitemap.xml.

• Проверить canonical на всех шаблонах.

• Проверить P0 URL вручную.

• Запустить автоматическую проверку redirect map.

• Проверить 404 и 5xx.

• Проверить формы, заказы и оплату.

• Проверить Метрику, GA4 и CRM.

• Выполнить crawl нового сайта.

• Проверить логи сервера.

• Отправить sitemap в инструменты вебмастеров.

• Запустить процедуру смены адреса, если она применима.

Автоматическая проверка карты

Для каждой строки должно выполняться:

Старый URL → один 301/308 → ожидаемый новый URL → 200 OK → indexable → self-canonical

Ошибка любого звена переводит URL в очередь исправлений.

Этап 11. Сообщите поисковым системам о переезде

Google Search Console

Прямой ответ. Change of Address используется при переносе домена или субдомена после настройки редиректов. Инструмент не нужен для HTTP → HTTPS, изменения путей внутри того же домена, переключения www или смены хостинга без изменения URL.

Перед отправкой заявки:

• подтвердите права на старый и новый домены;

• проверьте все важные варианты hostname;

• активируйте редиректы;

• сохраните verification-файлы и DNS-записи;

• убедитесь, что новый сайт доступен для Googlebot;

• отправьте новый sitemap.

Google рекомендует применять Change of Address после переноса и настройки редиректов. Инструмент помогает Google сфокусировать обход на новом сайте и переносить сигналы со старого адреса.

Яндекс Вебмастер

При смене домена:

• добавьте старый и новый сайты;

• подтвердите права;

• откройте оба сайта для робота;

• настройте перенаправления;

• подайте заявку через раздел переезда;

• контролируйте уведомления и индексирование.

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

Этап 12. Обновите внешние источники

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

Обновите:

• профили компании;

• карты и каталоги;

• соцсети;

• рекламные кабинеты;

• email-подписи;

• партнерские сайты;

• отраслевые публикации;

• маркетплейсы;

• агрегаторы;

• пресс-релизы;

• ссылки в приложениях;

• PDF-презентации;

• ссылки на автора;

• ссылки на исследования;

• важные доноры с внешними ссылками.

Google рекомендует после запуска обновить внутренние ссылки, внешние ссылки с приоритетных сайтов, социальные профили и рекламные кампании.

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

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

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

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

Мониторинг после запуска

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

Первые часы

Проверить:

• главную;

• robots.txt;

• sitemap;

• P0 URL;

• редиректы;

• canonical;

• формы;

• оплату;

• аналитику;

• 404;

• 5xx;

• SSL;

• доступность CSS и JavaScript;

• мобильный рендеринг.

Первые 3 дня

• анализировать серверные логи;

• искать массовые 404;

• проверять рост обхода новых URL;

• контролировать старые URL без редиректа;

• сравнивать органические входы;

• проверять лиды;

• исправлять P0 и P1;

• проверять URL Inspection для ключевых страниц.

Первые 2–4 недели

• сравнивать клики по группам страниц;

• анализировать запросы, которые сменили посадочный URL;

• проверять выбранный Google canonical;

• контролировать исключенные страницы;

• отслеживать старые URL в выдаче;

• проверять обновление страниц в Яндексе;

• сравнивать Core Web Vitals;

• обновлять внешние ссылки;

• устранять цепочки редиректов.

Следующие 2–3 месяца

• контролировать остаточный трафик старого домена;

• анализировать URL, которые поисковики не перенесли;

• искать каннибализацию новых страниц;

• проверять восстановление позиций;

• сравнивать лиды и выручку;

• оценивать crawl budget;

• обновлять redirect map;

• проводить повторный технический аудит.

Приоритеты ошибок после миграции

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

Сценарий 1. Трафик упал сразу на всем сайте

Вероятные причины:

• robots.txt закрывает сайт;

• глобальный noindex;

• DNS ведет не на тот сервер;

• SSL или HTTPS работают некорректно;

• сервер возвращает 5xx;

• аналитика не установлена;

• WAF блокирует роботов или пользователей.

Это авария уровня P0.

Сценарий 2. Просели отдельные разделы

Проверьте:

• есть ли эти URL в redirect map;

• совпадает ли интент назначения;

• перенесен ли контент;

• сохранились ли Title и H1;

• есть ли внутренние ссылки;

• попадают ли URL в sitemap;

• какой canonical выбрал Google;

• не создала ли CMS новые дубли.

Сценарий 3. Трафик есть, но пропали заявки

Причина может быть не в индексации:

• не работает форма;

• изменился CTA;

• скрыта цена;

• потеряны отзывы;

• не настроено событие успешной отправки;

• CRM не получает источник;

• мобильная версия стала медленнее;

• контентный блок перекрывает форму.

Сценарий 4. Новый домен не заменяет старый в выдаче

Проверьте:

• редиректы;

• self-canonical;

• sitemap;

• права в Search Console;

• Change of Address;

• заявку в Яндекс Вебмастере;

• доступность нового сайта;

• наличие старых внутренних ссылок;

• конфликты hreflang;

• соответствие контента.

Сценарий 5. Страницы распознаны как soft 404

Обычно это происходит, если:

• множество URL редиректит на главную;

• страница назначения не соответствует старому интенту;

• новый контент практически пуст;

• шаблон возвращает 200, хотя сообщает, что материал не найден.

Особые сценарии миграции

Смена домена без изменения структуры

Это наиболее простой сценарий, если каждый путь сохраняется:

old.ru/catalog/product/ → new.ru/catalog/product/

Можно использовать общее правило переноса hostname, но обязательно проверить параметры, поддомены, HTTP/HTTPS и www.

Смена CMS без изменения домена

Основные риски:

• CMS меняет slugs;

• добавляет или удаляет завершающий слеш;

• создает новые категории и архивы;

• удаляет ручные метатеги;

• формирует неправильный canonical;

• меняет статус редиректов;

• переносит не весь контент;

• не отдает HTML без JavaScript.

Если URL можно сохранить, сохраняйте их.

Смена хостинга без изменения URL

• уменьшите DNS TTL заранее;

• подготовьте новый сервер;

• протестируйте сайт через hosts;

• синхронизируйте файлы и базу;

• проверьте SSL;

• контролируйте логи обоих серверов;

• не отключайте старый хостинг, пока трафик не перешел;

• отслеживайте 5xx и TTFB.

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

Переезд мультиязычного сайта

Обновите каждый набор hreflang:

<link rel="alternate" hreflang="ru" href="https://new.example.com/ru/page/">
<link rel="alternate" hreflang="en" href="https://new.example.com/en/page/">
<link rel="alternate" hreflang="x-default" href="https://new.example.com/page/">

Каждая языковая страница должна:

• ссылаться на себя;

• ссылаться на остальные версии;

• получать обратные hreflang-ссылки;

• быть канонической;

• возвращать 200;

• не вести через редирект.

Объединение нескольких сайтов

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

• какие интенты совпадают;

• какая страница сильнее;

• где контент нужно объединить;

• какие URL удалить;

• какие внешние ссылки обновить;

• какие бренды и сущности должны сохраниться.

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

Чек-лист переезда сайта

До запуска

• Проведен полный crawl старого сайта.

• Выгружены URL из CMS.

• Выгружены страницы входа из аналитики.

• Собраны URL из Search Console и Вебмастера.

• Собраны страницы с внешними ссылками.

• Зафиксированы позиции и поисковые запросы.

• Зафиксированы лиды и продажи.

• URL разделены на P0–P3.

• Подготовлена redirect map.

• Проверено соответствие интентов.

• Сохранены метатеги и контент.

• Перенесена schema.

• Перенесены авторы и даты.

• Проверены формы.

• Проверены Core Web Vitals.

• Подготовлен rollback.

• Подтверждены права в инструментах вебмастеров.

• Новый сервер выдерживает дополнительный обход.

В момент запуска

• Работает HTTPS.

• Активированы постоянные редиректы.

• Снят noindex.

• Снят Disallow: /.

• Canonical указывает на новый URL.

• Hreflang указывает на новые URL.

• Sitemap содержит новые canonical URL.

• Внутренние ссылки обновлены.

• Нет ссылок на staging.

• P0 URL возвращают 200.

• Старые P0 URL возвращают 301.

• Нет redirect loops.

• Нет массовых 404/5xx.

• Работают формы и ecommerce.

• Аналитика получает события.

• Логи доступны для мониторинга.

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

• Новый sitemap отправлен в Google и Яндекс.

• Подана заявка на смену адреса, если применимо.

• Проверены URL через URL Inspection.

• Ежедневно анализируются 404 и 5xx.

• Проверяется выбранный canonical.

• Сравниваются клики по группам страниц.

• Контролируются лиды и продажи.

• Анализируются логи роботов.

• Обновляются важные внешние ссылки.

• Редиректы сохраняются минимум год.

• Проведен повторный crawl.

• Проведен повторный SEO-аудит.

Когда перенос лучше отложить

Не запускайте миграцию, если:

• карта URL не завершена;

• нет резервной копии;

• неизвестно, какие страницы приносят трафик и заявки;

• staging не прошел crawl;

• разработчик не может гарантировать постоянные редиректы;

• canonical генерируется неправильно;

• новый сайт закрыт от роботов;

• формы не протестированы;

• нет доступа к DNS и серверу;

• нет ответственного за мониторинг после запуска;

• невозможно быстро откатить критическую ошибку;

• запуск запланирован на пик сезонного спроса.

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

Можно ли полностью избежать падения трафика?

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

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

Для постоянного переноса используйте серверный 301 или 308. Он должен вести непосредственно на релевантный конечный URL.

Можно ли заменить редирект canonical?

Нет. Canonical является сигналом выбора предпочтительного URL, а не механизмом перенаправления пользователя. При постоянном изменении адреса используйте редирект, а на новой странице — self-referencing canonical.

Как долго ждать восстановления позиций?

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

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

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

Нужно ли использовать Change of Address при переходе на HTTPS?

Нет. Инструмент не применяется для HTTP → HTTPS, изменения путей внутри сайта, переключения www и переезда хостинга без изменения адресов.

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

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

Что делать с удаленными страницами?

Если есть релевантная замена, настройте 301. Если замены нет, верните настоящий 404 или 410. Не перенаправляйте удаленные страницы на главную без смыслового соответствия.

Нужно ли обновлять llms.txt?

Да, если сайт использует этот файл. Все приоритетные ссылки должны вести на новые канонические URL. Однако llms.txt не заменяет HTML, sitemap, редиректы, авторство и доступность страниц.

Вывод

Переезд сайта без критической потери SEO-трафика начинается не в день переключения домена. Основная работа выполняется заранее: аудит старой версии, сбор URL, фиксация метрик, карта редиректов, проверка шаблонов, сохранение контента, настройка аналитики и тестирование staging.

После запуска важна согласованность:

Старый URL → постоянный редирект → релевантный новый URL → 200 OK → indexable → self-canonical → внутренняя ссылка → sitemap → рабочая аналитика

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

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

Источники

• Google Search Central: перенос сайта с изменением URL
• Google Search Console: инструмент Change of Address
• Яндекс Вебмастер: переезд сайта на новое доменное имя
• Яндекс Вебмастер: смена структуры и дизайна сайта
• web.dev: актуальные пороги Core Web Vitals

Материалы по теме

Что изучить дальше