Search Console під наглядом: як автоматично ловити просідання сторінок через Google Sheets і Telegram

Коли органічний трафік просідає, бізнес рідко дізнається про це в ту саму хвилину. Частіше сценарій інший: кілька днів падають кліки по ключовій сторінці, ще через тиждень просідають заявки, а команда помічає проблему вже тоді, коли доводиться пояснювати, чому план по лідах знову не зійшовся. Ручна перевірка Search Console тут майже завжди запізнюється, бо ніхто не відкриває звіт щогодини й не тримає в голові нормальне відхилення для кожного URL.

Саме тому сильніший підхід для SEO-команди або власника сайту виглядає інакше: не чекати, поки хтось помітить падіння, а побудувати систему раннього попередження. Search Console вже містить дані про кліки, покази, CTR і середню позицію. Google Apps Script вміє регулярно забирати ці метрики, Google Sheets зручно тримає базову історію й порівняння, а Telegram або email можуть стати останньою ланкою, яка дає короткий сигнал: тут щось пішло не так, перевір зараз, а не через п'ять днів. Для базової технічної частини вам знадобляться Search Analytics: query, UrlFetchApp і installable triggers.

Чому Search Console треба не просто читати, а моніторити

У більшості проєктів Search Console використовується як звіт після факту. Пішли кліки вниз, відкрили графік. Просів CTR, почали дивитися title і snippet. Зникли покази, згадали про технічні правки. Така логіка працює, якщо у вас мало сторінок і багато вільного часу. У всіх інших випадках вона занадто реактивна.

Проблема в тому, що органічне просідання майже ніколи не починається як драматичний обвал на всьому сайті. Частіше падає окрема категорія, один комерційний лендінг, кілька статей із гарячим сезонним попитом або група сторінок після релізу. Поки це видно лише на рівні окремих URL, втрати ще можна зловити рано. Якщо ж команда дивиться тільки на загальний графік раз на тиждень, причина вже розмазується по всьому сайту.

Тут корисно мислити не звітом, а сигналами. Для критичних сторінок вам потрібен не красивий дашборд сам по собі, а відповідь на просте питання: які URL за останні 24 години або 7 днів поводяться нетипово.

Які метрики реально варто ставити на алерт

Найпоширеніша помилка в таких системах проста: люди хапають одну метрику, наприклад позицію, і намагаються будувати всю логіку навколо неї. Це майже завжди дає шум. Середня позиція може плавати без реальної бізнес-проблеми. CTR теж може стрибати через зміну попиту, SERP-features або сезонність. Тому нормальний контроль будується як мінімум на чотирьох полях:

• clicks
• impressions
• ctr
• position

Умовно кажучи, якщо кліки впали на 35%, але покази стабільні, це один тип проблеми. Якщо разом падають і кліки, і покази, це вже інший сценарій. Якщо CTR обвалився, а позиція майже не зрушила, можливо, питання в snippet, конкурентах або зміні видачі. Саме тому Search Console добре підходить для ранніх сигналів: він показує не тільки сам факт просідання, а і його характер.

Щоб система не перетворилася на генератор фальшивої паніки, одразу відсікайте дрібні сторінки. Немає сенсу слати alert по URL, який отримує два кліки на тиждень. Для початку краще взяти whitelist критичних сторінок:

• комерційні лендінги;- категорії;
• топові статті, що реально приводять трафік;
• сезонні сторінки, де час реакції особливо важливий.

До речі, якщо у вас уже є зведена аналітика в таблицях, цей шар добре стикується з дашбордом на кшталт GA4 + Search Console у Google Sheets. Дашборд відповідає за широку картину, а alert-моніторинг ловить момент, коли на важливому URL починається злам тренду.

Як має виглядати робоча архітектура

Базова схема тут доволі приземлена:

Search Console API -> Google Apps Script -> Google Sheets -> Telegram / email

У таблиці зручно тримати не тільки сирі метрики, а й статус логіки моніторингу. Наприклад:

Така структура потрібна не “для краси”, а щоб уникнути хаосу. Якщо ви одразу не розводите baseline, поточні дані й статус алерту, через тиждень не зрозумієте, чи це нове просідання, чи старий інцидент, про який уже знають.

Для baseline немає єдиного правильного правила. На невеликому сайті можна порівнювати останні 7 днів із попередніми 7. На більш сезонних темах краще дивитися 14 або 28 днів. Суть одна: система

повинна порівнювати сторінку не з “середньою температурою по сайту”, а з її власною нормальною поведінкою.

Базова логіка в Apps Script

У Search Console API ви можете забирати дані по сторінках, а в Apps Script обробляти їх без проміжного сервера. Найпростіший сценарій такий:

1. Берете список URL із вкладки Watchlist
2. Для кожного URL робите запит у Search Console API.
3. Окремо отримуєте поточний період і baseline-період.
4. Рахуєте відхилення.
5. Якщо поріг перевищено, записуєте інцидент у таблицю й надсилаєте alert.

Нижче не production-ready система, а базова заготовка логіки:

