Монітори позицій Google налаштовують майже завжди однаково: задають поріг, спрацьовують на відхилення більше за нього — і на цьому все. Типове значення за замовчуванням у більшості інструментів — близько 3 позицій, бо трійка звучить як значуща зміна.
У наших даних це не так. Із 106 запитів, що набрали щонайменше 30 показів за 90 днів, медіанне стандартне відхилення денної позиції за запитом становило 7.45. Для типового запиту зсув на три позиції — не сигнал, а звичайна поведінка цього числа.
Монітор не зламаний — він не відкалібрований. Ось як він виглядає, коли налаштований за вашою власною історією, а не за типовими значеннями.
Що припускає монітор і які припущення не витримують
За кожним правилом оповіщення стоять чотири припущення, і правильне лише одне.
Позиції достатньо стабільні, щоб поріг працював. Хибне. Розкид відрізняється між запитами на порядок; ми виміряли це нижче.
Однакове за величиною зрушення означає те саме на будь-якій позиції. Хибне. Відстань між 3-м і 6-м місцем не еквівалентна відстані між 41-м і 44-м — ні за кліками, ні за змістом.
Кожен запит заслуговує на той самий поріг. Хибне. Брендові запити й конкурентні високочастотники статистично не мають нічого спільного.
Чим частіше перевіряєш, тим кращі дані. Після певної межі хибне. Щоденна перевірка дає в сім разів більше вимірювань, ніж щотижнева, а на більшості наборів запитів — у сім разів більше шуму навколо того самого сигналу.
Решта статті замінює кожне з цих чотирьох припущень вимірюванням.
Як насправді поводяться наші запити
Метод: наш власний ресурс Search Console, 90 днів, що закінчуються 12 вересня 2026 року, виміри query і date, 8 020 рядків, відфільтрованих до 106 запитів із щонайменше 30 показами за період. Для кожного запиту ми порахували стандартне відхилення середньої денної позиції та частку днів, коли він залишався в межах трьох позицій від власної медіани.
Показник | Значення |
|---|---|
Запитів у вибірці | 106 |
Медіана стандартного відхилення денної позиції | 7.45 позиції |
Запити зі стандартним відхиленням менше 2 позицій | 12 із 106 (11%) |
Запити зі стандартним відхиленням 10 і більше | 40 із 106 (38%) |
Медіанна частка днів у межах 3 позицій від власної медіани запиту | 59% |
Візьмімо чотири запити з тієї самої вибірки — на тому самому сайті різниця в поведінці така.
Запит | Медіана позиції | Стандартне відхилення | Днів у межах 3 від медіани |
|---|---|---|---|
amazon echo keywords | 14.1 | 1.29 | 100% |
on page seo audit | 92.2 | 4.99 | 63% |
perplexity seo checker | 31.9 | 12.87 | 22% |
geo | 70.4 | 9.83 | 30% |
Практичний висновок: запитів, достатньо стабільних для того, щоб фіксоване правило трьох позицій мало сенс, — приблизно один із десяти. Чотири з десяти рухаються так сильно, що за будь-якого порогу менше 10 позицій оповіщення спрацьовуватиме без упину.
Більшість запитів рухається значно сильніше, ніж припускає типовий поріг оповіщення.
Правило калібрування 1: будуйте діапазони за запитом, а не за сайтом
Поріг на рівні сайту — це середнє з не схожих між собою моделей поведінки. Рішення полягає в тому, щоб діапазон кожного запиту обчислювався з його власної історії; для цього потрібні один експорт Search Console і кілька рядків арифметики.
Для кожного запиту використовуйте його власний розподіл, а не глобальне число.
- Normal: у межах одного стандартного відхилення від медіани самого запиту.
- Watch: між одним і двома стандартними відхиленнями або коли запит виходить за власний центральний діапазон у 80%.
- Investigate: понад два стандартні відхилення і підтвердження на другому послідовному запуску.
На вибірці вище це радикально змінює обсяг оповіщень. Запиту зі стандартним відхиленням 1.29 потрібен рух приблизно на 3 позиції, щоб дійти до діапазону спостереження. Запиту з відхиленням 12.87 потрібно близько 13, тож оповіщення майже не з'явиться, доки не станеться щось реальне.
Це та сама логіка, яку посібник із проєктування діапазонів оповіщень використовує для регулярного моніторингу, застосована на рівні запиту, а не акаунта. І якщо після цієї статті ви зміните лише одне, зробіть поріг значенням для кожного запиту, а не константою.
Правило калібрування 2: задайте мінімальний поріг показів
Позиція — це середнє, а середнє з трьох показів не є вимірюванням. Нижче приблизно 30 показів за період базова вибірка настільки мала, що число рухається саме по собі.
Звідси випливають два висновки, і обидва прості в реалізації.
Не оповіщайте про запити з низькими показами. Спостерігайте за ними, але ставтеся до позиції як до контексту, а не як до сигналу. Виняток — запит, що раптово набирає обсяг: це подія за показами, і про неї варто знати окремо.
Супроводжуйте кожну позицію показами. Падіння на 5 позицій за стабільних показів означає не те саме, що падіння на 5 позицій із втратою 60% показів. Друге ближче до проблеми індексації чи відповідності, перше — ближче до конкуренції. Монітор, який повідомляє лише позицію, відкидає цю різницю, і це саме той сценарій відмови, який покликаний ловити цей порядок розбору.
Правило калібрування 3: розділяйте пристрій і регіон до оповіщення
Зведена позиція — це зважене середнє результатів за пристроями та регіонами. Коли змінюються ваги, середнє зсувається, хоча зі сторінкою нічого не сталося. Ми виміряли розрив між мобільними й десктопом за одним і тим самим запитом до 11 позицій, тож це не похибка округлення — це той самий порядок, що й шум, який ви намагаєтеся виявити.
Реалізація непоказна й дешева: витягуйте позиції окремо за пристроями, зберігайте обидві, оповіщайте на тому пристрої, де стався рух. А якщо стежите за одним зведеним числом, виводьте частки пристроїв у звіт, щоб зміна складу була видимою, а не вгаданою. Про форму запиту — у розборі розділення за пристроями.
П'ять стовпців перетворюють оповіщення на розслідування, у якого є відправна точка.
Що відстежувати, крім позиції
Позиція — це лише один стовпець. Решта чотири вирішують, чи вартий рух людської уваги.
Покази. Бік попиту. Коли рухається це, змінюється зміст усіх чисел позицій.
Стан функцій SERP. Чи є в цьому запиті AI Overview, блок відео, локальний пакет. Зміна функції зсуває позицію без жодних змін на сторінці.
Місце на кривій кліків. Не лише те, де ви в списку, а й те, де ви щодо функцій. Перше місце під AI Overview — не перше місце. А якщо хочете відстежувати стан функцій як слід, які поля зберігати, розібрано в побудові трекера AI Overview.
Журнал змін. Ваші деплої, зміни шаблонів і правки контенту на одній часовій шкалі. За більшістю реальних падінь, які ми розбирали, стояв коміт.
Зберігайте ці п'ять за кожним запитом і кожним днем — і оповіщення стане розслідуванням із відправною точкою, а не лячним числом і людиною, якій треба відтворити той тиждень із пам'яті.
Порахуйте частоту, перш ніж брати зобов'язання
Вартість моніторингу зростає як кількість ключових слів, помножена на кількість перевірок, тож частоту визначає кількість запитів, а не ентузіазм.
- Щоденна перевірка 30 важливих запитів — це 900 запитів на місяць. Це витримає майже будь-який тариф, і більшості команд варто починати саме звідси.
- Щоденна перевірка 200 запитів — це 6 000 запитів на місяць, і на волатильних наборах вона породжує більшість оповіщень із шуму.
- Ті самі 200 запитів щотижня — це близько 1 400 запитів на місяць, і вона ловить більшість реальних рухів, бо справжня зміна триває довше за тиждень.
Якщо потрібне і те, і те, діліть не за вподобанням, а за розміром ставки: короткий список, зав'язаний на дохід, — щодня, решта — щотижня. А якщо збираєте дані самі, трекер на двох джерелах розбирає форму запитів і правила порівняння.
Чек-ліст, перш ніж довіряти будь-якому монітору
П'ять питань. Монітор, що провалює будь-яке з них, забирає більше уваги, ніж заощаджує.
- Чи зберігає він сирі результати, чи лише обчислену позицію? Якщо згодом ви не можете запитати, що ще було на сторінці, ви не поясните оповіщення.
- Чи зафіксовані й записані регіон і пристрій для кожного запиту? Інакше історія змішує різні умови.
- Поріг задано для кожного запиту чи це одне число на весь акаунт? Одне число — це типове значення, а не калібрування.
- Чи розрізняє він збій і падіння? Google публікує панель стану з історією збоїв, і поглянути туди першою дешевше за будь-яке розслідування.
- Він каже, що змінилося, чи лише що щось змінилося? Оповіщення другого типу — це список завдань; перше — це судження.
Погляд Auspia: монітор позицій коштує рівно стільки, скільки коштує його калібрування. Типовий поріг у три позиції хибний не тому, що інструменти ліниві, а тому що це середнє по генеральній сукупності, застосоване до окремих запитів. Виміряйте власні запити й задайте діапазони з їхніх розподілів — і з оповіщень залишаться ті, за якими ви справді діятимете.
Часті питання
Яке нормальне коливання позицій монітор Google має ігнорувати? Універсального числа немає, і в цьому суть. У нашій вибірці медіанний запит зсунувся на 7.45 позиції за 90 днів, а один із десяти залишався в межах двох позицій. Правильний поріг виводиться з історії кожного запиту й зазвичай дорівнює одному стандартному відхиленню.
Як часто монітор має перевіряти позиції? Звичайні набори — щотижня, короткі списки, зав'язані на дохід, — щодня. Щоденна перевірка великого набору подвоює витрати й ловить переважно шум, бо реальна зміна позицій триває довше за добу.
Чому монітор показує денні коливання, яких немає в Search Console? Бо це два різні вимірювання. Монітор робить один знімок реальної сторінки результатів у конкретний момент і в конкретному регіоні. Search Console усереднює покази за діапазоном дат і складом пристроїв. Жоден із них не помиляється, а пряме порівняння змусить вас ганятися за падінням, яке існує лише з одного боку.
Чи варто відстежувати кожне слово, що має позицію? Ні. Відстежуйте запити, у яких достатньо показів для вимірювання. У наших даних це були 106 із тисяч. Ті, що нижче порогу показів, краще відстежувати групою, наприклад рахуючи, скільки запитів узагалі ранжуються, а не оповіщати про кожен окремо.
Чи потрібен платний інструмент для калібрування монітора? Ні. Одного експорту Search Console з вимірами query і date достатньо, щоб порахувати медіану й стандартне відхилення для кожного запиту, і калібруванню більше нічого не потрібно. Платні інструменти додають зручність і дані від різних постачальників, а не статистику.
Автор: Miles Carter, аналіз даних про позиції 8 000 запитів в Auspia. Пише про вимірювання позицій, калібрування оповіщень і про те, як відрізнити зміну в даних від зміни в результатах пошуку.
