Готовність сайту до Чорної пʼятниці 2026: чек-лист

Коротко

Чорна пʼятниця — 27 листопада 2026, Cyber Monday — 30 листопада. Коли лишається близько трьох тижнів, дивіться не на головну, а на шлях, що приносить гроші: картка товару, кошик і оформлення замовлення. Заморозьте обсяг робіт, приберіть зайві сторонні скрипти, протестуйте навантаженням весь шлях покупки, перевірте оплату й синхронізацію залишків, налаштуйте моніторинг і план відкату. Таблиця нижче розрахована на пізній старт; порогові значення ви вписуєте зі своєї бази.

Піковий період рідко ламає магазин через головну сторінку. Ламається оформлення замовлення, зворотний виклик оплати, синхронізація залишків або скрипт, про який усі забули. Тому план більше про шлях покупки й контроль змін, ніж про дизайн.

Чому пік ламає магазини

Трафік приходить сплесками, найчастіше одразу після розсилки чи запуску реклами, а не рівномірно протягом дня.
Оформлення замовлення — найкрихкіша ділянка: воно залежить від платіжних сервісів, залишків, правил доставки, логіки знижок і кількох скриптів одночасно.
Команди роблять пізні зміни. Новий банер, застосунок знижок чи тег відстеження в останній тиждень — типова причина проблем.
Ніхто не відповідає за весь шлях. Маркетинг, розробка й операційна команда дивляться кожен на свій шматок.

Призначте одну людину, яка відповідає за готовність до розпродажу, і ще одну, яка має право сказати «ні» пізнім змінам.

Таймлайн T-21 – T-0

Скопіюйте таблицю й заповніть пороги з вашої останньої кампанії чи звичайного тижня. Універсальних цифр ми не наводимо, бо вони залежать від платформи, каталогу й трафіку.

Коли	Мета	Перевірки	Ваш поріг (заповнити)
T-21 – T-18 (бл. 6 – 9 лист.)	База й обсяг	Зафіксувати поточну швидкість головної, категорії, картки, кошика, оформлення. Скласти список скриптів і застосунків. Записати календар розпродажу.	Базові цифри збережено
T-17 – T-14 (10 – 13 лист.)	Заморозка обсягу	Жодних нових функцій після цієї дати, лише виправлення. Визначити, хто погоджує винятки.	Дату заморозки узгоджено
T-13 – T-10 (14 – 17 лист.)	Вага й скрипти	Прибрати або відкласти зайві сторонні скрипти й застосунки. Стиснути зображення. Перевірити кешування.	Ціль за вагою / кількістю скриптів
T-9 – T-7 (18 – 20 лист.)	Тест навантаження	Протестувати весь шлях: перегляд, додавання в кошик, оформлення, оплата. Піднімати навантаження кроками до деградації.	Максимум до помилок
T-6 – T-4 (21 – 23 лист.)	Оплата, залишки, знижки	Протестувати кожен спосіб оплати. Перевірити синхронізацію залишків. Перевірити комбінації знижок і промокодів.	Усі тести пройдено
T-3 – T-1 (24 – 26 лист.)	Підготовка до запуску	Моніторинг, сповіщення, графік чергування, план відкату, повідомлення для клієнтів, інструктаж підтримки.	Сповіщення спрацьовують у тесті
T-0 (27 – 30 лист.)	Розпродаж	Перевіряти тричі на день. Лише заплановані зміни.	Щоденний розбір

Якщо стартуєте пізніше, дивіться розділ «Варіант для пізнього старту».

Задайте цілі за останньою кампанією й прогнозом

Перш ніж щось тестувати, потрібна ціль: що має витримати магазин.

Візьміть день із найбільшим трафіком (минулий розпродаж, велика розсилка) і запишіть сесії та замовлення за годину.
Додайте запас з огляду на заплановані витрати. Якщо рекламні бюджети зростуть (див. наш чек-лист для реклами), трафік теж зросте.
Визначте поведінку на піку, наприклад скільки людей одночасно оформлюють замовлення, як частку сесій, яку видно в аналітиці.

Використовуйте це як тестові цілі, а не як обіцянки. Якщо історії немає, тестуйте кроками до першої поломки й вважайте це знайденою межею.

Перший етап: заморозка обсягу й аудит скриптів

Заморозьте обсяг. Після дати заморозки лише виправлення. Вимагайте письмову причину для кожного винятку.
Складіть список усіх сторонніх скриптів і застосунків. Додайте менеджери тегів, віджети чату, застосунки відгуків, A/B-інструменти, пікселі ретаргетингу й персоналізацію. Для кожного запитайте: чи потрібен він під час розпродажу і що станеться з оформленням, якщо він упаде?
Приберіть або відкладіть зайве. Менше скриптів — менше точок відмови й часто швидші сторінки.
Зафіксуйте відстеження. Не змінюйте налаштування аналітики й рекламних тегів в останній тиждень.

Другий етап: навантажувальний тест усього шляху

Тест, що б’є лише по головній, мало що показує.

