Почати з якості вимірювання
У вересні 2026 ми в BUKI звіряли GSC, SE Ranking і трекінг на основі API HasData. GSC допомагала в поточному аналізі, у SE Ranking ми мали історичний пул із 200–300 пріоритетних запитів, а власний трекінг давав розподіл за категоріями й містами.
Коли змінився формат отриманих результатів, частина даних стала некоректною. Перша задача в такій ситуації — зрозуміти, чи справді змінився сайт у пошуку, чи зламався спосіб спостереження. Зниклий результат парсера не потрібно автоматично перетворювати на втрату позиції.
Що відбувалося зі збором позицій
Наприкінці серпня та у вересні ми зіткнулися з проблемами збору позицій. 30 вересня я підсумував послідовність подій. Приблизні частки некоректних даних стосуються нашої перевірки; вони не описують якість сервісів на всьому ринку.
Послідовність подій зібрав у журналі нижче. Якби порівнював сервіси між собою, перевіряв би той самий набір запитів за однакових умов.
Чому GSC і ручна перевірка можуть не збігатися
Середня позиція Search Console — агрегований показник фактичних показів за обраний зріз. Вона не є одним щоденним знімком видачі. Для порівняння я звіряю запит, сторінку, країну, пристрій, період і тип пошуку. Навіть після цього відмінності способів вимірювання залишаються.
Ручна перевірка допомагає розібрати конкретний приклад, але теж не відтворює досвід усіх користувачів. Для такої перевірки я б записував час, місце, мову та пристрій. Якщо сервіс зберігає HTML чи знімок видачі, звірив би його з отриманими значеннями. Без такого підтвердження залишив би причину розбіжності відкритим питанням.
Як ми звіряли позиції, трафік і ліди
У момент збою ми дивилися позиції в GSC, вручну перевіряли важливі запити та стежили за трафіком і виконанням плану за лідами. Головним орієнтиром для нас залишався план за лідами. Це не скасовує перевірку видимості, а допомагає розуміти наслідки для бізнесу.
Погіршення однієї метрики ще не встановлює причину. Кліки можуть змінитися через попит або вигляд видачі, сесії — через облік аналітики, заявки — через продукт, форму чи якість аудиторії. Корисніше зіставити порівнювані сегменти й перелік змін, ніж обрати один сервіс остаточною істиною.
Вести журнал інциденту й відновлення
У журналі інциденту я б зберігав дату першого сигналу, охоплення, приклади запитів і статус джерела. Окремо позначав би «результату немає», «збір не завершився» й «дані визнано некоректними», щоб прогалини не перетворювалися на вигадані значення.
Повернення відповідей від API ще не підтверджує повне відновлення якості. Перед поверненням джерела у звичайний звіт я б повторив перевірку того самого контрольного набору й зіставив збережені результати. Тривалість перевірки й розмір вибірки залежать від того, які рішення команда приймає за цими даними.
Як зіставляти сигнали
| Період | Спостереження в команді |
|---|---|
| Кінець серпня 2026 | Змінився формат посилань у отриманій видачі; тимчасові труднощі SE Ranking, HasData працював. |
| 14 вересня 2026 | За моєю оцінкою, близько 20% даних HasData були некоректними. |
| 21 вересня 2026 | За моєю оцінкою, частка некоректних даних HasData зросла приблизно до 50%. |
| 28 вересня 2026 | Ми зафіксували збій SE Ranking; кількісного охоплення тут не наводжу. |
| 30 вересня 2026 | Команда спирається на GSC, ручні перевірки важливих запитів, трафік і план за лідами. |
Це наш журнал подій. Вихідні приклади та повний обсяг перевірки тут не публікую.
| Сигнал | Що перевірити далі |
|---|---|
| Позиції трекера впали, GSC і ліди стабільні | Зіставити однакові запити й умови, перевірити отриману видачу та стан збору. Не робити висновок про SEO-втрату лише з парсера. |
| Падають і кліки GSC, і пошукові сесії | Перевірити ті самі сторінки й країни, попит, зміни видачі та релізи. Збіг підтримує факт зміни, але не пояснює її причину. |
| Трафік стабільний, лідів менше | Зіставити якість аудиторії, конверсію, форму, пропозицію та облік заявок. |
| У джерела є пропуски | Зберегти окремий статус даних. Відсутня відповідь не є встановленою останньою позицією. |
