SEO-миграция сайта без потерь трафика

SEO-миграция — это перенос сайта, раздела или отдельных страниц с изменением URL, которые видят пользователи. Ошибки в перенаправлениях (редиректах), каноническом адресе (canonical), robots.txt и карте URL могут привести к выпадению страниц из поиска. Задача миграции — для каждого переносимого старого URL задать согласованный путь к новому адресу либо осознанно вернуть 404/410, если замены нет.

Материал проверен по официальной документации 4 сентября 2026 года. Он основан на источниках и не заявляет о результатах практического тестирования конкретного сайта.

Для кого: владельцы сайтов, разработчики и SEO-специалисты. Понадобится базовое понимание HTTP-кодов, индексации и серверных настроек.

Оглавление

1. Целевая архитектура миграции
2. Чеклист быстрой проверки
3. Инвентаризация старых URL
4. Карта перенаправлений
5. Подготовка нового сайта
6. Запуск в Google и Яндексе
7. Мониторинг после запуска
8. Эталонный шаблон миграции
9. Источники

Целевая архитектура миграции

После запуска система должна выглядеть так:

flowchart LR
    A[Старый URL] -->|301 или 308| B[Конечный новый URL]
    B --> C[200 OK]
    B --> D[Canonical на себя]
    E[Внутренние ссылки] --> B
    F[Новый sitemap.xml] --> B
    G[Google Search Console и Яндекс.Вебмастер] --> B

Для каждого переносимого URL нужен один из результатов:

• актуальная страница переехала на эквивалентный новый URL через постоянный серверный редирект;
• несколько старых страниц объединены в одну действительно соответствующую им страницу;
• удалённый без замены материал возвращает 404 Not Found или 410 Gone;
• новый конечный URL отвечает 200 OK, доступен для обхода и не закрыт временными правилами robots.txt или noindex, а канонический адрес (canonical) указывает на него же.

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

Чеклист быстрой проверки

Этот список можно пройти перед запуском за несколько минут:

Когда нужен миграционный план

План с картой URL нужен при смене домена, протокола, субдомена или путей страниц. Смена системы управления контентом (CMS) сама по себе не является переездом с изменением URL, но часто сопровождается изменением структуры адресов и поэтому требует тех же проверок.

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

Инвентаризация старых URL

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

Соберите адреса из следующих источников:

1. CMS или базы контента.
2. Текущих sitemap-файлов.
3. Веб-аналитики и страниц входа с учётом сезонности.
4. Серверных журналов.
5. Google Search Console и Яндекс.Вебмастера.
6. Отчётов о внутренних и внешних ссылках.
7. Краулинга сайта.

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

Для сравнения после запуска сохраните:

• клики, показы и позиции по поисковым запросам;
• органические входы по страницам;
• известные индексируемые URL;
• внешние ссылки на важные страницы;
• ответы сервера и canonical;
• показатели производительности, включая Core Web Vitals.

Карта перенаправлений

Карта связывает каждый старый URL с конечным новым адресом и ожидаемым HTTP-ответом.

Постоянные и временные редиректы

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

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

Цепочки и нерелевантные назначения

Направляйте старый URL сразу на конечную страницу. Googlebot способен проходить цепочки, однако они добавляют задержку и повышают риск ошибок. Утверждение, что каждый дополнительный переход обязательно «съедает вес», некорректно: Google прямо указывает, что постоянные редиректы не вызывают потери PageRank.

Не перенаправляйте множество несвязанных страниц на главную. Google может считать такие ответы мягкими ошибками 404 (soft 404). Объединение нескольких URL допустимо, если новая страница действительно заменяет их содержание.

Примеры серверной настройки

# Nginx: точное правило ведёт сразу на конечный URL
location = /catalog/shoes/nike-air {
    return 301 https://new.example/products/nike-air-max;
}

# Apache mod_alias
Redirect permanent "/catalog/shoes/nike-air" "https://new.example/products/nike-air-max"

После переноса между Apache, Nginx, Caddy, сетью доставки (CDN) или фреймворком правила нужно реализовать в реально обслуживающем запросы слое. Nginx не читает .htaccess. Заголовок Server может дать подсказку, но за CDN или обратным прокси он не доказывает, где применяются правила.

Проверяйте наблюдаемое поведение каждого важного маршрута:

curl -sI https://old.example/old-page

Ожидаемый результат:

HTTP/2 301
location: https://new.example/new-page

Затем отдельно проверьте конечный URL:

curl -sI https://new.example/new-page

Он должен отвечать 200, если страница доступна, и не перенаправлять запрос дальше без необходимости.

JavaScript-редиректы

JavaScript-перенаправление нельзя считать способом, который Google полностью игнорирует: Googlebot может обнаружить и выполнить window.location после обхода URL. Проблема в надёжности: редирект обнаруживается после рендеринга, а рендеринг может не состояться.

Используйте JavaScript только когда серверный редирект и мгновенный meta refresh недоступны. Для обычной миграции предпочтителен серверный 301 или 308.

Подготовка нового сайта

Канонический адрес, языковые версии и внутренние ссылки