Тестуйте весь шлях: перегляд, пошук, додавання в кошик, застосування знижки, оформлення, оплата.
Робіть це на тестовій копії з реалістичними даними, а не на бойовому оформленні з реальними платежами.
Піднімайте навантаження кроками і відмічайте, де починаються помилки чи повільні відповіді. Ця точка — ваша відома межа.
Перевірте, що буде вище межі: черга, зрозуміле повідомлення про помилку чи збій.
Дотримуйтесь правил платформи. Хостингові платформи часто обмежують тести навантаження або самі керують потужністю, тому прочитайте правила постачальника й за потреби запитайте підтримку.

Запишіть результат і порівняйте його із ціллю, яку визначили раніше.

Третій етап: оплата, залишки й знижки

Способи оплати: протестуйте кожен увімкнений спосіб від початку до кінця, включно з невдалими платежами, додатковою перевіркою банку й поверненнями. Подумайте, чи потрібна друга опція оплати, якщо основний сервіс — єдина точка відмови. Перегляньте сторінку статусу й обмеження у документації сервісу.
Залишки: переконайтеся, що залишки синхронізуються між складом, обліковою системою й магазином. Продаж того, чого немає, на піку коштує дорого.
Комбінації знижок: протестуйте поєднання промокодів, автоматичних знижок, подарункових карток і порогів безкоштовної доставки. Помилки тут швидко коштують грошей.
Доставка: терміни відправлення й оцінки доставки мають бути точними й помітними. Способи доставки й перевізників перевіряйте за власним договором.
Листи й сповіщення: підтвердження замовлення й листи про відправлення мають надсилатися коректно під навантаженням.

Core Web Vitals у кошику й на оформленні

Швидкість найважливіша там, де платять. Опубліковані Google пороги «добре» з web.dev:

Largest Contentful Paint (LCP): до 2,5 с.
Interaction to Next Paint (INP): до 200 мс.
Cumulative Layout Shift (CLS): до 0,1.

Вимірюйте їх на картці товару, у кошику й на оформленні, а не лише на головній, і користуйтеся польовими даними, якщо вони є. Типові причини поганих результатів на сторінці оформлення: важкі скрипти, великі зображення, зсув макета через банери, що довантажуються, і повільні відповіді сторонніх сервісів.

Тиждень запуску: моніторинг, відкат, чергування

Моніторинг: перевірка доступності ключових сторінок, сповіщення про рівень помилок, конверсія оформлення і сповіщення про невдалі платежі.
План відкату: знайте, як повернути останній деплой і хто це може зробити. Відпрацюйте раз.
Графік чергування: названа людина для розробки, операцій, платежів і підтримки, із запасним варіантом, на дні розпродажу.
Комунікація: що ви скажете клієнтам, якщо щось відмовить.
Узгодження з рекламою: дані й ціни у фіді мають збігатися із сайтом. Див. чек-лист аудиту Performance Max.

Блок моніторингу на Cyber Monday (30 листопада)

Перевіряйте у три фіксовані моменти й записуйте, що побачили.

09:00: сайт працює, оформлення проходить із реальним тестовим замовленням, способи оплати відповідають, залишки виглядають правильно, помилок не побільшало.
14:00: конверсія оформлення порівняно зі звичайним днем, невдалі платежі, повільні сторінки, звернення в підтримку про сайт.
21:00: замовлення відносно плану, товари без залишків, що виправити до завтра, і нотатка для розбору після події.

Варіант для пізнього старту: якщо лишився тиждень

Робіть у такому порядку:

Заморозьте зміни сьогодні.
Приберіть скрипти, які не потрібні.
Вручну протестуйте оформлення й кожен спосіб оплати.
Налаштуйте сповіщення про доступність і невдалі платежі.
Запишіть, хто на зв’язку і як відкотити зміни.

Пропустіть усе, що вимагає великих змін. Невеликий стабільний магазин кращий за недороблене покращення.

Після події

Збережіть дані: пікові навантаження, помилки, повільні сторінки, що відмовило і що змінили б. Наступного року це стане вашою базою. Той самий план годиться для будь-якого великого розпродажу, тож тримайте його як шаблон.

Поширені запитання

Коли почати готувати магазин до Чорної пʼятниці? Для великих магазинів ідеально за вісім–дванадцять тижнів. Якщо лишилося близько трьох, користуйтеся таймлайном вище й зосередьтеся на шляху покупки.

Як протестувати оформлення навантаженням, не зашкодивши реальним клієнтам? Використовуйте тестове середовище з реалістичними даними й тестовими платежами та дотримуйтесь правил платформи щодо тестів навантаження. Не запускайте важкі тести на бойовому оформленні в робочі години.

Чи потрібен другий платіжний сервіс? Він зменшує ризик єдиної точки відмови, але додає роботи з налаштування й тестування. Порівняйте вартість втрачених замовлень під час збою з витратами зусиль і перегляньте інформацію про надійність вашого сервісу.

Що заморозити в останній тиждень? Нові функції, зміни теми, нові застосунки й скрипти, зміни відстеження. Допускайте лише виправлення з письмовою причиною.

Які Core Web Vitals важливіші на кошику й оформленні? Важливі всі три, але INP (чутливість) і CLS (стабільність макета) покупці відчувають, коли натискають кнопки й вводять дані. Вимірюйте картку, кошик і оформлення окремо.

Потрібен огляд магазину перед піком?

Ми можемо переглянути швидкість, оформлення й відстеження та сказати, що виправити до розпродажу, і оцінити роботи. Дивіться послугу розробки інтернет-магазинів і маркетплейсів або зв’яжіться з нами.