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

Переезд сайта на новую платформу, домен или CMS — один из самых рискованных моментов в жизни проекта. Плохо спланированная миграция вполне может стоить десятков процентов органического трафика. В индустрии описаны случаи, когда сайт до обращения к специалистам терял 44% органики — порядка 500 000 пользователей. И это не аномалия, а типичный исход миграции без плана.

Но если сделать всё правильно, миграция может не только сохранить, но и улучшить позиции. Практическое правило здесь — основная часть усилий уходит на планирование (условно ~70%) и лишь меньшая на исполнение. Это руководство покрывает обе части — от инвентаризации URL до post-launch мониторинга в Яндекс.Вебмастере и Google Search Console.

Когда нужна SEO-миграция

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

Фаза 1: Инвентаризация (до переезда)

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

Экспорт всех URL

Соберите полный список URL, которые:

1. Есть в индексе — Google Search Console → Покрытие → Действующие страницы; Яндекс.Вебмастер → Индексирование → Страницы в поиске
2. Получают трафик — Google Analytics / Яндекс.Метрика → отчёт по страницам входа за последние 12 месяцев
3. Имеют внешние ссылки — Ahrefs, Serpstat или аналог → бэклинки по доменам и страницам
4. Есть в sitemap.xml — текущий файл sitemap

# Быстрый экспорт через Screaming Frog или curl
curl -s https://site.ru/sitemap.xml | grep '<loc>' | sed 's/<[^>]*>//g' > urls.txt

Фиксация метрик

Для каждой важной страницы зафиксируйте:

Фаза 2: Карта редиректов 301

Это самый критичный этап миграции. Карта редиректов — это таблица, в которой каждому старому URL сопоставлен новый. Без неё поисковые системы увидят 404 вместо ваших страниц, а вся накопленная ссылочная масса и возраст страниц будут потеряны.

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

Формат карты

Старый URL                          → Новый URL                         Статус
/catalog/shoes/nike-air              → /products/nike-air-max            301
/blog/2024/best-running-shoes        → /articles/best-running-shoes      301
/about/team                          → /company/team                     301
/promo/black-friday-2023             → (удалена)                         410

Реализация на сервере

# Nginx — постраничные редиректы
server {
    # ...
    location = /catalog/shoes/nike-air {
        return 301 /products/nike-air-max;
    }

    # Паттерн для категорий
    location ~ ^/catalog/(.*)$ {
        return 301 /products/$1;
    }
}

# Apache .htaccess
Redirect 301 /catalog/shoes/nike-air /products/nike-air-max
RedirectMatch 301 ^/blog/([0-9]{4})/(.*)$ /articles/$2

# Next.js — next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/catalog/shoes/nike-air',
        destination: '/products/nike-air-max',
        permanent: true, // 301
      },
      {
        source: '/blog/:year/:slug',
        destination: '/articles/:slug',
        permanent: true,
      },
    ]
  },
}

Ловушка .htaccess: редиректы молча не работают

Частый сценарий: на старом хостинге был Apache, и за годы в .htaccess накопились сотни правил — редиректы, rewrite, заголовки. При переезде файл копируют на новый сервер, где стоит Nginx. А Nginx .htaccess не читает вообще — не ругается, не предупреждает, просто игнорирует. Все 301-редиректы и правила перестают работать одномоментно и беззвучно.

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

Как продиагностировать:

# 1. Узнать, какой сервер на самом деле обслуживает сайт
curl -sI https://new-site.ru | grep -i server
# Server: nginx  → .htaccess не работает, правила нужны в конфиге Nginx
# Server: Apache → .htaccess читается

# 2. Проверить, что старый URL реально отдаёт 301, а не 404/200
curl -sI https://new-site.ru/old-page | grep -iE 'HTTP|location'
# Должно быть: HTTP/1.1 301 + Location: /new-page

Нюанс: на некоторых панелях (ISPmanager, ряд хостингов) Nginx стоит фронтендом перед Apache, и тогда .htaccess может частично работать через Apache-бэкенд. Ориентируйтесь не на «у меня вроде Apache», а на фактический ответ curl по старым URL.

Фаза 3: Техническая подготовка нового сайта

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

sitemap.xml

• Содержит только новые URL (не старые)
• Все URL — каноничные версии (https, с/без www — единообразно)
• Формат соответствует стандарту sitemaps.org
• Размер: до 50 000 URL или 50 МБ на файл, используйте sitemap index для больших сайтов

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://new-site.ru/products/nike-air-max</loc>
    <lastmod>2026-06-13</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>
</urlset>

robots.txt

• Разрешить краулинг всех важных разделов
• Указать путь к sitemap.xml
• Не блокировать CSS, JS и изображения — поисковики должны видеть рендеренную страницу

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

Sitemap: https://new-site.ru/sitemap.xml

Canonical-теги

Каждая страница должна иметь <link rel="canonical">, указывающий на её каноничную версию:

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

• Canonical должен указывать на новый URL, не на старый
• На всех версиях страницы (http/https, www/без www) canonical одинаковый
• Для пагинации: каждая страница каноничная сама на себя (Google отказался от rel=prev/next)

Open Graph и метатеги

При миграции часто теряются:

Фаза 4: Запуск и регистрация в поисковых системах

Google Search Console

1. Добавить новый сайт как свойство в GSC (если сменился домен)
2. Подтвердить владение — через DNS-запись, HTML-файл или тег
3. Подать заявку на смену адреса (Settings → Change of Address) — только при смене домена. GSC покажет проверку: 301-редиректы, подтверждение обоих сайтов
4. Отправить новый sitemap.xml — Sitemaps → Add a new sitemap
5. Проверить покрытие — через 2–3 дня в разделе Pages появятся данные о новых URL

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

1. Добавить новый сайт в Вебмастер и подтвердить права
2. Указать переезд — Индексирование → Переезд сайта → ввести новый домен. Яндекс начнёт склейку доменов (занимает 2–4 недели)
3. Отправить sitemap.xml — Индексирование → Файлы Sitemap
4. Проверить ответы сервера — Индексирование → Проверка ответа сервера → ввести старые URL и убедиться, что ответ 301
5. Настроить регион (если нужно) — Информация о сайте → Региональность

Фаза 5: Post-launch мониторинг

Первые 4–8 недель после запуска — критический период. Трафик может просесть на 10–20% даже при идеальной миграции. Задача — отличить нормальное «переходное» падение от реальной проблемы.

Еженедельный мониторинг

Типичные проблемы и решения

Антипаттерны

Чеклист

Pre-launch

Launch

Post-launch

Полезные ссылки

• Google: Как переместить сайт — официальная документация
• Google: Canonical URL — как правильно настроить
• Google: Rich Results Test — проверка структурированных данных
• Яндекс: Переезд сайта в Вебмастере — инструкция по подаче заявки
• Sitemaps.org: Протокол sitemap — спецификация формата
• Shopify: SEO Site Migration Checklist (2026) — подробный чеклист
• Habr: Как правильно сделать перенос сайта — практическое руководство на русском

По теме

• Статья: Сайт как редакторский граф
• Блог: Как сеньоры масштабируются с агентами
• База знаний: DeepSeek — как использовать API и модели

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