Каждая новая индексируемая страница должна иметь канонический адрес (canonical), указывающий на себя:

<link rel="canonical" href="https://new.example/products/nike-air-max">

Обновите связи языковых версий (hreflang), навигацию, хлебные крошки и все контекстные ссылки. Они должны вести непосредственно на новые URL, без прохождения через редиректы.

Sitemap

Новый sitemap должен содержать абсолютные канонические URL нового сайта. Для <lastmod> указывайте дату реального изменения страницы, а не дату генерации файла.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://new.example/products/nike-air-max</loc>
    <lastmod>2026-09-04</lastmod>
  </url>
</urlset>

Один sitemap может содержать не более 50 000 URL и иметь размер не более 50 МБ в несжатом виде. Для больших сайтов используйте несколько файлов и sitemap index. changefreq и priority необязательны; значение priority не повышает позицию страницы в поиске.

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

Robots.txt и noindex

Подготовьте продакшен-версию robots.txt заранее. Удалите временный Disallow: / и директивы noindex, которые использовались на тестовом окружении. Не закрывайте ресурсы, необходимые для корректного рендеринга страниц.

User-agent: *
Allow: /
Disallow: /admin/
Disallow: /api/

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

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

Контент и технические элементы

До запуска сравните старую и новую версии важных страниц:

• основной текст и смысл страницы;
• <title>, description и H1;
• Open Graph;
• структурированные данные JSON-LD;
• изображения, документы и видео;
• аналитические и верификационные теги;
• мобильный рендеринг и производительность.

Если используется новый или недавно приобретённый домен, проверьте в Search Console ручные меры и оставшиеся запросы на удаление URL от прежнего владельца. Новый сервер должен выдерживать повышенный обход: после миграции Googlebot обращается и к новым URL, и к старым адресам через редиректы.

Запуск в Google и Яндексе

Google Search Console

1. Подтвердите права на старые и новые свойства, включая используемые варианты протокола, www и субдомены.
2. Включите и протестируйте редиректы.
3. Отправьте новый sitemap.
4. При смене домена или субдомена подайте заявку через Change of Address из свойства старого сайта.
5. Следите за отчётами Pages, Sitemaps, Search results и Crawl stats.

Для Change of Address нужны права владельца на обоих свойствах в одном аккаунте. Инструмент работает только со свойствами уровня домена, а не с отдельным путём.

Change of Address не используют для:

• перехода с HTTP на HTTPS;
• переключения между www и адресом без www в одном домене;
• изменения путей внутри одного сайта;
• смены хостинга без видимого изменения URL.

Для доменной миграции инструмент запускают после настройки перенаправлений. Он не заменяет карту URL и проверяет только часть условий.

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

Официальный сценарий Яндекса:

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

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

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

Ежедневно в первые дни, затем еженедельно проверяйте:

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

Диагностика типичных проблем

Массовые 404. Сопоставьте ошибки с исходным реестром. Добавьте редиректы для страниц с эквивалентной заменой; URL без замены должны осознанно возвращать 404 или 410.

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

Новые страницы не индексируются. Проверьте noindex, robots.txt, canonical, ответы сервера, доступность ресурсов и внутренние ссылки.

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

Сервер отвечает 5xx. Увеличьте доступные ресурсы или снизьте нагрузку приложения. Не блокируйте Googlebot как способ решить проблему ёмкости.

Эталонный шаблон миграции

Храните единый рабочий документ со следующими листами или разделами:

Реестр URL

old_url,new_url,expected_status,page_type,organic_clicks,backlinks,owner,verified
https://old.example/a,https://new.example/a,301,article,1200,14,content,false
https://old.example/b,,410,promo,0,0,marketing,false

Проверка перед запуском

[ ] Все строки карты имеют назначение или осознанный 404/410
[ ] Редиректы протестированы на тестовом окружении
[ ] Конечные URL отвечают 200
[ ] Canonical, hreflang и внутренние ссылки обновлены
[ ] Продакшен-версии robots.txt и robots meta подготовлены
[ ] Новый sitemap сгенерирован и провалидирован
[ ] Сохранены исходные метрики и журналы
[ ] Подтверждены свойства поисковых систем
[ ] Назначены ответственные за запуск и мониторинг

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

Минимальный проверочный сценарий должен для каждой строки фиксировать:

• первый HTTP-код;
• значение Location;
• число переходов;
• конечный URL и его код;
• canonical конечной страницы;
• наличие noindex;
• соответствие фактического результата карте.

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

Источники

• Google Search Central: перенос сайта с изменением URL
• Google Search Central: редиректы и Google Search
• Google Search Console Help: Change of Address tool
• Яндекс.Вебмастер: что такое переезд сайта и как его совершить
• Sitemaps.org: протокол Sitemap

Следующий шаг

Для контроля поисковых показателей до и после переноса используйте руководство «SEO-аналитика для сайта: Метрика, Вебмастер и Search Console».

Связанные материалы

• База знаний: Cloudflare — бесплатная защита, ускорение и управление доменами для любого сайта
• База знаний: Notion как Headless CMS: контент-движок для сайта

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov