Перевірка сайту перед запуском: практичний QA-чекліст

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

Нижче — практичний список для WordPress і Bricks. Його слід адаптувати до функцій проєкту. Інтернет-магазин додатково потребує тестів оплати, доставки, податків і листів замовлення.

1. Зафіксуйте стан перед змінами

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

На live-сайті резервна копія — не формальність. Вона повинна бути створена до редиректів, масового імпорту або зміни шаблонів.

2. Перевірте контент і структуру

Пройдіть меню, футер, кнопки, хлібні крихти й внутрішні посилання. Переконайтеся, що немає стандартних сторінок WordPress, тестових записів, lorem ipsum, порожніх блоків і непідтверджених контактів. Назви компанії та послуг повинні бути послідовними.

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

3. Адаптивність на ключових ширинах

Перевірка лише в режимі «мобільний телефон» недостатня. Пройдіть щонайменше 1440, 1024, 768, 390 і 360 пікселів. Звертайте увагу на горизонтальне переповнення, довгі слова, таблиці, відступи, липкі елементи й висоту першого екрану.

Меню повинно відкриватися з клавіатури, закриватися Escape і правильно повертати фокус. Кнопки не мають бути надто близькими, а форми — виходити за межі екрана.

4. Повний тест форм

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

Переконайтеся, що подія аналітики спрацьовує після успішної відповіді сервера, а не після простого натискання кнопки. Не передавайте у GA4 і GTM ім’я, телефон, email або текст повідомлення.

5. Технічне SEO

• Title і Description унікальні та не дублюються у коді;
• canonical вказує на поточний live URL;
• сторінки мають правильний robots index/follow;
• robots.txt доступний і містить sitemap;
• sitemap містить лише канонічні опубліковані URL;
• старі адреси мають точкові 301-редиректи;
• 404 повертає код 404, а не 200;
• schema відповідає видимому контенту і проходить валідацію.

Після запуску додайте sitemap у Search Console і Bing Webmaster Tools. Запитуйте індексацію лише для пріоритетних сторінок; багато повторних запитів не прискорюють обхід.

6. Швидкість і Core Web Vitals

Перевірте найбільший елемент першого екрану, завантаження локальних шрифтів, розміри зображень і сторонні скрипти. Головне зображення не повинно мати lazy loading, якщо воно є кандидатом LCP. Для медіа нижче першого екрану lazy loading доречний.

• використовуйте WebP або AVIF із резервним форматом;
• вказуйте width і height для зображень;
• не завантажуйте непотрібні бібліотеки на всіх сторінках;
• перевірте консоль на JavaScript-помилки;
• оцінюйте як лабораторні дані, так і польові дані після накопичення трафіку.

7. Доступність

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

Автоматичний аудит знаходить лише частину проблем. Додайте ручну перевірку меню, акордеонів, модальних вікон і форм.

8. Безпека та доступи

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

9. Аналітика й пошукові кабінети

Перевірте один спосіб встановлення GA4, щоб не було дублювання. У GTM опублікуйте конкретну версію та дайте їй зрозумілу назву. У Realtime перевірте page_view і тестову подію без персональних даних. Зв’яжіть GA4 із Search Console після підтвердження ресурсу.

10. Перевірка після публікації

Повторіть критичні сценарії вже на публічному домені: головна, послуги, блог, контакти, форми, 404 і редиректи. Перевірте HTTP-коди, canonical, sitemap та robots ззовні. Зафіксуйте час запуску, внесені зміни й питання, які залежать від власника.

Мінімальний протокол приймання

1. Критичні сторінки повертають 200.
2. Форми доставляють звернення й показують підтвердження.
3. Немає горизонтального переповнення на погоджених ширинах.
4. У консолі немає нових критичних помилок.
5. Метадані, canonical і schema не дублюються.
6. Аналітика отримує події без персональних даних.
7. Резервна копія та доступи передані власнику.

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