Стаття · 5 хвилин

Search Clues: з чого почати, коли впав органічний трафік

Мій спосіб швидко розібратися з падінням органічного трафіку: порівняти дані Search Console, підтверджені оновлення Google і зміни сайту, не передаючи файли на сервер.

Ноутбук зі справжньою сторінкою Search Clues: завантаження ZIP із Search Console та список підтверджених оновлень Google.

Уявімо: клієнт надсилає скриншот із Search Console і питає: «Органічний трафік упав. Що сталося?» Те саме запитання виникає і щодо власного сайту. Падіння видно. Причину ще треба з’ясувати.

Починаю з двох запитань: що ми змінювали на сайті? І чи було в цей час підтверджене оновлення Google? Конкуренти теж могли попрацювати краще, але це окремий аналіз. Сезонність, зміна попиту або збої у звітності також можливі.

Для цієї швидкої перевірки я зробив Search Clues. Він показує на одній часовій шкалі щоденні дані Google Search Console, підтверджені оновлення Google і, за бажанням, злиті PR з GitHub. Так легше побачити збіги в часі та вирішити, що перевіряти далі.

Початковий екран Search Clues із кнопкою вибору ZIP та переліком оновлень Google.
Список підтверджених оновлень доступний ще до імпорту ZIP.

Чому файли залишаються у вашому браузері

Для першої перевірки не треба завантажувати клієнтський експорт Search Console в сторонній сервіс. GitHub JSON теж може містити назви PR і шляхи до файлів.

Search Clues читає ZIP і JSON у браузері та не надсилає їх на сервери M09. Реєстрація не потрібна. Незбережений аналіз зникне після закриття вкладки. Якщо зберегти сайт, його дані та історія імпорту залишаться в IndexedDB цього профілю браузера. Там можна тримати кілька сайтів і повертатися до них пізніше. За бажанням перевірте JavaScript, який завантажує браузер, і запити на вкладці Network в інструментах розробника. Сама сторінка завантажується з мережі, але ваші файли аналізу залишаються на пристрої.

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

Спершу потрібен оригінальний ZIP із Search Console

Відкрийте потрібний ресурс у Google Search Console та перейдіть до Ефективність > Результати пошуку. Виберіть останні 16 місяців і тип пошуку Веб. Вимкніть Порівняння. Якщо аналізуєте весь сайт, приберіть фільтри сторінок, запитів, країн, пристроїв і вигляду результатів пошуку. Потім натисніть Експорт > Завантажити CSV. Цей експорт описано в довідці Google.

Search Console завантажить ZIP. Не розпаковуйте й не перейменовуйте його: назва допомагає перевірити ресурс. Відкрийте файл через Вибрати ZIP у Search Clues. Для графіка інструмент бере щоденні підсумки й перевіряє метадані, щоб не змішати вибірки з різними фільтрами. Якщо ресурс не вдалося визначити за назвою ZIP або даними експорту, інструмент попросить підтвердження. Це зменшує ризик переплутати сайти, але не доводить справжність файлу.

Шістнадцять місяців дають змогу порівняти новіші дані з тим самим періодом торік. Один ZIP охоплює лише вибраний період. Якщо час від часу додавати сумісні ZIP для того самого сайту, Search Clues збереже старі дати локально, а дати, що перекриваються, оновить свіжішим експортом. Режим Увесь час покаже всю накопичену історію, навіть якщо вона довша за один файл.

Спочатку з’ясуйте, що саме змінилося

Після імпорту подивіться на кліки й покази окремо. Впали обидва показники чи лише кліки? Коли почалося падіння і скільки воно тривало? Чи повні дані за останні дні? Порівняйте останні повні 28 днів із попередніми 28 днями й тим самим періодом торік.

Інструмент позначає на графіку стійкі зміни трафіку й підтверджені оновлення Google. Він також шукає схожий спад у той самий сезон торік. Це лише підказки: одного року замало, щоб довести сезонність, а збіг з оновленням Google не доводить його впливу на ваш сайт.

Графік Search Clues із падінням трафіку на 38%, оновленнями Google та датами злиття PR.
Тестові дані: падіння, оновлення Google і дати злиття PR на одному графіку.

Дані GitHub потрібні не завжди

Якщо зміни сайту проходять через GitHub, можна додати злиті PR. Встановіть GitHub CLI, увійдіть в обліковий запис і виконайте команду в терміналі. Замініть OWNER/REPOSITORY в обох місцях, а замість YYYY-MM-DD введіть дату не пізніше початку вашого періоду Search Console. Команда визначить основну гілку й створить на комп’ютері файл website-changes.json.

gh auth login

gh pr list \
  --repo OWNER/REPOSITORY \
  --base "$(gh repo view OWNER/REPOSITORY --json defaultBranchRef --jq '.defaultBranchRef.name')" \
  --state merged \
  --search "merged:>=YYYY-MM-DD" \
  --limit 1000 \
  --json number,title,mergedAt,url,labels,additions,deletions,changedFiles,files,mergeCommit,baseRefName \
  > website-changes.json

Відкрийте JSON у Search Clues через Вибрати JSON. Команда читає метадані PR і не запускає GitHub Actions.

--limit 1000 запитує до 1000 PR. Пошук GitHub не повертає понад 1000 результатів за один запит; у Search Clues такого обмеження немає. Якщо у файлі рівно 1000 PR, частина могла не потрапити до нього. Розбийте період на діапазони дат без перекриття, наприклад merged:YYYY-MM-DD..YYYY-MM-DD, і створіть окремий файл для кожного. Імпортуйте файли по черзі: Search Clues об’єднає PR і не дублюватиме повтори.

Сині позначки показують дати злиття PR, а не релізів. Код міг з’явитися на сайті пізніше або взагалі не вийти. Сайт також можна змінити без PR. Це підказка, які релізи перевірити, але самої дати злиття замало, щоб назвати причину падіння.

Що показує приклад

На скриншотах Search Clues оцінює початок зміни приблизно 17 липня 2026 року та спад на 38%. У тестових даних кліки трохи знизилися 18 липня, а різко впали 20 липня. PR про canonical і robots злили 18 липня. У списку підтверджених оновлень Google інструмент не знаходить події на ці дати.

Це ще не означає, що PR спричинив падіння. Дата на графіку - оцінка алгоритму, а злиття PR не означає, що код уже працював на сайті. Я б спершу з’ясував, коли вийшов реліз, а потім порівняв постраждалі сторінки й запити та перевірив індексацію. Навіть збіг із оновленням Google не скасував би цих перевірок.

Висновок Search Clues із близьким за датою PR та порадою перевірити дату релізу.
Тестові дані. Наступний крок - з'ясувати дату релізу.

Історія залишиться для наступного аналізу

Збережіть аналіз під назвою сайту. Потім можна додати інший сайт, перемикатися між ними й час від часу імпортувати нові сумісні ZIP. Так у браузері накопичиться історія кожного сайту. Журнал імпорту покаже, які файли й дати вже додано. Якщо історія важлива, зробіть резервну копію. Вона не зашифрована.

Для мене це спосіб швидко зібрати факти перед розслідуванням: коли змінився трафік, які події були поруч і що перевірити спочатку. Збіг дат - початок перевірки, а не висновок.

Відкрийте Search Clues і спробуйте його зі своїм ZIP із Search Console. Файл залишиться на вашому пристрої.