function checkSearchConsoleDrops() {
    const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Watchlist');
    const rows = sheet.getDataRange().getValues();
    const siteUrl = 'sc-domain:example.com';
    const token = ScriptApp.getOAuthToken();
    for (let i = 1; i < rows.length; i++) {
        const url = rows[i][0];
        const minClicks = rows[i][1] || 20;
        const current = queryPageMetrics(siteUrl, url, '2026-05-16', '2026-05-22', token);
        const baseline = queryPageMetrics(siteUrl, url, '2026-05-09', '2026-05-15', token);
        if (!baseline.clicks || baseline.clicks < minClicks) {
            continue;
        }
        const delta = ((current.clicks - baseline.clicks) / baseline.clicks) * 100;
        if (delta <= -30) {
            sendTelegramAlert(`SEO alert: ${url}
Clicks: ${baseline.clicks} -> ${current.clicks}
Delta: ${delta.toFixed(1)}%`);
            sheet.getRange(i + 1, 5).setValue(delta);
            sheet.getRange(i + 1, 6).setValue('sent');
            sheet.getRange(i + 1, 7).setValue(new Date());
        }
    }
}

function queryPageMetrics(siteUrl, pageUrl, startDate, endDate, token) {
    const endpoint = 'https://www.googleapis.com/webmasters/v3/sites/' + encodeURIComponent(siteUrl) + '/searchAnalytics/query';
    const payload = {
        startDate,
        endDate,
        dimensions: ['page'],
        rowLimit: 1,
        dimensionFilterGroups: [{
            filters: [{
                dimension: 'page',
                operator: 'equals',
                expression: pageUrl
            }]
        }]
    };
    const response = UrlFetchApp.fetch(endpoint, {
        method: 'post',
        contentType: 'application/json',
        headers: {
            Authorization: 'Bearer ' + token
        },
        payload: JSON.stringify(payload),
        muteHttpExceptions: true
    });
    const data = JSON.parse(response.getContentText());
    const row = (data.rows && data.rows[0]) || {};
    return {
        clicks: row.clicks || 0,
        impressions: row.impressions || 0,
        ctr: row.ctr || 0,
        position: row.position || 0
    };
}

Ключовий момент тут не в самому коді, а в правилах навколо нього. Якщо не задати мінімальний поріг кліків, система почне “ловити” випадкові коливання. Якщо не тримати окремий AlertStatus, ви почнете дублювати одні й ті самі повідомлення. Якщо не позначити LastChecked, складно буде зрозуміти, чи алерт свіжий, чи сторінку просто давно не перевіряли.

Як відсікти шум і не зненавидіти власні алерти

Будь-який SEO-моніторинг помирає в той момент, коли генерує занадто багато сміття. Команда перестає довіряти повідомленням, а потім пропускає вже реальну проблему. Тому фільтрація тут важливіша за сам факт автоматизації.

Почніть із трьох простих обмежень:

• не перевіряти сторінки з дуже малим трафіком;
• не спрацьовувати по одній метриці без контексту;
• розділяти warning і critical.

Наприклад, падіння кліків на 15% при низьких обсягах може бути просто шумом. А ось мінус 35% по сторінці, яка регулярно приводить ліди, уже заслуговує окремого сигналу. На деяких проектах корисно також виключати дні, коли на сайт викочувався реліз, мінялася перелінковка або вносилися масові SEO-правки. У таких місцях “аномалія” може бути очікуваною, і система має або знати про це, або хоча б не спамити в чат.

Якщо ви вже автоматизуєте технічні перевірки, логіку alert-моніторингу добре поєднати з іншими контрольними шарами. Наприклад, падіння по URL іноді не пов'язане з алгоритмом Google взагалі, а з технічною помилкою після релізу. У такому випадку поруч стає корисним і аудит битих посилань, щоб не розводити діагностику наосліп.

Чому Telegram тут часто кращий за email

Email нікуди не зник, але в операційній роботі він майже завжди повільніший. Telegram краще тим, що сигнал приходить туди, де команда реально живе щодня. Якщо у вас уже є внутрішній чат для маркетингу, SEO або розробки, короткий alert там спрацьовує швидше, ніж лист, який може відкритися через кілька годин. Технічно це найпростіше закривається через Telegram Bot API.

Формат повідомлення теж має значення. Не треба слати “щось сталося”. Нормальний алерт має бути коротким і конкретним:

• який URL просів;
• що саме впало;- наскільки сильно;
• за який період;- який рівень критичності.

Коли повідомлення одразу дає контекст, воно не створює ще одну задачу “піти подивитися, що там мав на увазі бот”.

Що варто зробити вже в першій версії

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

1. Списку з 10–30 критичних URL.
2. Порівняння 7 днів до 7 попередніх днів.
3. Порога, наприклад -30% clicks.
4. Окремого warning і critical.
5. Відправки alert у Telegram.

Цього вже вистачить, щоб перестати жити в режимі “випадково помітили просідання через тиждень”. А далі система добудовується природно: додасте окремі сегменти, базову пріоритезацію, винятки для сезонності та зв'язок із ширшим дашбордом.

Search Console під наглядом — це не про ще одну красиву таблицю. Це про керований технічний процес, у якому органічне просідання перестає бути сюрпризом. Ви не чекаєте, поки бізнес відчує мінус у заявках, а ловите перший сигнал там, де проблему видно найраніше: на рівні конкретної сторінки, конкретної метрики й конкретного відхилення.