Виявлено, але не проіндексовано: причини та перевірки
Сайти з тисячами неіндексованих URL зазвичай мають одну нудну причину. Ця таблиця перелічує типові причини в порядку, у якому ми їх перевіряємо.
Симптом, ймовірна причина, перша перевірка
| Симптом у Search Console | Ймовірна причина | Перша перевірка |
|---|---|---|
| Виявлено, не проіндексовано на багатьох нових URL | Google знає URL, але не витратив час на його обхід | Порахуйте внутрішні посилання на сторінку; глибокі сторінки часто пропускаються |
| Обійдено, не проіндексовано | Сторінку переглянуто, але визнано такою, що має низьку цінність або є дублікатом | Порівняйте з позиціонуванням сторінки за тим самим запитом |
| Google обрав інший канонічний URL | Одночасно активні http і https, або www і non-www | Перевірте обидва варіанти та шукайте редирект 301 |
| Staging-сайт з’являється в результатах пошуку | Staging-середовище ніколи не було заблоковане або не потребувало автентифікації | Пошук site:staging.yourdomain.com |
| Різкий сплеск виключених URL | Параметри або фасетна навігація генерують URL | Перегляньте зразки URL у звіті |
| Помилки Googlebot лише на одному піддомені | Брандмауер або обмеження швидкості від хостинг-провайдера або Cloudflare | Перевірте логи сервера на наявність відповідей 429 та 403 |
Перевірка одного URL так, як його бачить Google
Почніть з однієї адреси. Таблиця причин корисна лише тоді, коли ви знаєте, який рядок описує сторінку перед вами.
Почніть зі статусу покриття
Відкрийте звіт про інспекцію сторінки в Search Console та прочитайте рядок статусу перед усе іншим. Статус «Виявлено» та «Обійдено» — це різні висновки, і кожен вказує на своє рішення.
Не витрачайте тиждень на посилання для сторінки, яку Google ніколи не обходив. Ці зусилля краще спрямувати кудись інакше, доки рядок статусу не зміниться.
Збережіть результат інспекції з датою. Стан покриття змінюється під час повторних обходів Google, тому запис з минулого тижня покаже, що сталося тоді, а свіжа інспекція — що відбувається зараз.
Порівняйте сирій HTML із відображеною сторінкою
Отримайте URL за допомогою cURL і шукайте основний текст у відповіді. Якщо слова з’являються лише після запуску скриптів, проблема в рендерингу, а не в графі посилань.
Відсутній заголовок або тонкий текст у сирій відповіді — це швидкий сигнал, який найчастіше ігнорують.
Робіть перевірки послідовно. Збій на першому пункті часто пояснює решту, тому немає потреби перевіряти інші, доки не виправлено перший.
- Головний заголовок присутній у відповіді
- Текст тіла довший за кілька речень
- Внутрішні посилання присутні як звичайні якорі
- Канонічний тег вказує на правильну адресу
Переконайтеся, що карта сайту та robots.txt узгоджені
Карта сайту, яка перелічує URL, тоді як robots.txt його блокує, подає змішані сигнали. Перевірте обидва файли на канонічному хості, оскільки копія на іншому хості може містити іншу інформацію.
Такі невідповідності рідко ламають весь сайт. Вони ускладнюють інтерпретацію інших перевірок.
Також перевірте значення lastmod, якщо ваша карта сайту їх містить. Дати, які ніколи не змінюються або збігаються з днем збірки, мало говорять Google про новизну.
Де тут місце для зворотних посилань
Посилання з іншого сайту — це шлях до виявлення. Google йде ним, що може прискорити витягнення сторінки з черги виявлення.
Це не робить посилання вимикачем індексації. Сторінка без внутрішніх посилань і з одним випадковим зворотним посиланням все ще є слабким кандидатом, і Google чітко заявив, що не індексує все, що знаходить.
Використовуйте toppages, щоб побачити, які з ваших URL приваблюють посилання, а потім переконайтеся, що ці точні URL проіндексовані. Наявність посилань, але відсутність в індексі — це сигнал, вартий дня роботи.
Коли ви сумніваєтеся, подивіться на сторінки, які посилаються на застрягла URL. Якщо жодна з них не є вашою власною сторінкою, проблема, ймовірно, у внутрішній структурі, а не в зовнішніх посиланнях.
Посилання зі сторінок, які ніхто не читає
Посилання зі сторінки, яку ніколи не обходять, дає Google мало можливостей для переходу. Перевірте, чи проіндексована сама сторінка-джерело, перш ніж вважати її шляхом виявлення.
Мертві посилання зі старих сторінок можуть тримати адресу в списку певний час, але рідко самі по собі змінюють вирок.
Внутрішні посилання виконують основну роботу
Більшість виявлення власних сторінок сайту відбувається всередині сайту. Меню, список категорій та карта сайту роблять більше для нової сторінки, ніж одне зовнішнє посилання.
Якщо у сторінки немає внутрішнього шляху, зовнішнє посилання — це латка на структурний прогалину, і саме прогалину потрібно виправити.
Як розрізнити глибину посилань та якість
Сторінка, яку виявлено, але не обійдено, зазвичай є проблемою пріоритетів. Google має адресу, але бачить мало причин поспішати, часто через те, що мало внутрішніх шляхів ведуть туди.
Сторінка, яку обійдено, але не проіндексовано, — це судження. Google прочитав її і не захотів, тому більше посилань не виправить тонкий або дубльований текст.
Фреймворки додають третю причину. Сайти на Next.js та React іноді відправляють текст, який з’являється лише після запуску JavaScript. Отримайте сирій HTML за допомогою cURL і подивіться, чи є там ваш текст. Якщо ні, виправленням буде серверний рендеринг або пре-рендеринг, і рецепт збереження стабільності URL застосовується при зміні технологічного стеку.
Bing та Yandex мають свої власні черги, тому перевірте Bing Webmaster Tools, перш ніж припускати, що проблема лише ваша.
Корисний тест — подивитися на одну й ту ж сторінку з двох боків. Якщо кількість її внутрішніх посилань низька, а текст тонкий, причина може бути обома, і вам слід виправити обидва, перш ніж чекати.
Порядок робіт
- Проінспектуйте один уражений URL і зверніть увагу, чи пише він «URL є в Google».
- Відкрийте карту сайту та переконайтеся, що вона повертає HTTP 200 на канонічному хості.
- Перевірте robots.txt так, як його бачив би Googlebot, а не так, як його бачить ваш браузер.
- Порахуйте внутрішні посилання, що ведуть на сторінку, і тримайте важливі сторінки в межах трьох кліків від головної.
- Видаліть тонкі шаблонні сторінки, які існують лише заради індексації.
- Зачекайте кілька тижнів після виправлень; індексація рідко встановлюється за ніч.
Робота з одним застряглим URL
Використовуйте цю послідовність для одного URL, який перебував у черзі тижнями. Зупиніться на першому кроці, який дасть вам причину.
- 1
Прочитайте статус
Запишіть точний статус з Search Console та дату останнього обходу URL.
- 2
Порахуйте шляхи всередині
З вашого експорту обходу порахуйте внутрішні посилання, що вказують на сторінку, та запишіть, з яких хаб-сторінок вони походять.
- 3
Перевірте відповідь
Запитайте URL та підтвердіть статус 200 на канонічному хості без ланцюжків редиректів.
- 4
Вирішіть, потім зачекайте
Якщо сторінка тонка, покращіть її. Якщо вона просто глибоко схована в сайті, посилайтеся на неї з сильнішої сторінки, а потім зачекайте кілька тижнів, перш ніж робити висновки.
Коли стрибок виключених URL — це проблема параметрів або карти сайту
Різкий ріст виключених URL зазвичай має механічну причину. Завдання — знайти генератор, а не переслідувати кожну адресу.
Параметри та фасетні шляхи
Різкий стрибок часто веде до фільтра або параметра сортування, який почав генерувати нові адреси. Візьміть з десяток зразків із звіту та прочитайте їхні рядки запитів.
Якщо варіанти містять однаковий контент, проблема — у дублюванні. Виправлення — канонічний тег або правило параметра, а не більше посилань.
Слідкуйте за сторінками, які мають існувати. Фільтр може заслуговувати на власну адресу, якщо люди дійсно шукають цю комбінацію. Правило не в тому, щоб блокувати кожен параметр, а в тому, щоб вирішити, які комбінації заслуговують на адресу.
Карта сайту, яка перелічує неправильний хост
Карта сайту, створена для http-версії сайту або для хоста, який тепер робить редирект, дає Google список, якому він не довірятиме. Відкрийте файл і перевірте перші десять адрес на вашому канонічному хості.
Спочатку виправте список. Чиста карта сайту коштує нічого для публікації, і вона усуває одну змінну з розслідування.
Пастки хостингу та блокування ботів
Hostinger, Cloudflare та подібні шари іноді обмежують швидкість для Googlebot, ідеально обслуговуючи людей. Сайт виглядає нормально для вас і ненадійно для краулера.
Прочитайте сирі логи доступу на наявність відповідей 403, 429 та 5xx для агентів користувача, що містять Googlebot. Перевірте ці візити за зворотним DNS, оскільки багато скраперів підробляють ім'я.
AI-краулери — це окреме рішення. Блокування GPTBot або ClaudeBot у robots.txt не впливає на Googlebot, але необережне правило wildcard може. Тестуйте файл після кожного редагування.
Staging-копії потребують уваги. Коли одна з них є проблемою, помістіть її за пароль та запитайте видалення в Search Console. Тег noindex alone може бути скасований одним деплоєм. Перегляньте рецепт редиректів перед консолідацією хостів.
Обмеження швидкості часто з’являються лише в завантажені часи. Перевірка опівночі може виглядати чистою, тоді як логи після обіду розкажуть іншу історію, тому візьміть зразки з кількох вікон, перш ніж приймати рішення.
Ведіть запис кожного правила брандмауера, яке ви змінюєте. Правило, додане для зупинки одного скрапера, може заблокувати і краулера, і симптом може проявитися пізніше як тихий спад покриття.
Які проіндексовані URL ви втрачаєте?
Цей запит коштує 2 кредити та повертає до 1000 рядків.
curl "https://rankbrainmarketing.link/api.php?action=toppages&q=yourdomain.com&per=1000&key=sk_live_..."Виправлення можуть показати результат через тижні. Стан індексу та наш щомісячний оновлення посилань не зміняться в один день, тому порівнюйте подібне з подібним.
Питання щодо виявлених сторінок
Чи зможуть зворотні посилання самі по собі проіндексувати виявлену сторінку?
Самі по собі — ні. Посилання — це шлях виявлення, який може допомогти Google знайти сторінку швидше. Чи буде сторінка проіндексована, все ще залежить від її контенту та решти сайту.
Скільки часу потрібно чекати після виправлення?
Тижні, а не дні. Індексація рідко встановлюється за ніч, а наше оновлення індексу відбувається за власним щомісячним ритмом, тому порівнюйте подібне з подібним при перевірці. Запишіть дату виправлення в свої нотатки, щоб очікування мало початок, на який можна посилатися.
Чи варто запитувати індексацію для кожного URL?
Ні. Запит індексації для кількох важливих сторінок є доречним. Робити це для тисячі тонких сторінок не змінить судження Google про них.
Чи є «виявлено-не проіндексовано» завжди проблемою бюджету обходу?
Зазвичай ні для малого сайту. Бюджет обходу має значення переважно в великому масштабі. Для кількох сотень сторінок більш ймовірними причинами є глибина посилань, тонкий контент або дублікати.
