# Журнал спостереження за SEO-релізом

MAX SITE · 10.09.2026 · робочий шаблон для відповідального за реліз.

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

## До зміни

1. [ ] Записати задачу, причину, дозволений обсяг, цільові URL, відповідального й точний попередній реліз: ___.
2. [ ] Зберегти GSC-baseline: ресурс, дати, Web/Image тощо, країна, пристрій, зерно даних і дату експорту.
3. [ ] Окремо зафіксувати доступні GA4/CRM-дані й визначення конверсії. Відсутність доступу позначити UNKNOWN, не нулем.
4. [ ] Записати поточні canonical, indexability, sitemap, HTTP-статуси й істотні Title/H1 для змінюваних URL.
5. [ ] Зберегти desktop/mobile знімки з розмірами viewport, середовищем і датою; локальну збірку не називати live.
6. [ ] Узгодити попередню працездатну версію, умови rollback і дозволений спосіб публікації.

## Приймання коду й публікація

7. [ ] Записати diff, коміт/PR та перевірки з фактичними результатами. Не замінювати падіння тесту його вимкненням.
8. [ ] Перевірити кількість H1, метадані, canonical, schema, внутрішні посилання й правила індексації.
9. [ ] Перевірити мобільні заголовки, меню, consent, контактну панель, форму та прокручування; врахувати fallback-шрифти.
10. [ ] Перевірити оновлення CSS/JS і ключ кешу: HTML має посилатися на актуальні байти, а не лише стару дату у query.
11. [ ] Перевірити зображення, розміри, srcset, alt і пріоритет завантаження без підміни всіх ресурсів одним файлом.
12. [ ] Звірити delivery-сценарії окремо від аналітики: успіх, відмова, тайм-аут, повтор і резервний контакт.
13. [ ] Отримати дозволений go/no-go; записати точний коміт, який буде опублікований, а не тільки назву гілки.
14. [ ] Після деплою перевірити live-ідентифікатор релізу або інший надійний доказ актуальної версії; врахувати кеш.
15. [ ] Перевірити із зовнішньої мережі HTTPS, важливі URL, ресурси, canonical, robots/sitemap та контрольну відсутню сторінку.
16. [ ] Окремо записати, що не деплоїлося: Worker/API, DNS, GA4/Ads або інші зовнішні системи. Успіх статичного workflow їх не підтверджує.

## Спостереження після релізу

17. [ ] Зафіксувати дату релізу в журналі або дозволеній анотації; перелічити одночасні зміни реклами, контенту чи трекінгу.
18. [ ] Запланувати контрольні точки з конкретним власником: одразу, день 2, 7, 14 і 30; майбутні перевірки не позначати виконаними.
19. [ ] На кожній точці перевірити доступність, помилки обходу, coverage й отримані звернення в межах наявних доступів.
20. [ ] Для порівняння вибрати зіставний період і ті самі фільтри. Перекривні 28-денні вікна не називати незалежним результатом «до / після».
21. [ ] Розділити лабораторні виміри, польові CWV, GSC і бізнес-конверсії; для кожного вказати доступність та затримку даних.
22. [ ] Записати висновок із невизначеністю, наступну дію та критерії rollback. Короткий рух середньої позиції сам по собі не доводить вплив однієї правки.

## Таблиця спостережень

| Дата / точка | Реліз | Метод і фільтри | Фактичне спостереження | Доказ | Обмеження | Дія / власник |
|---|---|---|---|---|---|---|
| До | ___ | ___ | ___ | ___ | ___ | ___ |
| Одразу | ___ | ___ | ___ | ___ | ___ | ___ |
| День 2 | ___ | ___ | ___ | ___ | ___ | ___ |
| День 7 | ___ | ___ | ___ | ___ | ___ | ___ |
| День 14 | ___ | ___ | ___ | ___ | ___ | ___ |
| День 30 | ___ | ___ | ___ | ___ | ___ | ___ |

Контекст: [вихідний GSC-зріз MAX SITE](https://maxsite.com.ua/portfolio/max-site/#gsc-baseline) · [публічний QA-чекліст](https://maxsite.com.ua/qa-checklist/).