Миграция на headless без потери SEO: план по шагам

Headless‑миграция убивает SEO, если планировать её как обычный редизайн. URL‑структура меняется, canonical уезжает, hreflang ломается, sitemap опаздывает на пару недель — и через месяц после переезда вы смотрите в Search Console на минус 40% органики и не понимаете, как откатиться.

Делимся планом, по которому переводим магазины с 1С‑Битрикс на Next.js. На каждом этапе есть критерий «можно идти дальше». Если критерий не выполняется — не движемся. Это медленнее, но не приходится потом разбирать постмортем.

1. URL‑structure: 1:1 или строгий redirect‑map

Первое решение, которое нужно зафиксировать до старта разработки — что будет с URL. Вариантов два, и оба легитимные:

• 1:1. Старые URL‑ы Битрикса сохраняются на новом фронте побайтно. Это правило по умолчанию: новый Next.js‑роутер принимает /catalog/
  //, обрабатывает их так же, как Битрикс, отдаёт ту же страницу. SEO‑история, ссылки из писем, закладки пользователей, индекс Google — всё продолжает работать без 301.
• Новая структура + 301 map. Если URL‑ы переезжают сознательно (например, убирается завершающий слэш, меняются slug‑и категорий) — каждый старый URL должен иметь явный 301 на новый. Map составляется до разработки, не после. Включается в момент переключения трафика, не позже.

Критерий выхода: либо список «всё 1:1, исключений нет», либо CSV с парами old_url → new_url на каждый индексируемый URL Битрикса. Не вылавливать редиректы постфактум — за каждую промашку платим органикой.

2. Canonical: явный self‑reference, без cross‑locale ошибок

На каждой странице нового фронта добавляем явный на саму себя (без UTM, без хешей, в той самой версии URL, которая попадёт в sitemap). Без этого Google имеет право выбрать любой вариант — с www, без www, с трейлинг‑слэшем, без — и склеить ваши страницы как ему удобно.

Отдельная боль: cross‑locale canonical. Если у вас русская и английская версии сайта, RU‑страница должна канонизироваться сама на себя (/ru/foo), а не на EN‑зеркало. EN‑страница — сама на себя. Hreflang отвечает за связь, canonical — за самоидентификацию. Путаница тут приводит к выпадению одного из языков из индекса целиком.

3. Hreflang: полный цикл взаимных ссылок

Если сайт мультиязычный, hreflang должен быть на каждой странице в обоих локалях. Минимальный набор тегов на RU‑странице:

Тот же блок — на EN‑странице, с противоположной симметрией. Если на одной стороне ссылка есть, а на второй нет — Google трактует как ошибку и игнорирует hreflang целиком. Самый частый баг: новые страницы добавили, hreflang забыли, поисковик неделю пытается понять, какую страницу показывать в SERP, и в итоге показывает не ту.

Критерий выхода: автоматический e2e‑тест в CI, который проходит по карте сайта, дёргает hreflang каждой страницы и проверяет обратную ссылку. Без теста человек обязательно где‑то пропустит.

4. Sitemap delta: что добавилось, что ушло, в какой день

