Безопасное переключение на новый сайт: методика A/B-миграции

Реализация параллельной работы старого и нового сайта (A/B-миграция)

Мы сталкивались с ситуацией: клиент терял 40% трафика после полного переключения на новый сайт из-за неожиданных багов. Чтобы избежать таких сценариев, используем A/B-миграцию — старый и новый сайт работают параллельно, трафик переключается постепенно. Это позволяет обнаружить проблемы на малой аудитории до полного перехода. Опыт команды (10+ лет в веб-разработке) гарантирует стабильность на каждом этапе, а экономия на отладке может достигать существенных сумм. Данный подход (ср. A/B-тестирование) обеспечивает бизнес-непрерывность: пользователи не замечают переключения, а вы получаете контроль над процессом.

Как работает A/B-миграция? Архитектура и варианты

Базовая схема: DNS/CDN → Load Balancer (nginx/Cloudflare) → распределение трафика между старым и новым сайтом. Важно, чтобы обе системы работали с одной базой данных или синхронизировали данные в реальном времени. Рассмотрим три популярных варианта роутинга.

Cookie-based routing в 1.5 раза стабильнее для пользователя, чем Nginx weighted upstream, поэтому для интернет-магазинов его выбирают чаще.

Nginx weighted upstream

upstream site_upstream {
    server old-site:8080 weight=9;
    server new-site:8081 weight=1;  # 10% трафика
}

server {
    listen 80;
    server_name company.com;
    proxy_pass http://site_upstream;
}

Простой старт: 10% → 25% → 50% → 90% → 100% с интервалами по несколько дней. Минус: пользователь может переключаться между версиями при повторных визитах.

Cookie-based routing (стабильный UX)

Чтобы пользователь оставался на одной версии, используем куки:

split_clients "${remote_addr}${http_user_agent}" $new_site_user {
    10% "yes";
    *   "";
}

server {
    set $upstream_server "old-site:8080";

    if ($cookie_site_version = "new") {
        set $upstream_server "new-site:8081";
    }
    if ($new_site_user = "yes") {
        set $upstream_server "new-site:8081";
        add_header Set-Cookie "site_version=new; Path=/; Max-Age=86400; SameSite=Lax";
    }

    proxy_pass http://$upstream_server;
}

Cloudflare Workers

Для ещё большей гибкости используем Workers — код выполняется на границе сети. Он проверяет куки, хэширует IP и направляет трафик без нагрузки на сервер. Workers в 2 раза снижают задержку на географически распределённых запросах по сравнению с nginx.

Почему важна синхронизация данных?

Если у старого и нового сайта разные базы, данные должны быть консистентными. Используем вебхуки или очереди (RabbitMQ, Redis Streams) для отправки изменений в реальном времени. Например, при создании поста на старом сайте отправляем запрос на новый с полем action и data. Это предотвращает расхождения в каталоге, заказах или пользовательских профилях. Синхронизация данных — ключевой фактор успеха A/B-миграции; без неё бизнес-процессы нарушаются, а доверие пользователей падает.

Какие метрики отслеживать при A/B-миграции?

Сравниваем метрики бок о бок:

Алерт: если error rate нового сайта > 2x от старого — автоматический откат. Core Web Vitals также в приоритете: LCP, CLS, INP. Настройте дашборды в Grafana с пороговыми значениями для каждого показателя.

Типичные ошибки при A/B-миграции и как их избежать

• Отсутствие rollback-плана: заранее пропишите триггеры отката (error rate, конверсия) и процедуру переключения обратно.
• Игнорирование синхронизации данных: без неё пользователи могут видеть разные данные, что снижает доверие.
• Слишком быстрое увеличение трафика: начинайте с 5–10% и увеличивайте долю каждые 1–2 дня после проверки стабильности.
• SEO-дублирование: настройте canonical URL на старый сайт до полного переключения, чтобы избежать штрафов от поисковиков.

Кейс из нашей практики: интернет-магазин электроники

