«Виявлено, наразі не проіндексовано» означає, що Google знає URL, але ще не просканував його. Цей статус не доводить, що сторінка має слабкий текст, неправильний canonical або тег noindex: Google ще не завантажив документ за цією адресою і не міг зробити такі висновки на рівні сторінки. Тому корисне питання звучить не «як змусити Google проіндексувати URL», а «чому адреса має низький пріоритет сканування і чи потрібна вона в пошуку взагалі».
У довідці звіту про індексування Google пояснює: сканування було перенесено, бо відвідування сайту могло створити надмірне навантаження, тому дата останнього сканування відсутня. Нижче це коротке визначення перетворене на відтворювану діагностику. Метод використовує чотири сигнали, які перевіряє GSC URL Auditor SEOKit: жива HTTP-відповідь, наявність у sitemap, внутрішні посилання і доступність для робота. Ці факти не прогнозують індексування, але відокремлюють технічну суперечність від звичайної проблеми пріоритету.
Що цей статус доводить, а що — ні?
Статус доводить дві речі: Google виявив адресу, але у збережених даних немає завершеного сканування. Порожнє поле останнього обходу важливе. Воно відрізняє цю ситуацію від «Проскановано, наразі не проіндексовано», коли Google уже завантажив сторінку й міг оцінити вміст та канонічні сигнали. Отже, перевіряти потрібно інші причини.
| Сигнал Search Console | Що можна виснувати | Чого виснувати не можна |
|---|---|---|
| Виявлено, не проіндексовано; дати обходу немає | Google знає URL, але не зафіксував сканування. | Що текст слабкий, тонкий або дубльований. |
| Жива перевірка повертає 200 | Зараз Googlebot може завантажити поточну версію. | Що основна система вже поставила URL у чергу або прийняла його. |
| URL є в sitemap | Ви явно надіслали схожу на канонічну адресу для виявлення. | Що карта створює попит на обхід або гарантує індекс. |
| На URL ведуть внутрішні посилання | Сайт має навігаційний шлях і тематичний контекст. | Що сторінка достатньо важлива для негайного обходу. |
Google окремо попереджає: статус «Не проіндексовано» ще не означає помилку, спершу треба визначити причину виключення. Тому звичайний список із десяти можливих причин мало корисний. Однаковий статус може отримати нова картка товару, яка чекає на чергу, сирота, відома лише з sitemap, і тисячі комбінацій фільтрів, які взагалі не слід було надсилати.
Які URL узагалі мають потрапити до індексу?
Починайте з призначення сторінки, а не з кнопки «Надіслати на індексування». URL потрібен в індексі, якщо він канонічний, самостійно відповідає на запит і призначений для пошукового трафіку. Результати внутрішнього пошуку, порожні фільтри, мітки відстеження, комбінації календаря та дублікати фасетної навігації зазвичай цей тест не проходять. Правильна дія для них — прибрати з sitemap, об’єднати або змінити шлях обходу, а не пришвидшувати індексування.
Для кожного URL дайте відповідь на три питання:
- Чи отримає відвідувач повну відповідь саме за цією адресою? Оцінюйте відтворену сторінку, а не запис у базі чи задуманий шаблон.
- Це канонічна адреса? Не витрачайте увагу робота на параметричну версію, якщо сайт указує на інший URL.
- Чи можна дійти до сторінки звичайною навігацією? URL, який існує лише в sitemap, уже виявлений, але сайт слабко показує його важливість.
Якщо десь відповідь «ні», свідомо виключіть або об’єднайте адресу. Якщо всі відповіді «так», переходьте до чотирьох вимірюваних сигналів.
Як працює діагностика SEOKit за чотирма сигналами?
Експортуйте потрібну групу зі звіту «Індексування сторінок» і завантажте файл у GSC URL Auditor. За документацією Google таблиця прикладів обмежена 1000 URL і може бути неповною навіть за меншої кількості. Тому експорт — діагностична вибірка, а не повний список сторінок сайту.
| Перевірка | Здоровий сигнал | Суперечність для розслідування |
|---|---|---|
| Жива HTTP-відповідь | Стабільний 200 на потрібному канонічному URL. | Редирект, періодичний 5xx, тайм-аут, 403 або сторінка 200 з повідомленням про помилку. |
| Наявність у sitemap | У карті лише канонічні індексовані сторінки, які потрібні в пошуку. | Надіслані старі, перенаправлені, параметричні або навмисно виключені адреси. |
| Внутрішні посилання | Релевантні індексовані сторінки посилаються на URL звичайними доступними посиланнями. | Єдине джерело — sitemap, або посилання з’являються лише після дії користувача. |
| Доступ для обходу | Googlebot завантажує сторінку й потрібні ресурси без авторизації. | robots.txt, firewall, обмежувач запитів або нестабільний хостинг блокує доступ. |
Сенс — у поєднаннях. URL із кодом 200, у sitemap і з кількома внутрішніми посиланнями, але без дати обходу схожий на випадок черги або доступної потужності. Сторінка 200, знайдена лише в sitemap, схожа на сироту з низьким пріоритетом. Сотні параметричних адрес без посилань — проблема інвентарю. URL, який тепер перенаправляється, — застарілі дані звіту або завдання на очищення, а не на індексування.
Чому потрібно аналізувати кластери, а не окремі сторінки?
Одна затримана адреса і зростаюча папка затриманих адрес потребують різних рішень. Згрупуйте експорт за каталогом, шаблоном або параметрами. Порівняйте розмір груп і повторюваність чотирьох сигналів. Це головна практична відмінність методу: повторюваний патерн — доказ щодо шаблону, один URL — ще ні.
Уявімо експорт із товарами, сторінками тегів і фільтрами категорій. Товари відповідають 200, входять до товарного sitemap і отримують посилання з категорій. Теги відповідають 200, але внутрішніх посилань не мають. Фільтри відсутні в карті, проте потрапляють у доступну навігацію. Надіслати всі три групи на повторне індексування — означає приховати причини. Товарам, можливо, потрібен час; тегам — редакційне рішення; фільтрам — очищення інвентарю обходу.
У рекомендаціях щодо бюджету сканування Google радить керувати дубльованими й малоцінними URL, швидкістю відповіді сервера та ресурсами з помилками. Управління бюджетом передусім стосується великих або швидко змінюваних сайтів, але кластерний підхід корисний усім: він не дозволяє виправляти окремі URL, коли причина міститься в шаблоні.
Що виправляти за кожного поєднання сигналів?
| Патерн | Імовірне завдання | Як перевірити |
|---|---|---|
| Потрібна сторінка; 200; sitemap; хороші внутрішні посилання; live-тест працює | Не переписувати наосліп. Перевірити, чи новий це кластер, і спостерігати збережений статус. | Перевірити одного представника й стежити за динамікою групи. |
| Потрібна сторінка; 200; sitemap; внутрішніх посилань немає | Додати контекстні посилання з релевантних індексованих сторінок і включити URL до навігації. | Повторно просканувати сайт і переконатися, що посилання доступне без кліку чи події JavaScript. |
| Потрібна сторінка; нестабільна відповідь, 5xx або тайм-аут | Виправити потужність, кешування або rate limit до нового запиту обходу. | Повторити live-перевірки в різний час і вивчити логи сервера. |
| Потрібна сторінка; блокування robots або авторизацією | Зняти ненавмисну заборону. Не використовувати robots.txt замість noindex. | Відкрити Перевірку URL і підтвердити доступність обходу. |
| Непотрібний фільтр, пошук або дублікат | Прибрати із sitemap та внутрішніх шляхів обходу; об’єднати, якщо є канонічна альтернатива. | Переконатися, що правильна канонічна сторінка лишається доступною. |
| URL тепер перенаправляється або видалений | Очистити sitemap і внутрішні посилання. Залишити редирект лише за наявності справжньої заміни. | Перевірити кінцеву відповідь і адресу призначення; не просити індексувати старий URL. |
Матриця навмисно не ставить діагноз «якість», доки сканування не відбулося. Якщо статус зміниться на «Проскановано, наразі не проіндексовано», тоді вміст, дублікати й вибір canonical стануть обґрунтованими напрямами перевірки. До цього переписування сторінки як доведене рішення змішує різні етапи системи Google.
Чи потрібно надсилати URL на індексування після виправлення?
Для невеликої кількості важливих сторінок після усунення технічної суперечності використовуйте живу Перевірку URL. Для багатьох URL Google рекомендує sitemap. У документації про повторне сканування сказано прямо: запит не гарантує ані негайного потрапляння до індексу, ані потрапляння взагалі, а збільшення кількості запитів не пришвидшує обхід.
Зафіксуйте дату виправлення, уражений шаблон і один контрольний URL. Потім спостерігайте групу в просторі індексування SEOKit. Результат — не натиснута кнопка, а припинення появи нових URL у кластері й отримання наявними сторінками дати обходу або інформативнішого статусу.
Чого цей метод не визначає?
Чотири сигнали не прогнозують розклад Google і не гарантують індексування. Search Console показує приклади, а не повний список, збережені дані можуть відставати від живої сторінки, успішний live-тест підтверджує лише доступ зараз. SEOKit читає докази й розставляє пріоритети; він не змінює Search Console, не надсилає приховані команди й не бачить внутрішню чергу Google.
Метод також не перетворює кожен URL на кандидата для індексу. Для великого кластера фільтрів правильний висновок може бути «перестати відкривати ці адреси роботу», а окрема стратегічна посадкова заслуговує на стабільну відповідь і сильну навігацію. Це розрізнення корисніше за універсальну пораду.
Що робити далі?
Експортуйте групу «Виявлено, наразі не проіндексовано», завантажте її в GSC URL Auditor і згрупуйте результати до зміни сторінок. Спершу виправте повторювані технічні суперечності, потім посильте виявлення потрібних сиріт і приберіть непотрібний інвентар із сигналів. Різницю між виявленням, скануванням та індексуванням пояснює наш урок про індексування; якщо після обходу сторінка відповідає 200, але виглядає відсутньою, використовуйте розбір soft 404.