Як прийняти сайт у розробника перед запуском: повний чекліст перевірки

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

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

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

Що означає «прийняти сайт»

Прийняти сайт — означає підтвердити чотири речі:

1. погоджений обсяг робіт виконано;
2. критичні користувацькі сценарії працюють;
3. замовник отримав контроль над активами й доступами;
4. відомо, хто й у які строки усуває помилки після запуску.

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

Матриця пріоритетів

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

Крок 1. Підготуйте основу перевірки

Зберіть в одному місці договір, додатки, прототипи, погоджені макети, карту сторінок, функціональні вимоги, список інтеграцій і переписку зі змінами. Якщо вимоги були усними, створіть підсумкову таблицю й попросіть обидві сторони її підтвердити.

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

Створіть таблицю приймання з полями:

• номер і назва перевірки;
• URL або екран;
• пристрій і браузер;
• очікуваний результат;
• фактичний результат;
• пріоритет;
• скриншот або відео;
• відповідальний;
• строк повторної перевірки;
• статус.

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

Крок 2. Тестуйте на правильному середовищі

Основну перевірку зручно проводити на staging-версії, закритій паролем та від індексації. Але остаточне приймання можливе лише після короткого повторного тесту на бойовому домені: під час перенесення змінюються DNS, SSL, шляхи до файлів, кеш, пошта, платіжні callback URL та правила редиректів.

Запишіть версію збірки або точний час, з якого почалося тестування. Інакше розробник може виправити частину проблем під час перевірки, а замовник не зрозуміє, який результат він фактично приймає.

Для бойового середовища перевірте:

• домен відкриває потрібний сервер;
• HTTPS працює без попереджень;
• усі ресурси завантажуються через HTTPS;
• тестова версія не доступна пошуковим роботам;
• production не залишився закритим через noindex або пароль;
• резервна копія створена безпосередньо перед перенесенням.

Якість сервера, SSL і резервних копій варто погодити разом із хостингом для сайту, а не після першого збою.

Крок 3. Пройдіть критичні сценарії як користувач

Не перевіряйте сайт лише сторінка за сторінкою. Складіть маршрути, заради яких його створено:

Google або реклама → посадкова сторінка → доказ довіри → форма → підтвердження → CRM → відповідь менеджера

Для інтернет-магазину додайте пошук, фільтр, товар, варіант, кошик, промокод, доставку, оплату, лист і зміну статусу. Для сервісного бізнесу — сторінку послуги, кейс, ціну, форму, дзвінок і запис. Для кабінету — реєстрацію, відновлення пароля, ролі, документи й вихід.

Кожен сценарій перевіряйте щонайменше у трьох станах:

• нормальні правильні дані;
• помилка користувача;
• технічна відмова або недоступна інтеграція.

Система повинна не лише прийняти правильний запит, а й зрозуміло пояснити помилку без втрати введених даних.

Крок 4. Перевірте всі сторінки й навігацію

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

Перевірте:

• чи немає порожніх сторінок, Lorem ipsum, тестових товарів і службових назв;
• чи правильні телефони, адреси, графік, email і реквізити;
• чи відкриваються зовнішні посилання очікуваним способом;
• чи не ведуть кнопки на #, staging або старий домен;
• чи є зрозуміла сторінка 404;
• чи повертає неіснуюча URL саме код 404, а не 200;
• чи працюють пошук, фільтри, сортування й пагінація;
• чи зберігається логіка повернення назад.

Для швидкої технічної перевірки кодів відповіді, редиректів і доменних даних можна використати інструменти BB STUDIO. Водночас автоматичний сканер не замінює ручного проходження сценаріїв.

Крок 5. Звірте дизайн із макетами

Порівнюйте не окремий скриншот, а систему: типографіку, відступи, сітку, кольори, стани кнопок, поля, помилки, модальні вікна, таблиці й довгий контент. Макет із коротким заголовком може виглядати добре, а реальна назва послуги — ламати картку.

Під час перевірки UI/UX-дизайну зверніть увагу на:

• видимість головної дії без здогадок;
• контраст тексту й інтерактивних елементів;
• однакові компоненти на різних сторінках;
• стани hover, focus, active, disabled, loading і error;
• читабельність повідомлень про помилки;
• поведінку довгих слів, цін, таблиць і перекладів;
• відсутність стрибків макета після завантаження шрифтів та зображень.

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