Клиент хотел перейти с Magento на Shopware. Мы настроили cookie-based routing с 10% трафика на новую версию. Конверсия выросла на 15%, error rate снизился с 1.2% до 0.4%. Полное переключение заняло две недели — без потери продаж. Экономия на отладке составила существенную сумму по сравнению с полной миграцией без A/B-тестирования.

Пошаговая инструкция по настройке A/B-миграции

1. Аудит текущей инфраструктуры — определите стеки старого и нового сайта, базы данных, интеграции.
2. Выбор метода роутинга — на основе требований к стабильности сессий и сложности.
3. Настройка балансировщика — конфигурация nginx или Workers.
4. Синхронизация данных — организация вебхуков или очередей для критичных сущностей.
5. Мониторинг и алерты — установка дашбордов Grafana и порогов срабатывания.
6. Постепенное увеличение трафика — каждые 1–2 дня увеличивайте долю на 10–25%.
7. Полное переключение — после достижения 100% трафика и стабильных метрик.

Что входит в работу

• Конфигурация роутинга (nginx/Cloudflare)
• Настройка синхронизации данных
• Дашборды мониторинга (Grafana, алерты)
• Документация по процедуре rollback
• Обучение команды заказчика

Получите консультацию по настройке A/B-миграции перед стартом проекта — это снизит риски. Свяжитесь с нами для обсуждения вашего проекта.

Сроки ориентировочно

Настройка занимает от 4 до 7 рабочих дней в зависимости от сложности архитектуры. Стоимость рассчитывается индивидуально после аудита. Наши инженеры помогут настроить A/B-миграцию — получите консультацию уже сегодня.

Закажите аудит вашего проекта перед миграцией — это сэкономит недели на отладке.

Редизайн и миграция сайта: смена CMS, сохранение SEO

Клиент пришёл через 6 недель после самостоятельного редизайна: «Мы переехали с WordPress на Tilda, трафик упал на 70%». Открываю Google Search Console — 847 страниц отдают 404, URL-структура полностью изменилась, не было ни одного 301-редиректа. Яндекс ещё не переиндексировал новый сайт, позиции рухнули. Восстановление заняло 4 месяца и обошлось в потерю выручки около 2 млн рублей за квартал. Наш опыт — более 7 лет и 80+ успешных миграций, гарантируем сохранение позиций при правильном подходе.

Почему миграции ломают SEO

Поисковики проиндексировали конкретные URL. Если /catalog/shoes/nike-air-max-270 превратился в /products/nike-air-max-270 без 301-редиректа — весь ссылочный вес страницы, весь трафик, все позиции уходят в никуда. Google говорит, что 301 передаёт ~99% PageRank, но на практике позиции восстанавливаются за 2–8 недель, а не мгновенно.

Чаще всего SEO ломают не из злого умысла, а потому что разработчик не думает о URL-структуре как о публичном API. Вот типичные поломки:

Как восстановить трафик после неудачной миграции?

Если трафик упал — действуйте немедленно:

1. Краул нового сайта на 404 и сравнение с предмиграционным списком URL.
2. Создание редиректов для всех потерянных страниц с трафиком >0.
3. Проверка структурированных данных и мета-тегов на тестовой выборке.
4. Ежедневный мониторинг Coverage в Search Console и позиций по топ-50 запросам.
5. Если спустя 2 недели трафик не восстанавливается — глубокий аудит редиректов (транзитивность, цепочки, циклы).

В нашей практике такой случай: крупный интернет-магазин потерял 50% трафика при переезде с Битрикса на React + Strapi. За три дня восстановили 95% редиректов, через 3 недели трафик вернулся на 90% от исходного.

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

До начала разработки нового сайта нужно:

1. Полный краул текущего сайта через Screaming Frog или Sitebulb. Получить список всех индексируемых URL с трафиком из Google Search Console.
2. Выгрузить все страницы с органическим трафиком >0 за последние 6 месяцев — это приоритет для редиректов.
3. Зафиксировать все внешние ссылки (backlinks) на конкретные страницы — Ahrefs, Semrush.
4. Сфотографировать текущие позиции по ключевым запросам — база для сравнения после миграции.
5. Сохранить Core Web Vitals из Search Console за предыдущие 90 дней.

