Більшість студій тихне після запуску. Сайт іде в живе, студія шле фінальний інвойс, команда постить LinkedIn-анонс. Через три місяці щось ламається, і ніхто до кінця не знає, хто відповідальний.
Ми робимо це інакше. Перші 90 днів після запуску — це там, де відбувається справжня робота. Сайт у живому, але ще не доведений. Метрики, що мали значення у розробці (бали Lighthouse, аудити доступності), тепер приєднуються до метрик, які ви не могли виміряти раніше (реальні користувачі, реальний трафік, реальна конверсія).
Ось що ми дивимось за ці 90 днів, на що діємо, і що лишаємо в спокої.
Година нуль: готовність до запуску
Перед запуском — чеклист:
- 301-редиректи на місці для будь-яких URL, що змінились.
- DNS TTL опущено до 5 хвилин за день до, піднято назад до 24 годин через тиждень після.
- Бекапи підтверджено робочими і відновлюваними.
- Моніторинг (Sentry, uptime, аналітика) підтверджено стріляючим на staging.
- Скрипт smoke-test готовий запуститись проти продакшну одразу post-cutover.
- План відкату задокументовано і протестовано.
Ми не запускаємо у п'ятницю. Не запускаємо за день до того, як хтось іде у відпустку. Не запускаємо, коли половина команди не може бути онлайн наступні чотири години.
Година 1-24: surface-перевірки
Перші 24 години — переважно про вилов речей, що проявляються лише у проді.
Що моніторимо:
Error rate. Обсяг помилок Sentry має короткочасно стрибнути на запуску (приріст трафіку розкриває помилки), потім впасти за 4-6 годин. Якщо ні — щось конкретне зламано. Поширені винуватці: відсутня змінна середовища, проблема CORS з новим third-party, route handler, що повертає 500.
Uptime-моніторинг. Зовнішні пінги мають повертати 200. Якщо будь-який регіон показує downtime — перевіряємо CDN і DNS.
Конверсійні шляхи. Вручну проходимо контактну форму, signup-флоу, будь-які платіжні шляхи. Речі, що працювали на staging, іноді не працюють у проді через тонкі відмінності середовища (різні API-ключі, різні feature flags, різні CORS-правила домену).
Індексація. Подаємо нову sitemap у Google Search Console. Підтверджуємо, що головна індексується за кілька годин. Перший crawl — корисний сигнал, що технічне SEO правильне.
Email deliverability. Якщо сайт надсилає транзакційні email — шлемо тест на Gmail-адресу і Yahoo-адресу. Підтверджуємо, що приходить у inbox, не спам. Misconfigurations SPF/DKIM/DMARC проявляються тут швидко.
Якщо усе виглядає нормально через 4 години — миттєва крайна запуску позаду. Наступна фаза — спостереження.
День 1-7: тренди, не точкові метрики
Перший тиждень — про встановлення нового baseline.
Що дивимось щодня:
Real-user Web Vitals. Синтетичні бали Lighthouse — одна цифра. Real-user CrUX-дані — це правда. Перші 7 днів реального трафіку кажуть, чи Performance насправді 100 для реальних користувачів на реальних пристроях, чи lab-бал був обманливим.
Дивимось: перцентилі LCP за класом пристрою, outliers INP, проблеми CLS, що не з'явились у лабі.
Search Console impressions. Новий або перебудований сайт бере дні, щоб реакумулювати ранкінг. Не панікуйте, якщо impressions падають у день 1. Дивіться тренд за тиждень.
Bounce rate і час на сторінці. Перший тиждень показує, як новий сайт працює проти старого baseline (якщо у вас була аналітика на старому). Значне зростання bounce rate на ключових landing — сигнал, що щось гірше.
Конверсійні воронки. Чи втримався submission rate контактної форми? Чи втримався demo-signup rate? Якщо конверсія впала після запуску — новий дизайн може гірше працювати на метриках, що важать, незалежно від того, як виглядає.
Ми не діємо на цифрах дня 1. Діємо на цифрах днів 4-5, де достатньо даних, щоб зрозуміти, чи це тренд чи шум.
День 7-30: можливості оптимізації
Перший місяць — коли починається таргетна оптимізація.
Над чим працюємо:
Сторінки, що не дотягують. Якщо service-сторінка конвертує наполовину гірше за інших — A/B-тестуємо. Якщо індекс блогу має високий трафік, але низький CTR до статей — передизайнимо картки. Дані кажуть, що пріоритизувати.
Проблеми Search Console. Сторінки «Crawled - currently not indexed». Warning «Soft 404». Сторінки, що отримують impressions, але без кліків (натяк, що title чи description не виконують роботу). Кожна — 30-хвилинний фікс.
Real-user продуктивність. Якщо CrUX показує INP-проблеми на мобілці, які лаба пропустила — полюємо. Зазвичай JavaScript-інтеракція, що блокує main thread, часто у third-party віджеті.
Контентні gaps. Якщо користувачі шукають терміни, які сайт не покриває (видно у Search Console) — або додаємо сторінку, або переробляємо існуючу. Контентна мапа сайту має адаптуватись до того, що відвідувачі насправді шукають.
Це там, де структура плану підтримки окупається — у нас виділено години на цю роботу без того, щоб вона була окремим проєктом щоразу.
День 30-90: стабілізація і вивчене
До другого і третього місяця сайт осідає у новий baseline. Робота зміщується з оптимізації на insight.
Що дивимось:
Тримісячні дельти конверсії. Порівняти rate конверсії з pre-launch baseline. Чи новий сайт справді кращий? На яких сторінках? Наскільки? Деякі сторінки покращуються драматично; інші лишаються плоскими; рідко — деякі стають гіршими. Чесний вимір.
Top-traffic сторінки. Які сторінки отримують найбільше трафіку, і чи це той трафік-mix, який хотіли? Іноді блог-пост, що не очікували ранкуватись, стає top entry point. Це сигнал інвестувати більше у цю тему.
SEO-позиція ранкінгу. Де ви ранкуєтесь за ключами, що важать? Чи перебудова зрушила їх вгору, вниз чи вбік? Використайте відстеження ранкінгу (Ahrefs, SEMrush або Search Console для середніх позицій).
«Звіт перших 90 днів». У кінці періоду ми пишемо короткий звіт: що змінилось, що покращилось, що ні, що б ми робили інакше. Клієнт читає. Обговорюємо разом. Це інформує наступну фазу.
Це звіт, якого більшість студій не пише. Це найкорисніший один документ за весь проєкт.
Що ми робимо, тиждень за тижнем
Каденція, яку тримаємо перші 90 днів:
Щодня (тиждень 1): перевірка error rate, uptime, smoke-test ключових флоу.
Щотижня (тижні 2-12): ревью Search Console, CrUX, метрик конверсії, error-логів. 30-60 хвилин. Документуємо все, що потребує follow-up.
Раз на два тижні (тижні 2-12): 30-хвилинний sync з клієнтом. Що помітили, на що подіяли, що хочемо знати від них.
Щомісяця: письмовий звіт. Бали Lighthouse (поточний vs. baseline запуску), Search Console (impressions, кліки, top-сторінки), метрики конверсії, над чим працювали, що заплановано.
День 90: «звіт перших 90 днів». Комплексний погляд назад, рекомендації вперед.
Це ритм. Він не важкий; це близько 4-6 годин на тиждень сумарного часу. Він ловить проблеми рано і продукує паперовий слід того, що зроблено і що спрацювало.
Чому це важить
Чесні причини, чому ми робимо це:
Це ловить проблеми, перш ніж вони складуться. Баг на запуску, який не зловлено за 30 днів — це баг, що впливав на користувачів 30 днів. Ціна повільної детекції реальна, навіть якщо баг виглядає малим.
Це генерує вивчене, що інформує наступний проєкт. «Звіт перших 90 днів» каже нам, для наступного проєкту, що пріоритизувати у дизайні й інженерії. Студія, що не ревьюїть запуски, не вчиться з них.
Це заробляє наступну фазу роботи. Клієнти, які бачать уважний моніторинг після запуску, лишаються клієнтами. Контракт на підтримку, наступна фіча, реферал у їхню мережу — приходять зі стосунок, які не закінчились на запуску.
Це чесна версія «нам важить робота». Більшість студій це каже. Мало хто з них досі відповідає на DM про сайт у четвертий місяць. Ті, що так — зазвичай ті, кого клієнт рекомендує.
Короткий підсумок фреймворку
- Година 1: surface-перевірки (error rate, uptime, smoke-тести).
- День 1-7: встановити real-user baseline (Web Vitals, конверсія, пошук).
- День 7-30: таргетна оптимізація на основі того, що показують дані.
- День 30-90: стабілізація, глибший insight, ретроспектива.
Якщо запускаєте щось або запустили недавно і хочете структурований період після запуску, почніть розмову. Ми це зашиваємо у кожен проєкт, який відвантажуємо, але робимо це і як standalone для сайтів, які не будували.