Крок 6. Перевірте мобільну версію та браузери

Режим пристрою в браузері корисний, але фінальну перевірку проведіть хоча б на реальному iPhone та Android. Перевірте сучасні версії Chrome, Safari, Firefox і Edge відповідно до погодженої матриці підтримки.

На мобільному окремо протестуйте:

• відкриття й закриття меню;
• фіксовані панелі та cookie-банер;
• натискання кнопок без перекриття;
• поля з правильною клавіатурою для телефону, email і числа;
• масштабування, поворот екрана та safe area;
• таблиці, слайдери, карти й відео;
• завантаження файлів із камери або сховища;
• дзвінок, email, месенджери та маршрути;
• оформлення замовлення однією рукою.

Горизонтальний скрол на одному блоці часто вказує на широку таблицю, довге слово, фіксовану ширину або сторонній віджет. Зафіксуйте конкретну сторінку й ширину екрана.

Крок 7. Перевірте форми, заявки та CRM

Фраза «форма показала повідомлення “Дякуємо”» ще не доводить, що бізнес отримав заявку. Створіть окремі тестові звернення в кожній формі та простежте весь шлях.

Для кожної форми перевірте:

1. обов’язкові й необов’язкові поля;
2. формат телефону та email;
3. зрозумілі повідомлення про помилки;
4. захист від повторного надсилання;
5. згоду з політикою конфіденційності;
6. доставку на правильну пошту;
7. створення ліда в CRM;
8. передачу джерела, UTM, сторінки входу й назви форми;
9. призначення відповідального;
10. автоматичну відповідь користувачу, якщо вона передбачена.

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

Якщо заявка приходить лише в Telegram або на особисту пошту розробника, процес не можна вважати переданим бізнесу.

Крок 8. Перевірте контент і локалізації

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

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

Контрольний список контенту:

• факти, ціни й умови актуальні;
• однакові назви послуг використовуються послідовно;
• немає орфографічних помилок і подвійних пробілів;
• зображення мають доречні alt-описи;
• у файлів зрозумілі назви;
• дати й валюта локалізовані;
• юридичні тексти погоджені відповідальним фахівцем;
• авторські права на тексти, фото, шрифти й відео врегульовані.

Крок 9. Перевірте базове SEO до відкриття індексації

SEO-помилки під час запуску можуть не бути помітними відвідувачу, але завадять пошуку правильно обходити й розуміти сайт. Для кожної індексованої сторінки перевірте унікальні Title, Description, H1, зрозумілу URL, canonical і статус 200.

Також перевірте:

• robots.txt не блокує важливі розділи;
• XML sitemap містить лише канонічні індексовані URL;
• staging і параметричні дублікати закриті;
• редиректи зі старих URL ведуть без ланцюжків;
• hreflang взаємний і використовує правильні мовні URL;
• структуровані дані відповідають видимому контенту;
• немає внутрішніх посилань на 404, 5xx або зайві редиректи;
• фільтри й пошук не створюють неконтрольовану індексацію;
• сторінки доступні без виконання дій, яких робот не може пройти.

Якщо старий сайт уже мав органічний трафік, карта редиректів і збереження важливих URL повинні бути частиною SEO-просування, а не післярелізним експериментом.

Крок 10. Перевірте швидкість і стабільність

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

Оцініть:

• час відповіді сервера;
• появу основного контенту;
• стабільність макета;
• реакцію на натискання;
• вагу зображень і відео;
• повторне завантаження з кешем;
• поведінку під кількома паралельними діями;
• помилки в консолі та мережевих запитах.

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

Крок 11. Перевірте безпеку й приватність

Замовнику не потрібно самостійно проводити повний тест на проникнення, але базові ризики мають бути закриті до запуску.

Переконайтеся, що:

• усі сторінки працюють через HTTPS;
• адмінські облікові записи персональні;
• немає стандартних або переданих у чаті паролів;
• ролі мають мінімально потрібні права;
• резервні копії створюються й відновлення перевірене;
• службові файли, журнали й дампи не доступні публічно;
• форми мають серверну валідацію й захист від спаму;
• секрети та API-ключі не виведені у frontend-код;
• залежності не мають відомих критичних проблем;
• політика конфіденційності описує фактичний збір даних;
• cookie-механізм відповідає погодженій моделі згоди.