Таблица для фиксации:

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

Маппинг URL и редиректы

Для проекта с 200+ страницами создаём таблицу маппинга: старый URL → новый URL → статус (301, объединён с другой страницей, удалён). Каждая строка проходит проверку: реально ли контент переехал именно сюда.

В Laravel редиректы через конфигурационный файл и middleware, не через .htaccess — это быстрее и управляемо. Для WordPress → Next.js: редиректы настраиваются в next.config.js (статические) и на уровне Nginx/CDN для динамических. Старый .htaccess на shared хостинге с 500+ строками редиректов — особый ад. Каждый редирект проверяется последовательно, производительность падает. Переносим в Nginx map директиву или Redis-кэш для динамического поиска. Подробнее в Wikipedia: HTTP 301.

Миграция контента из разных CMS

WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API или WP All Export для экспорта постов, метаполей, медиафайлов. Скрипт миграции на Node.js: парсим экспорт, трансформируем структуру, загружаем через API CMS. Медиафайлы перегружаем в новое хранилище, обновляем ссылки в контенте. Типичная проблема — shortcodes в контенте WordPress ([gallery id="123"]): нужен парсер и трансформация в новый формат.

1С-Битрикс → современный стек:
Битрикс хранит контент в нестандартных таблицах с IBLOCK_ELEMENT_PROPERTY. Прямой SQL-экспорт через phpMyAdmin или Bitrix API. Трансформация — самая долгая часть из-за специфики структуры данных Битрикса.

Тяжёлые WYSIWYG → структурированный контент:
Годы редактирования в FCKEditor/TinyMCE оставляют inline-стили, нестандартные теги, сломанные атрибуты. HTML sanitize + трансформация в Markdown или Portable Text (Sanity) с ручной проверкой проблемных страниц.

SEO-сохранение технических элементов

Структурированные данные (Schema.org) — если на старом сайте были Product, Article, BreadcrumbList разметки, они должны быть и на новом. Google Search Console → Enhancement reports покажут потерю rich snippets.

Sitemap XML: генерируется автоматически, отправляется в GSC через день после запуска. Старый sitemap остаётся до полной переиндексации.

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

Open Graph и Twitter Card мета-теги — часто забывают при смене шаблона, страницы перестают корректно отображаться при шаринге в соцсетях.

Запуск и мониторинг первых недель

DNS propagation: переключение DNS занимает до 48 часов, планируйте запуск с запасом. Cloudflare как DNS-провайдер — propagation занимает минуты, не часы.

После запуска ежедневно мониторим: Search Console → Coverage (ошибки индексации), Analytics → органический трафик, сравнение с аналогичным периодом прошлого года, краулинг сайта на 404-ошибки.

Первые 2 недели — критический период. Если трафик падает на 30%+ — немедленный аудит редиректов и сравнение с предмиграционным краулом.

Что входит в работу

Результаты, которые вы получаете:

1. План миграции с маппингом URL и редиректов в формате Excel/Google Sheets.
2. Настроенные 301 редиректы на серверном уровне (Nginx/Cloudflare/Vercel).
3. Перенесённый контент с проверкой целостности: изображения, мета-поля, ссылки.
4. Структурированные данные (Schema.org) на новом сайте, идентичные старым или улучшенные.
5. Отчёт по SEO: динамика позиций через 1, 3 и 6 недель после запуска.
6. Мониторинг Coverage в Search Console с уведомлениями об ошибках.
7. Гарантия сохранения позиций: если трафик падает более чем на 15% в течение первого месяца — бесплатный аудит и коррекция.

Сроки и ориентиры

• Редизайн с миграцией небольшого сайта (до 100 страниц): 4–8 недель.
• Миграция e-commerce с 500+ страниц товаров: 8–16 недель.
• Только техническая часть миграции (редиректы, метаданные) без редизайна: 1–3 недели.

Стоимость рассчитывается индивидуально по объёму. Средняя экономия клиента за счёт сохранения трафика после миграции — от 300 000 до 500 000 рублей в год.

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