# Карта пошукового наміру та основного URL

MAX SITE · 10.09.2026 · шаблон рішення, не автоматична команда видалення сторінок.

«Один основний URL» означає узгоджену ціль для конкретного наміру. Це не обіцянка, що Google завжди показуватиме тільки її. Кілька URL за запитом — сигнал для аналізу, не доказ штрафу.

## Вихідні дані

1. [ ] Записати ресурс GSC, дату експорту, власника даних і доступні виміри: ___.
2. [ ] Зафіксувати базовий період із точними датами, тип пошуку, країну й пристрій. Не змінювати фільтри непомітно.
3. [ ] Перевірити повноту пагінації та унікальність рядків для обраної деталізації.
4. [ ] Розділити підсумки ресурсу, сторінок і query-page. Не називати суму показів сторінок загальними показами ресурсу.
5. [ ] Уточнити одиниці CTR. Для підсумку обчислити кліки ÷ покази × 100, а не середнє відсотків рядків.
6. [ ] Зафіксувати відсутні дані: приховані запити, GA4, ліди або backlinks. Невідоме не записувати нулем.

## Сформувати власника наміру

7. [ ] Відібрати реальні запити й описати задачу відвідувача: замовити послугу, дізнатися ціну, порівняти або отримати інструкцію.
8. [ ] Відокремити бренд, національний, міський, нішевий та інформаційний контекст.
9. [ ] Згрупувати близькі формулювання за наміром, а не лише за спільним словом.
10. [ ] Перелічити всі URL, які вже отримують покази в групі, їх title/H1, canonical, indexability і поточні внутрішні посилання.
11. [ ] Визначити основний URL, який реально відповідає задачі; записати підставу, не лише бажання підняти позицію.
12. [ ] Для кожної суміжної сторінки зафіксувати відмінну роль. Стаття може пояснювати вибір, а сторінка послуги — приймати заявку.
13. [ ] Перевірити реальну змістову відповідь, CTA, докази й доступні конверсії; не обирати сторінку лише за довжиною тексту.
14. [ ] Запланувати контекстні входи з релевантних сторінок і пояснювальний анкор. Не повторювати один exact-match анкор у всій навігації.

## Рішення й контроль

15. [ ] Обрати мінімальну зміну: уточнити текст/намір, змінити посилання, доповнити доказ або залишити без змін.
16. [ ] Перед merge/301/noindex/410 окремо перевірити ліди, backlinks, доступний період GSC й цінність сторінки. Сам збіг ключового слова не є підставою.
17. [ ] Якщо потрібне об’єднання, погодити релевантний кінцевий URL, внутрішні посилання й тест без ланцюжка редиректів.
18. [ ] До публікації записати очікуваний вимірюваний сигнал і критерій невдачі, без гарантованої позиції.
19. [ ] Записати дату релізу й усі супутні зміни реклами, трекінгу або контенту.
20. [ ] Після накопичення даних повторити такий самий зріз. Періоди, що майже повністю перекриваються, не називати «до / після».
21. [ ] Оцінити покази, кліки, CTR і основні URL групи разом; середня позиція сайту не є місцем за одним ключем.
22. [ ] Зафіксувати висновок, обмеження даних, наступну дію й відповідального. Відсутність швидкого росту не виправдовує хаотичне видалення URL.

## Робоча карта

| Кластер / намір | Запити з джерела | Основний URL | Суміжні URL та їх роль | Baseline / період | Дія й підстава | Власник / дата перевірки |
|---|---|---|---|---|---|---|
| ___ | ___ | ___ | ___ | ___ | ___ | ___ |

Приклад чесного baseline: [відкритий кейс MAX SITE](https://maxsite.com.ua/portfolio/max-site/#gsc-baseline). Контроль реалізації: [технічне SEO](https://maxsite.com.ua/tehnichne-seo/).