Глава 9
Індексація: чому сканування не гарантує індексації
Як відрізняти «Googlebot відвідав URL» від «документ є в індексі», чому noindex, дублікати, soft 404, якість і технічні правила спричиняють різні класи проблем і як проводити аудит індексації без ритуального натискання «Запросити індексацію» (Request indexing).
Індексація — один із тих процесів, у яких SEO-фахівці найчастіше плутають факт із наміром. Googlebot отримав 200 — отже, сторінка має бути в індексі. URL є в sitemap — отже, вона має бути в індексі. Ми натиснули «Запросити індексацію» — отже, система «зобов’язана» її додати. Жодне з цих тверджень не відповідає тому, як Google описує роботу пошуку. Навіть повна відповідність технічним вимогам не гарантує сканування, індексації чи показу в результатах пошуку.[1]
9.1Індекс — це не архів усього, що побачив Googlebot
Пошуковій системі немає сенсу зберігати в активному індексі кожну технічно доступну URL. Варіанти параметрів, дублікати, порожні фільтри, тестові сторінки, soft 404, малокорисні комбінації сторінок, автоматично створених за шаблонами, і нескінченні календарі можуть бути доступні для сканування, але не мати самостійної цінності для пошуку. Тому “Crawled - currently not indexed” слід трактувати як категорію стану, а не як один дефект з одним способом виправлення.
9.2noindex працює лише тоді, коли пошуковий робот може його прочитати
Google прямо вказує: директива noindex має бути доступною пошуковому роботу. Якщо сканування сторінки водночас заборонене в robots.txt, Googlebot не отримує HTML і не бачить noindex; URL усе ще може бути відомою завдяки посиланням та інколи з’являтися в результатах без повноцінного текстового опису.[2] Це класичний приклад конфлікту між керуванням скануванням і керуванням індексацією.
9.3“Discovered” і “Crawled” — це різні вузькі місця
Якщо URL має статус “Discovered - currently not indexed”, перше запитання — чи отримував Googlebot сторінку за цією адресою. Якщо ні, ми ще на етапі виявлення URL і планування сканування: тут важливі внутрішні посилання, sitemap, пропускна здатність сервера, потреба пошукової системи в скануванні та надмірна кількість можливих URL. Якщо URL має статус “Crawled - currently not indexed”, пошуковий робот уже дістався до документа, тож бездумно «підсилювати sitemap» менш доцільно. Треба перевіряти групу URL зі спільною канонічною адресою, soft 404, дублікати, якість шаблону, унікальність фактичних даних і те, чи сторінка взагалі заслуговує на індексацію як окремий документ.
9.4soft 404 — це не лише сторінка з текстом «не знайдено»
Стан soft 404 виникає, коли HTTP-відповідь формально успішна, але вміст указує на відсутній або непридатний ресурс. Типові приклади: порожня категорія з кодом 200, товар, який назавжди став недоступним і не має альтернативи, сторінка внутрішнього пошуку без результатів, шаблон з одним заголовком і без основного контенту. Важлива причина проблеми — системі доводиться самостійно визначати стан ресурсу за змістом сторінки замість того, щоб отримати коректний код стану HTTP.
9.5Дублікат може бути «не проіндексований», тому що індексується його представник
У звітах про індексацію багато URL, про які SEO-фахівці кажуть, що вони «випали з індексу», насправді є альтернативними сторінками або дублікатами. Це не обов’язково проблема. Якщо URL з параметрами, версія для друку й URL без параметрів утворюють одну групу зі спільною канонічною адресою, індексація одного представника є очікуваною поведінкою. Тут треба оцінювати групу, а не домагатися індексації кожної URL окремо.
9.6Якість під час індексації: не перетворюйте невідоме на «чинник ранжування»
Google не публікує повної формули відбору сторінок для індексації. Тому я не пишу «сторінка не індексується через E-E-A-T» або «потрібно 800 слів». Коректніше сказати так: у Search Essentials прямо зазначено, що індексація не гарантована навіть для сторінки, яка відповідає технічним вимогам; Google оцінює контент і дублікати на етапах обробки; якщо цілі класи малозмістовних або майже взаємозамінних сторінок систематично не індексуються, це вагомий сигнал переглянути саму цінність шаблону, а не шукати чарівне технічне налаштування.[1][3]
9.7Воронка індексації: правильний знаменник
Я навмисно не ділю кількість проіндексованих URL на кількість усіх URL, які знайшов робот під час сканування. Якщо робот знайшов 12 млн варіантів URL з параметрами, а бізнес очікує 400 тисяч проіндексованих сторінок, такий знаменник нічого не говорить про якість індексації.
9.8Вибірковий аналіз замість ручної перевірки кожної URL
Інструмент перевірки URL (URL Inspection) корисний для підтвердження стану конкретної сторінки, але перевірити 100 тисяч URL вручну нереалістично. Я будую стратифіковану вибірку за такими ознаками: шаблон, рівень підтримки внутрішніми посиланнями, нові чи старі URL, наявність чи відсутність у sitemap, канонічні чи неканонічні URL, країна та мова. Потім беру 50-200 URL із кожного значущого сегмента. Мета — не отримати «загальний % індексації», а знайти клас сторінок, для якого ймовірність індексації різко відрізняється.
9.9«Запросити індексацію» — інструмент перевірки й прискорення обробки окремих змін, а не API для масової індексації
Ручний запит на індексацію я використовую для важливої нової URL або після виправлення конкретної технічної помилки, коли хочу швидше запустити наступний цикл. Це не стратегія, яку можна масштабувати. Google прямо пише, що сканування та індексація потребують часу й не гарантуються; sitemap і належно побудований граф внутрішніх посилань — системні канали, а кнопка ручного запиту — допоміжний інструмент.[4]
9.10Практичний порядок діагностики
Мій порядок перевірки: 1) чи має сторінка за цією URL існувати як окремий документ, доступний у пошуку; 2) кінцевий код стану HTTP; 3) правила сканування та директива noindex; 4) канонічна URL і дублікати; 5) вміст після відтворення сторінки; 6) внутрішні посилання та sitemap; 7) дані інструмента перевірки URL; 8) серверний журнал; 9) порівняння шаблону з проіндексованими аналогами. Це майже завжди швидше, ніж починати з «додамо більше тексту» або «купимо посилання, щоб Google захотів індексувати».
9.11Що ми знаємо точно
Технічна доступність не гарантує індексації; директива noindex має бути доступною пошуковому роботу; sitemap допомагає виявляти URL, але не гарантує індексації чи ранжування; вибір канонічної URL може означати, що альтернативна URL не представлена в індексі окремо; Google не встановлює строків і не дає гарантій сканування та індексації.[1][2][4]
Джерела до глави 9
- Google Search Central. Search Essentials. https://developers.google.com/search/docs/essentials
- Google Search Central. Block Search indexing with noindex. https://developers.google.com/search/docs/crawling-indexing/block-indexing
- Google Search Central. In-depth guide to how Google Search works. https://developers.google.com/search/docs/fundamentals/how-search-works
- Google Search Central. Crawling and indexing FAQ. https://developers.google.com/search/help/crawling-index-faq
- Google Search Central. Crawling and indexing overview. https://developers.google.com/search/docs/crawling-indexing
Це скорочений виклад: у книзі кожна глава має повний розбір, таблиці й приклади. Завантажити книгу або почати зі вступу.