«Discovered – currently not indexed» і «Crawled – currently not indexed» — два найчастіші рядки звіту «Сторінки в індексі» у Search Console — і два найбільш незрозумілі. Вони виглядають як технічна поломка, але насправді це рішення Google про пріоритет і якість ваших сторінок. Надсилати знову і знову нічого не змінює. Виправити причину — так.
Цей гайд — повний цикл, який можна цілком передати агенту Hermes: витягти список URL, перевірити кожну сторінку, визначити реальну причину, затвердити чергу виправлень і надіслати через Google Indexing API лише ті сторінки, які заслуговують індексації. У підсумку ви маєте повторюваний щотижневий пайплайн, а не разову сесію кліків.
Що ви отримуєте
- Класифікований інвентар: URL, що застрягли в «discovered», обійдені, але не індексовані, і ті, які вам взагалі не варто було надсилати
- Затверджений список для Indexing API та список пропущених із причинами
- Етап перевірки, який показує, чи спрацювали ваші надсилання
Що потрібно: встановлений і працюючий агент Hermes (hermes chat відкриває сесію. Актуальні кроки встановлення: офіційна документація на hermes-agent.nousresearch.com/docs), властивість Search Console, власником якої ви є, і два набори облікових даних Google (один для читання GSC, інший для Indexing API). Перший сетап близько 60–90 хвилин, потім близько 15 хвилин на тиждень. «Готово» означає: ваші надіслані URL показують реальну зміну статусу в API перевірки протягом двох тижнів — або у вас є переконливі докази, чому ні.
Правильно читати два статуси
Google не застряг на вашому сайті. Він ухвалив рішення — і статус каже вам, яке саме.
Статус | Що насправді означає | Часті причини | Коли надсилати |
|---|---|---|---|
Discovered – currently not indexed | Google знає URL (із sitemap або посилань), але ще не обходив його | Низький пріоритет обходу, слабкі або відсутні внутрішні посилання, тиск на краулінговий бюджет на великих сайтах, новий сайт, повільний або важкий JS-рендеринг, sitemap, що часто змінюються | Один раз, після покращення сигналів пріоритету (передусім внутрішніх посилань) |
Crawled – currently not indexed | Google отримав URL, але вирішив його не індексувати | Дубльований або майже дубльований контент, слабкий контент, canonical на інший URL, noindex на момент обходу, soft 404, оцінка як низькоцінного | Тільки якщо ви дійсно щось змінили: контент, canonical або noindex |
Indexed | В індексі | — | Не надсилати |
Excluded | Обійдений та виключений навмисно (noindex, canonical, вибір дубліката, блокування) | — | Не надсилати; перевірте, чи виключення навмисне |
Однією фразою: надсилайте лише URL, які ви дійсно змінили або які заслуговують другого погляду. Indexing API — це канал сповіщень, а не скасування рейтингу. Надсилання слабкої сторінки десять разів поверне десять разів той самий вердикт.
Чому це має робити агент
У кнопки «Запросити індексацію» в GSC немає публічного API — офіційного способу натиснути її скриптом не існує. Найближча автоматизація — Google Indexing API, яка приймає сповіщення про URL безпосередньо. Агент додає цінності з трьох причин:
- Цикл механічний і довгий: інвентар → перевірка → класифікація → виправлення → надсилання → верифікація. Щотижня.
- Потрібен аудиторський слід: вам потрібен файл, який показує, які URL надіслано, коли і чому.
- Потрібен шлюз затвердження: частина, що пише в Google, має перевірятися людиною. Hermes побудований саме навколо цього розділення — скіли, папки проєкту та правила затвердження.
Що потрібно перед початком
- Агент Hermes встановлений. Перевірте
hermes chat, перш ніж продовжувати. - Властивість GSC, власником якої ви є. У форматі
sc-domain:example.com(не повний URL). - Доступ на читання: OAuth-клієнт Google Cloud (client ID + секрет) для Search Console API. Скрипти скіла GSC використовують його для sitemap, Search Analytics і перевірки URL.
- Доступ на запис: проєкт Google Cloud з увімкненою Indexing API і JSON-ключ сервісного акаунта. Додайте e-mail сервісного акаунта як власника в GSC → Налаштування → Користувачі та права. Якщо надсилання повертає 403 — це той самий пропущений крок.
- Python 3 і
pip install google-auth google-api-python-client. - Папка проєкту. Наприклад
/hermes-seo-projectізcontext/,data/,qa/іapproval-rules.md, що вимагає, щоб етап надсилання завжди потребував людського підпису.
Крок 1: зібрати інвентар URL
Скопіюйте два скіли GSC у директорію скілів Hermes (~/.hermes/skills): скіл читання (sitemap, Search Analytics, перевірка URL) і скіл індексації (скрипт надсилання). Якщо харнес каталогізує скіли, їх також можна завантажити через skill_view.
Потім попросіть Hermes у чат-сесії, з папки проєкту:
Перелічи всі sitemap для sc-domain:example.com, витягни кожен URL із lastmod і запиши їх у data/url-inventory.csv. Познач будь-який sitemap, чий fetch упав.
Hermes виконує команди sitemap через термінальний інструмент і пише CSV. Гарний результат: дедуплікований CSV із URL, lastmod та вихідним sitemap. Контроль якості: перевірте п'ять випадкових рядків і звірте підсумок зі звітом sitemap у GSC. Якщо список порожній або аутентифікація падає, повторіть потік аутентифікації GSC; скрипту читання потрібен свіжий OAuth-токен.
Крок 2: перевірити й класифікувати
Потім агент перевіряє інвентар партіями через URL Inspection API і отримує поточний статус покриття кожної сторінки. Попросіть наступний етап:
Перевір кожен URL із data/url-inventory.csv. Розділи їх на три файли: data/to-submit.txt (не індексовані та гідні надсилання), data/skip.txt (із причиною для кожного URL) і data/needs-fix.txt (не індексовані та застряглі на тому, що ми можемо змінити).
В API перевірки є ліміти частоти на властивість (актуальну квоту дивіться в Google Cloud Console; кілька тисяч на день, але не безмежність). На великих сайтах обмежте цей прохід URL із найсвіжішим lastmod — тими, що ви дійсно змінювали цього кварталу. Контроль якості: вибірково перегляньте список пропущених. У ньому мають домінувати noindex, canonical на інші URL і дублікати, а не сторінки, які вам важливі. Якщо сайт із тисячами URL дає порожній needs-fix, етап інвентаря, імовірно, втратив сторінки. Розширте вхідний діапазон.
Крок 3: тріаж перед надсиланням
Крок, який усі пропускають. Зіставте застряглі URL із причиною та виправленням у цьому порядку:
Причина | Виправлення | Надсилати після виправлення? |
|---|---|---|
У сторінки немає жодного внутрішнього посилання | Додати контекстні посилання з індексованих сторінок | Так |
Зовсім новий сайт або сторінка | Виправляти нічого; надіслати один раз і чекати 1–2 тижні | Так, один раз |
Блокування robots.txt | Зняти блокування на цьому шляху | Так |
Обійдений, але дубльований або слабкий | Переписати, об'єднати або видалити | Тільки після реальної зміни контенту |
canonical вказує на інший URL | Виправити canonical, якщо невірний; якщо навмисно — припинити надсилати цей URL | Тільки після виправлення |
noindex на момент обходу | Прибрати noindex і дати Google переобійти | Так, після видалення |
Soft 404, марна пагінація/архіви | Виправити сторінку або видалити її | Ні — постійний пропуск |
Попросіть Hermes підготувати чергу виправлень таблицею: URL, імовірна причина, доказ (результат перевірки або рев'ю контенту), запропонована дія, рівень ризику. Затверджуйте кожен рядок у чаті. Ваш approval-rules.md має цього вимагати: агент готує, ви затверджуєте, і нічого вище низького ризику не надсилається без підпису.
Шлюз затвердження відділяє підготовку агента від етапу запису.
Самі виправлення — звичайна SEO-робота: переписати контент, почистити canonical, внутрішні посилання. Цей пайплайн покриває половину надсилання. Половину виправлень покривають статті про аудит та оновлення з серії Hermes.
Список надсилання — перетин «виправно» та «гідно індексації».
Крок 4: надсилання через Indexing API
Коли чергу затверджено, помістіть URL у data/approved-urls.txt і дайте Hermes виконати скіл індексації:
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py check-auth
python3 ~/.hermes/skills/gsc-indexing/scripts/index_submit.py submit --urls-file data/approved-urls.txtТип сповіщення за замовчуванням — URL_UPDATED, призначений для нових або змінених сторінок. Три числа, які варто запам'ятати: квота за замовчуванням — 200 URL на день, 600 запитів на хвилину — а 403 означає, що сервісний акаунт не є власником властивості. Якщо затверджений список перевищує 200, розбийте на кілька днів; Hermes може розпланувати решту партій.
Ніколи не надсилайте вже індексовані сторінки та список пропущених. Витрачені сповіщення лише спалюють квоту та створюють шум.
Крок 5: верифікація та очікування
status одразу після надсилання каже лише про те, чи є в Google метадані сповіщення, а не про те, чи індексована сторінка. Справжнє підтвердження приходить за кілька днів.
Через 3–7 днів після партії попросіть Hermes:
Перевір ще раз URL із data/approved-urls.txt і повідом про зміни статусу порівняно з останнім запуском.
Здорова прогресія — discovered → crawled → indexed. Ось як це виглядає протягом тижнів: список неіндексованих стискається, а ваші реальні виправлення (нові внутрішні посилання, переписані тексти) з'являються в індексі. Пам'ятайте: дані GSC приходять із затримкою в кілька днів, і Google переобходить за власним розкладом. URL, що залишається в «Crawled – currently not indexed» 10–14 днів після реальних виправлень, — сигнал якості, а не проблема надсилання; переведіть його в роботу над контентом.
Підтримання циклу
Перетворіть пайплайн на щотижневу рутину: нові або змінені URL з минулого запуску → перевірка → класифікація → тріаж → затвердження → надсилання → журнал. Hermes може виконувати read-only частину (інвентар, перевірка, класифікація) без нагляду, за розкладом, і приносити вам чергу щопонеділка. Етап надсилання лишається за шлюзом затвердження, з безперервним журналом у qa/indexing-log.md: дата надсилання, URL, тип сповіщення, результат. Пів року журналу — єдина чесна міра того, чи працює пайплайн.
Чесні обмеження
- Google документує Indexing API для сторінок зі структурованими даними
JobPostingабоBroadcastEvent. Використання на звичайних сторінках — поширена SEO-практика, але Google не гарантує індексацію та підтримку для жодного типу сторінок. - У кнопки «Запросити індексацію» немає публічного API. Indexing API — найближча автоматизація, але не та сама кнопка.
- Надсилання не створює пріоритет. Якщо сторінка так і не індексується після виправлення, надсилання та очікування, наступна відповідь — якість контенту, а не чергове сповіщення.
Поширені запитання
Чи працює Indexing API зі звичайними сторінками? Вона приймає будь-який URL, який ви надсилаєте. Офіційна документація Google націлена на сторінки JobPosting і BroadcastEvent, тому ставтеся до надсилання звичайних сторінок як до best-effort: корисно, поширено, але ніколи не гарантовано.
Чому після надсилання лишається «Discovered – currently not indexed»? Цей статус зазвичай означає пріоритет обходу, а не провал. Перевірте внутрішні посилання на сторінку, чи не блокує robots.txt шлях і чи сильно сторінка залежить від JavaScript. Потім чекайте: на нових сайтах від виявлення до обходу може минути 1–2 тижні.
Чи достатньо 200 URL на день? Для більшості сайтів так — у будь-якому разі надсилати варто лише реально змінені URL. Якщо їх регулярно більше, пріоритизуйте за бізнес-цінністю та запросіть збільшення квоти в Google Cloud Console.
Чи пришвидшує Indexing API ранжування? Ні. Вона лише сповіщає Google, що URL змінився. Ранжування — окреме рішення систем Google, незалежне від кількості надісланих сповіщень.
Чим це відрізняється від кліку «Запросити індексацію» в Search Console? Та сама мета, інший механізм. Кнопка — чистий UI без публічного API; Indexing API — скриптований канал. Жодне з них не скасовує рішення Google про те, чи має сторінка бути в індексі.
Автор: Джуліан Мерсер, практик технічного SEO в Auspia із 14-річним досвідом. Пише про краулабельність, індексацію, схему та технічні основи, що роблять сайт читабельним і для Google, і для систем ШІ.
