Безпечне оновлення сайту: A/B-тестування для поступового переходу

Для безпечного переключення на новий сайт ми використовуємо A/B-міграцію. Ми стикалися з ситуацією: клієнт втрачав 40% трафіку після повного перемикання на новий сайт через неочікувані баги. Щоб уникнути таких сценаріїв, використовуємо A/B-міграцію — старий і новий сайт працюють паралельно, трафік перемикається поступово. Це дозволяє виявити проблеми на малій аудиторії до повного переходу. Наша команда має 10+ років досвіду та успішно реалізувала понад 20 міграцій. Досвід команди (10+ років у веб-розробці) гарантує стабільність на кожному етапі, а економія на налагодженні може сягати до $3,000. Даний підхід (пор. A/B-тестування) забезпечує бізнес-безперервність: користувачі не помічають перемикання, а ви отримуєте контроль над процесом.

Як працює A/B-міграція? Архітектура та варіанти

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

Cookie-based routing краще ніж Nginx weighted upstream у 1.5 рази за стабільністю сесій, тому для інтернет-магазинів його обирають частіше.

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 і направляє трафік без навантаження на сервер. Cloudflare 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 на старий сайт до повного перемикання, щоб уникнути штрафів від пошуковиків.

Покрокова інструкція з налаштування 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 місяці та призвело до значних фінансових втрат. Наш досвід — понад 7 років та 80+ успішних міграцій. Клієнти, які замовляють професійну міграцію, відновлюють трафік у 3 рази швидше, ніж ті, хто виконує її самостійно.

Чому міграції ламають 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-кеш для динамічного пошуку.

Міграція контенту з різних 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 тижні.

Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.

Отримайте консультацію по вашому проекту — ми відповімо протягом дня. Замовте передміграційний аудит вашого сайту та отримайте точний кошторис з планом редиректів. Зв'яжіться з нами, щоб обговорити деталі.