Не надсилайте остаточні паролі одним листом. Передавайте доступи через менеджер паролів, а після завершення змініть тимчасові секрети.

Крок 12. Перевірте аналітику й конверсії

Аналітика, встановлена «десь у коді», ще не є робочою. Відкрийте сайт у режимі налагодження або реального часу та виконайте ключові дії.

Перевірте:

• правильний контейнер і ресурс;
• відсутність подвійного перегляду сторінки;
• події форм, дзвінків, месенджерів, покупок і оплат;
• коректні назви, параметри, валюти й суми;
• передачу UTM та джерела в CRM;
• виключення внутрішнього й тестового трафіку, якщо погоджено;
• поведінку до та після вибору cookie-згоди;
• конверсії рекламних систем;
• відсутність персональних даних у URL і подіях.

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

Крок 13. Отримайте всі доступи та права власності

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

Замовник повинен контролювати:

• реєстратора домену й DNS;
• хостинг або хмарний акаунт;
• CMS і головного адміністратора;
• репозиторій коду та історію версій;
• базу даних і резервні копії;
• аналітику, Search Console і Tag Manager;
• рекламні та CRM-акаунти;
• корпоративну пошту й сервіси розсилок;
• платіжні, картографічні та інші інтеграції;
• дизайн-макети, шрифти, ліцензії й вихідні файли.

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

Крок 14. Оформіть дефекти так, щоб їх можна було виправити

Запис «форма не працює» створює зайву переписку. Якісний баг-репорт містить:

• коротку однозначну назву;
• точну URL;
• пристрій, ОС і браузер;
• передумови;
• кроки відтворення;
• очікуваний результат;
• фактичний результат;
• скриншот або коротке відео;
• час і тестові дані;
• пріоритет.

Приклад: «На iPhone 15, Safari, після надсилання форми на сторінці /contact/ з валідним номером з’являється нескінченний loader; лист і лід у CRM не створюються». Це значно корисніше за «на телефоні щось зависає».

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

Крок 15. Проведіть повторну перевірку після перенесення

Після виправлень протестуйте не лише конкретний пункт, а й суміжні сценарії. Зміна валідації форми може вплинути на CRM; редирект — на локалізації; оптимізація скриптів — на оплату.

Після публікації на бойовому домені повторіть короткий smoke test:

1. головна й ключові посадкові відкриваються;
2. HTTPS і редиректи правильні;
3. меню й основні кнопки працюють;
4. тестова заявка доходить до менеджера;
5. оплата проходить у потрібному режимі;
6. аналітика бачить подію;
7. production доступний для індексації;
8. sitemap і robots відкриваються;
9. резервна копія після запуску створена;
10. моніторинг доступності активний.

У перші 72 години контролюйте 404, 5xx, помилки JavaScript, доставку листів, заявки, платежі, навантаження й індексацію. Заздалегідь визначте канал для критичних інцидентів.

Готовий чекліст замовника

Документи й обсяг

• Функції та сторінки звірено з договором і ТЗ.
• Усі зміни після старту зафіксовані.
• Відомі критерії приймання та гарантійний строк.
• Дефекти розподілені за пріоритетами.

Функції та контент

• Критичні сценарії пройдені від початку до кінця.
• Форми, листи, CRM і повідомлення перевірені.
• Телефони, ціни, реквізити й тексти актуальні.
• Немає тестового контенту та битих посилань.
• 404 повертає правильний код.

Адаптивність і якість

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

SEO, аналітика й безпека

• Title, H1, canonical, robots і sitemap коректні.
• Редиректи зі старих URL перевірені.
• Події й конверсії доходять до аналітики.
• Production відкритий, staging закритий від індексації.
• HTTPS, ролі, резервні копії й форми перевірені.

Передача

• Компанія контролює домен, хостинг і CMS.
• Передані код, база, макети, ліцензії та інструкції.
• Тимчасові паролі змінені.
• Узгоджені підтримка, SLA й канал аварійного зв’язку.
• Проведений повторний тест на бойовому домені.

Як прийняти рішення про фінальну оплату

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

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

Висновок

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

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