Новый sitemap.xml генерируется фронтом (в Next.js это обычно app/sitemap.xml/route.ts) и должен содержать только индексируемые URL: без thank-you, без /api/*, без legal, без noindex‑страниц. Lastmod — реальная дата последнего изменения контента, а не дата сборки.

Перед переключением трафика готовим три файла:

• Sitemap старого сайта — снимок состояния до миграции.
• Sitemap нового сайта — что отдаёт Next.js в день‑X.
• Delta‑отчёт — какие URL ушли (должны быть закрыты 301), какие добавились (должны индексироваться), какие остались без изменений.

Delta — это основной артефакт, по которому проверяется правильность миграции на стороне поисковика. Без него вы будете гадать, индексируется ли страница, по графику в Search Console.

5. Google Search Console и Яндекс.Вебмастер: ручная подача

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

• В Google Search Console: Sitemaps → Add new → /sitemap.xml. Через час проверяем, что sitemap прочитан, ошибок 0.
• В Яндекс.Вебмастере: Индексирование → Файлы Sitemap. Дополнительно — раздел Переобход страниц, куда вручную добавляем топ‑20 самых трафиковых URL‑ов первой недели.
• IndexNow (Bing, Yandex) — если фронт умеет (у нас в Frontbox умеет), посылаем сигнал об изменениях сразу. Это даёт переиндексацию за часы, а не дни.

6. Pre/Post measurement: фиксируем метрики до и после

За две недели до переключения трафика снимаем baseline:

• Органический трафик в день — медиана по 14 дням.
• Топ‑50 запросов и позиции по каждому (Search Console).
• Топ‑200 страниц по показам и кликам.
• Core Web Vitals: LCP, INP, CLS (CrUX или Lighthouse).
• Доля проиндексированных страниц от sitemap‑а.

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

На headless‑миграции с правильной 1:1 структурой Core Web Vitals улучшаются с первого дня (это положительный ранжирующий сигнал), а трафик не должен проседать совсем. Если просел — что‑то сломали технически. Чек‑лист расследования в следующем разделе.

7. Fallback rollback: план Б, который реально работает

Самое недооценённое — план Б. Если новая версия после раскатки рушит ранжирование, мы должны уметь откатить трафик за минуты, а не часы.

Как мы это делаем на Frontbox:

• Старый Битрикс‑фронт остаётся развёрнутым и работоспособным в течение первого месяца после миграции.
• Переключение трафика — через DNS или edge‑router (Cloudflare Workers, nginx upstream). Не через большой деплой.
• Поэтапная раскатка: 5% → 25% → 100% с паузой 2–3 дня на каждой ступени, чтобы успеть увидеть проблему до того, как пострадает 100% трафика.
• Триггеры автоматического отката: 5xx>1%, LCP>4s на p75, падение конверсии на проверочной когорте более 15%.

Если триггер сработал — трафик автоматически уезжает обратно на Битрикс. Дальше — разбор инцидента, а не паника.

Что должно быть готово до дня‑X

Чек‑лист, по которому мы принимаем решение запускать переключение трафика:

• URL‑map (1:1 или 301) подтверждён и подписан.
• Canonical отдаётся правильно на всех индексируемых URL — проверено e2e‑тестом.
• Hreflang между ru/en полный, симметричный — проверено e2e‑тестом.
• Sitemap.xml собирается на фронте, lastmod — реальный.
• Delta‑отчёт по sitemap до/после — на руках.
• Robots.txt: AI‑боты разрешены, чувствительные пути закрыты.
• OG/Twitter теги перенесены и валидны (1200×630, alt, description).
• Schema.org перенесена — Organization, BreadcrumbList на каждой странице, плюс Service/Product/Article где уместно.
• Core Web Vitals у нового фронта на p75 — зелёные.
• Yandex Metrika и GA4 настроены, события собираются.
• Rollback‑механизм проверен (раскатывали 1% и откатывали).
• Baseline метрик собран за 14 дней.

Почему headless при правильной миграции помогает SEO

Технически грамотная headless‑миграция почти всегда даёт прирост органики через 2–4 месяца после стабилизации, потому что:

• Core Web Vitals на Next.js обычно в 3–5× лучше, чем на типовом Битрикс‑фронте. Это прямой ранжирующий фактор с 2021 года.
• SSR/SSG отдаёт полный HTML на первый запрос — Google и Яндекс не зависят от JavaScript‑рендеринга.
• Schema.org проще поддерживать в кодовой базе фронта, чем в Битрикс‑шаблонах.
• Sitemap всегда актуальный — генерируется из реальных данных, а не вручную составляется.

Но всё это работает только при условии, что вы прошли семь шагов выше. Без них headless становится способом потерять трафик красиво.

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

Если у вас Битрикс‑магазин и вы думаете о headless — начните с Catalog Probe: за 3 дня поднимаем headless‑витрину на вашем каталоге, замеряем метрики, отдаём отчёт. Решение, идти ли дальше в полный Headless Pilot, принимаете на основе цифр, а не презентаций.

SEO‑миграция в комплекте: 1:1 URL, canonical/hreflang/sitemap — всё переносится автоматически, потеря трафика стремится к нулю.