Індексація без ручної рутини: як перевіряти нові URL через Search Console API та Google Apps Script

Публікація нової сторінки ще не означає, що вона вже працює в пошуку. На сайті URL може відкриватися, у CMS статус може бути published, у редакційному плані задача може стояти як закрита, але для Google ця сторінка ще може бути невідомою, не просканованою або не доданою в індекс. Саме тут зазвичай губиться час: команда вважає матеріал завершеним, а проблему помічає тільки тоді, коли сторінка не дає показів, кліків і заявок.

Ручна перевірка через Search Console працює, якщо нових URL мало. Але коли сайт регулярно публікує статті, категорії, посадкові сторінки або сторінки кампаній, потрібен процес: Google Sheets як реєстр нових URL, Apps Script як шар автоматичної перевірки, Search Console API як джерело статусів і окремий список сторінок, які потребують ручної уваги.

Для технічної частини корисно тримати під рукою Search Console API, URL Inspection API, UrlFetchApp і installable triggers. Вони дають базу для перевірок за розкладом і роботи з URL-статусами без щоденної ручної рутини.

Що саме треба контролювати після публікації

Найслабше місце у звичайному контент-процесі, це розрив між “сторінку опублікували” і “сторінка реально потрапила в пошук”. Якщо між цими подіями немає контрольної точки, команда не бачить, де сторінка застрягла.

У простому post-publish реєстрі варто зберігати такі поля:

Це не просто таблиця для звітності. Вона відповідає на операційне питання: які сторінки вже можна вважати нормальними, а які треба підняти в роботу.

Не всі нові URL однаково важливі

Якщо перевіряти всі сторінки з однаковим пріоритетом, система швидко стане громіздкою. Комерційний лендінг, нова категорія, сезонна сторінка і другорядна новина не повинні мати однакову вагу.

Практична шкала може виглядати так:

Така пріоритизація важлива ще й тому, що індексація залежить не тільки від факту запиту в Search Console. На неї впливають якість сторінки, внутрішні посилання, технічна доступність, дублікати, canonical, швидкість обходу сайту і crawl priority. Якщо сторінка слабка або ізольована від внутрішньої структури, сам факт “ми її перевірили через API” не гарантує швидкого результату.

Архітектура post-publish контролю

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

CMS або редакційний план -> Google Sheets -> Apps Script -> Search Console API -> статус / action list

Після публікації URL потрапляє в таблицю. Apps Script за розкладом бере сторінки зі статусом new, pending або atrisk, робить перевірку через API, оновлює lastchecked, записує статус і формує наступну дію. Якщо сторінка довго не входить в індекс, вона переходить у список at_risk.

Головне, щоб система не дублювала одну й ту саму перевірку без сенсу. Наприклад, немає потреби щогодини перевіряти URL, який щойно опублікований і ще не отримав внутрішніх посилань. Але якщо сторінка critical не змінює статус кілька днів, це вже привід для ручної діагностики.

Базовий приклад Apps Script

Нижче спрощений приклад логіки. У реальному проєкті потрібно додати OAuth, обробку помилок і точну структуру відповіді URL Inspection API, але принцип залишається тим самим: беремо URL з таблиці, перевіряємо, записуємо статус і дату перевірки.

function checkNewUrlsIndexing() {
  const sheet = SpreadsheetApp.getActive().getSheetByName('Indexing_Monitor');
  const rows = sheet.getDataRange().getValues();
  const headers = rows[0];

  const col = {
    url: headers.indexOf('url'),
    priority: headers.indexOf('priority'),
    status: headers.indexOf('index_status'),
    issue: headers.indexOf('issue_type'),
    checked: headers.indexOf('last_checked'),
    action: headers.indexOf('next_action'),
  };

  const siteUrl = 'https://example.com/';
  const endpoint = 'https://searchconsole.googleapis.com/v1/urlInspection/index:inspect';
  const token = ScriptApp.getOAuthToken();
  const now = new Date();

  for (let r = 1; r < rows.length; r++) {
    const url = String(rows[r][col.url] || '').trim();
    const currentStatus = String(rows[r][col.status] || '').trim();

    if (!url || currentStatus === 'indexed') continue;

    const response = UrlFetchApp.fetch(endpoint, {
      method: 'post',
      contentType: 'application/json',
      headers: {
        Authorization: `Bearer ${token}`,
      },
      payload: JSON.stringify({
        inspectionUrl: url,
        siteUrl: siteUrl,
      }),
      muteHttpExceptions: true,
    });

    const data = JSON.parse(response.getContentText());
    const result = data.inspectionResult?.indexStatusResult;
    const coverageState = result?.coverageState || 'unknown';

    let status = 'pending';
    let nextAction = 'recheck later';

    if (coverageState.includes('Submitted and indexed')) {
      status = 'indexed';
      nextAction = 'done';
    } else if (coverageState.includes('Discovered') || coverageState.includes('Crawled')) {
      status = 'at_risk';
      nextAction = 'check internal links and page quality';
    }

    sheet.getRange(r + 1, col.status + 1).setValue(status);
    sheet.getRange(r + 1, col.issue + 1).setValue(coverageState);
    sheet.getRange(r + 1, col.checked + 1).setValue(now);
    sheet.getRange(r + 1, col.action + 1).setValue(nextAction);
  }
}

Цей код не треба сприймати як готовий універсальний модуль. Його задача, показати каркас: є список URL, є API-перевірка, є запис результату назад у таблицю. Далі додаються ліміти, батчі, повторні спроби, окремі правила для priority і повідомлення для команди.

Як не створити зайву рутину замість автоматизації

Автоматизація індексації легко стає ще одним джерелом шуму, якщо немає правил. Наприклад, сторінка опублікована годину тому, а система вже кричить, що її немає в індексі. Це не корисний alert, а нормальний стан для нового URL.

Краще працює така логіка:

• перша перевірка через 12-24 години після публікації;
• для critical сторінок повторна перевірка щодня;
• для normal сторінок кілька контрольних перевірок протягом тижня;
• alert тільки якщо URL не змінює статус довше допустимого вікна;
• окрема ручна діагностика для сторінок із технічними або quality-сигналами.

Якщо сторінка довго не індексується, наступна дія не повинна бути “натиснути request indexing ще раз”. Потрібно дивитися ширше: чи є внутрішні посилання, чи немає noindex, чи правильний canonical, чи не дублює сторінка вже існуючий матеріал, чи справді вона має достатню цінність для пошуку.

Rocket-підхід

Найсильніший формат для SEO-команди, це не список “усі нові URL”, а автоматичний список at_risk. У нього потрапляють сторінки, які:

• мають високий priority;
• опубліковані більше заданого часу тому;
• не мають нормального індексного статусу;
• мають повторювану проблему;
• потребують ручної перевірки або внутрішньої перелінковки.

Тоді команда працює не з хаотичним набором URL, а з чергою рішень. Редактор бачить, які матеріали треба допрацювати. SEO-фахівець бачить, де потрібна технічна перевірка. Власник сайту бачить, які важливі сторінки ще не почали працювати.

Контроль індексації не повинен жити в голові SEO-фахівця або в ручних перевірках раз на тиждень. Якщо сайт регулярно публікує нові сторінки, після публікації має запускатися окремий процес: URL потрапляє в Google Sheets, Apps Script перевіряє його за розкладом, Search Console API повертає статус, а команда отримує зрозумілу дію.

Це не гарантує миттєвої індексації, бо Google оцінює не тільки факт існування URL. Але така система прибирає головну проблему: команда перестає здогадуватися, чи сторінка вже зайшла в пошук, і починає бачити конкретний статус, пріоритет і наступний крок.