Найгірша новина у звіті про індексацію ніколи не написана в ньому цифрою. Вона там, де цифри немає.
Двадцять першого серпня 2026 ми дивилися Search Console власного сайту. Проіндексовано 262 сторінки, не проіндексовано 529. Перше, що хочеться зробити з таким звітом, — узятися за найбільшу купу. Найбільша купа виглядала так:
| Причина | Сторінок |
|---|---|
| виключено тегом noindex | 420 |
| заблоковано в robots.txt | 25 |
| виявлено, але не проскановано | 37 |
| проскановано, не проіндексовано | 24 |
| помилка 404 | 11 |
| сторінка з переадресацією | 10 |
| альтернативна канонічна | 2 |
Чотириста двадцять сторінок із noindex. Виглядає як катастрофа й вимагає негайних дій. Насправді це найздоровіший рядок у всьому звіті: сайт сам закрив ці адреси, робот побачив заборону й підкорився. Система працює як задумано.
Проблема лежала на два рядки нижче.
Тридцять сім адрес, до яких робот не дійшов
У категорії «виявлено, але не проскановано» опинилися сторінка «Про нас» і сторінка портфоліо. Обидві — з головного меню. Тобто Google знав про їхнє існування і жодного разу не витратив на них запит.
Поруч він справно обходив 420 адрес, позначених «не індексувати».
Це і є справжня знахідка звіту. Не «багато noindex», а розподіл уваги: робот виявив закриті сторінки раніше й вважав їх вартими обходу більше, ніж дві сторінки, на які ведуть посилання з кожної сторінки сайту.
Звідки він їх узагалі бере
Відповідь знайшлася в одному файлі. У нас є службова сторінка — карта послуг, повний перелік усього, що є на сайті. На ній 296 посилань, і важить вона 887 КБ.
Для робота це найзручніша точка входу: одна сторінка, з якої видно все. Він її обходить, забирає звідти сотні адрес і починає ходити по них — включно з тими, що закриті від індексації. Обхід витрачається, індекс не поповнюється.
Важливо, що сама сторінка не помилка. Помилка — вважати, що «нехай робот бачить усе» безкоштовно. Кожне посилання, яке ви показуєте, — це заявка на обхід, і робот виконує їх у своєму порядку, а не у вашому.
Карта сайту, яка суперечила самим сторінкам
Чотирма днями раніше, 17 серпня, знайшлася річ гірша за нерівний розподіл: чотири сторінки лежали в карті сайту й водночас віддавали noindex.
Це прямо суперечливі вказівки. Карта каже: «ось адреса, будь ласка, обійди». Сторінка каже: «мене не індексувати». В інтерфейсі Search Console така адреса осідає в помилках, і виправдано — сайт сам собі суперечить.
Причина виявилась банальною й повчальною. У нас є правило: розділ, у якому менше трьох сторінок, не індексується — надто порожній, щоб бути корисним. Правило нормальне. Але поріг «три» був записаний константою всередині коду сторінки, а збірка карти сайту про нього не знала й додавала туди все підряд.
Правило, яке з цього лишилось: будь-який поріг індексації має бути одним значенням, спільним для сторінки й для карти. Дві копії однієї константи в різних файлах розійдуться — питання лише коли. І розійдуться мовчки: ніщо не зламається, тести пройдуть, помилка виявиться через тижні у звіті пошуковика.
Одинадцять сторінок, яких більше немає
Окремий рядок звіту — 404. Одинадцять адрес, які колись працювали.
Частина з них — наслідок звичайного наведення ладу. Ми прибирали числові суфікси з кількох адрес: було …/consent-mode-v2-4, стало …/consent-mode-v2. Нова адреса працює, стару перевірити забули. Ще кілька сторінок переїхали в інший розділ — теж без переадресації зі старого місця.
Тут працює правило, яке легко сформулювати й легко забути: перевіряти треба не те, що нова адреса відкривається, а те, що стара веде на нову. Перше очевидне й перевіряється саме собою. Друге ніхто не помічає, поки не подивиться в звіт.
Друга частина 404 цікавіша. Це адреси виду /en/… з українськими написаннями — сторінки, які колись існували всіма мовами, а потім лишилися тільки українською. У нас 52 сторінки з двохсот з гаком мають лише одну мовну версію: перекладу немає, і ставити машинний ми не стали. Про те, як мовні версії ламаються зсередини, є окремий розбір. Google запам'ятав старі адреси й ще довго ходитиме за ними.
Як подивитись те саме в себе
1. Розкрийте звіт індексації повністю. Search Console, розділ «Індексування сторінок». Дивитесь не на загальну цифру, а на перелік причин, і читаєте його знизу вгору — від малих категорій до великих. Найважливіше майже завжди в «виявлено, але не проскановано»: там лежать сторінки, які робот знає й ігнорує.
2. Звірте карту сайту зі станом самих сторінок. Найпростіша перевірка руками:
curl -s https://ваш-сайт.com/sitemap.xml \
| grep -o '<loc>[^<]*' | sed 's/<loc>//' | head -50 \
| while read u; do
echo "$(curl -s "$u" | grep -c 'noindex') $u"
done
Будь-яка одиниця в першій колонці — сторінка, що суперечить власній карті.
Якщо адрес багато, це варто автоматизувати. Ми тримаємо в проєкті окремий скрипт, який обходить усі адреси з усіх карт під виглядом Googlebot і перевіряє чотири речі: код відповіді, заборону в robots.txt, noindex у метатегах і в заголовку X-Robots-Tag, а також canonical. Останнє про заголовок — не дрібниця: noindex можна віддати відповіддю сервера, і у вихідному коді сторінки його не буде видно взагалі.
3. Знайдіть свою сторінку-каталог. Ту, з якої видно все. Порахуйте на ній посилання й подивіться, скільки з них ведуть на адреси, які ви й не збиралися індексувати.
4. Перевірте старі адреси, а не нові. Складіть перелік усього, що ви перейменовували чи переносили за останній рік, і пройдіться по старих адресах. Кожна має відповідати 301, а не 404.
Три пастки, на яких ми втратили час
Це частина, якої зазвичай немає в статтях, а вона найкорисніша.
Не обмежуйте пошук першими кілобайтами сторінки. Перша версія нашого скрипта читала 60 КБ і повідомила про дві сторінки без canonical. Насправді canonical там був — просто лежав після великого блоку структурованих даних. Хибна тривога, породжена оптимізацією заміру.
Не міряйте все одразу в багато потоків. Обхід трьох сотень адрес у шістнадцять потоків із таймаутом двадцять секунд дав нам три хибні тривоги поспіль: найважчі сторінки віддають по 630–670 КБ і не встигають, обірваний HTML читається як «сторінка без canonical і з noindex». Або менше потоків, або більший таймаут.
Помилка 502 під час обходу — часто не дефект сайту. Якщо ви щойно викотили оновлення, контейнер міг перезапускатися рівно в цей момент. Перевіряйте повторно, перш ніж заводити задачу.
Загальне з усіх трьох: вимірювальний інструмент помиляється частіше за те, що він міряє. Перш ніж повірити в тривожний результат, перевірте підозрілу адресу поодинці, руками.
Чесні межі
Якщо у вас сайт на п'ятдесят сторінок — усе вище вас не стосується. Google прямо пише в документації, що керування обходом не є турботою більшості сайтів: робот приходить достатньо часто, бюджету вистачає. Тема вмикається на кількох сотнях адрес і стає важливою на десятках тисяч, тобто передусім у великих каталогах.
Виправлення розподілу обходу не додає позицій і не приносить трафіку саме по собі. Воно робить одне: прибирає причини, через які сторінка, здатна працювати, взагалі не потрапляє в індекс. Далі все одно вирішує зміст сторінки й попит на те, що на ній написано.
І ще одне, що варто сказати прямо: сторінка з noindex — це нормально. Службові розділи, порожні категорії, дублі фільтрів закривати треба. Погано не те, що їх багато, а те, що робот витрачає на них час, який мав витратити на інше. Різницю видно тільки в звіті — і тільки якщо читати його далі за першу цифру.
