Обнаружено, но не проиндексировано в Google: причины и способы исправления

Статус «Обнаружено, но не проиндексировано» (Discovered — currently not indexed) означает, что Google знает о существовании URL, но ещё не загрузил страницу. Адрес мог быть найден в sitemap, по внутренней или внешней ссылке, однако в отчёте Google Search Console отсутствует дата последнего сканирования. Пока обход не состоялся, Google не может полноценно обработать основной контент, увидеть актуальный robots meta tag, выбрать canonical по содержанию и добавить документ в индекс.

Google поясняет, что обычно система хотела просканировать URL, но ожидала, что это может перегрузить сайт, и перенесла обход. Это не единственный возможный контекст проблемы и не точный диагноз для каждого адреса. На практике нужно проверить доступность сервера, объём создаваемых URL, архитектуру, sitemap, crawl demand и то, какие страницы сайт сам показывает как приоритетные.

Главная ошибка — воспринимать статус как оценку качества текста. Google ещё не скачал документ, поэтому на основании одного названия группы нельзя утверждать, что содержание «плохое». Однако общее качество сайта, дубли, история раздела и полезность уже известных страниц способны влиять на спрос Google на дальнейший обход. В руководстве разделим доказанные факты, вероятные причины и действия, которые действительно можно проверить. Для общей проверки используйте отдельную инструкцию как проверить индексацию страницы в Google и Яндексе, а полный перечень технических и содержательных причин собран в материале почему страницы сайта не индексируются.

Содержание

• Что означает статус
• Отличие от «Просканировано, но не проиндексировано»
• Нужно ли беспокоиться
• Как Google выбирает URL для обхода
• Быстрая проверка одной страницы
• Диагностика в Google Search Console
• Основные причины
• Нагрузка и доступность сервера
• Crawl demand и приоритет страницы
• Лишние URL, фильтры и параметры
• Sitemap и lastmod
• Внутренняя перелинковка
• Новые и крупные сайты
• JavaScript и архитектура
• Массовая диагностика
• Пошаговый план исправления
• Практические сценарии
• Мониторинг результата
• Типичные ошибки
• Чек-лист
• FAQ
• Вывод

Что означает статус «Обнаружено, но не проиндексировано»

В отчёте об индексировании страниц Google Search Console этот статус описывает URL, который Google обнаружил, но ещё не просканировал. В карточке обычно нет даты последнего обхода, потому что Googlebot пока не запрашивал документ в рамках зафиксированного состояния.

Статус подтверждает два факта:

1. URL известен Google.
2. На момент данных отчёта страница ещё не была загружена Googlebot.

Он не подтверждает:

• какой HTTP-код вернёт страница при будущем визите;
• есть ли в текущем HTML noindex;
• какое содержание увидит Google;
• какой URL будет выбран каноническим;
• будет ли страница проиндексирована после сканирования;
• является ли текст качественным или слабым.

Google указывает типичный сценарий: обход был отложен, поскольку система ожидала возможной перегрузки сайта. Формулировка не означает, что сервер обязательно падал. Алгоритм старается выбирать скорость обхода так, чтобы не ухудшать работу ресурса, и учитывает историю ответов хоста.

Где Google мог найти URL

Адрес становится известен поисковой системе через:

• XML sitemap;
• обычную HTML-ссылку на сайте;
• внешнюю ссылку;
• редирект;
• hreflang;
• структурированные данные;
• ранее существовавшую версию сайта;
• URL-параметры и автоматически создаваемую навигацию;
• отправку через Google Search Console.

Сам факт обнаружения не показывает, какой источник был основным. Проверка URL иногда содержит сведения о sitemap и ссылающейся странице, но они могут быть неполными.

Статус может быть временным

Новый URL способен находиться в этой группе несколько дней, после чего Googlebot его загрузит без вмешательства владельца. Отчёт обновляется не мгновенно: индивидуальная проверка уже может показывать новый результат, когда общая группа ещё не пересчитана.

Важно: сначала сопоставьте дату публикации, дату отчёта и результат проверки URL. Не перестраивайте сайт из-за страницы, созданной вчера.

Отличие от «Просканировано, но не проиндексировано»

Обе группы содержат URL, отсутствующие в индексе, но показывают разные этапы процесса.

Для «Обнаружено» задача — добиться нормального обхода важных страниц и сократить бессмысленную нагрузку. Для «Просканировано» повторная загрузка уже состоялась, поэтому основное внимание переходит к назначению документа, содержанию и сигналам канонизации.

Нельзя объединять причины механически. Например, пустая карточка товара может косвенно снижать ценность раздела в целом, но конкретный URL со статусом «Обнаружено» Google ещё не загрузил и не мог оценить его текущий текст. Подробная диагностика соседнего состояния приведена в статье про статус «Просканировано, но не проиндексировано».

Возможен переход между статусами

После обхода URL может:

• попасть в индекс;
• перейти в «Просканировано, но не проиндексировано»;
• получить отдельную причину исключения из-за noindex;
• быть признан дублем;
• вернуть ошибку или редирект;
• временно исчезнуть из примеров группового отчёта.

Поэтому успехом является не просто исчезновение из текущей группы. Нужно проверить конечный статус и убедиться, что целевая страница действительно появилась в индексе.

Когда статус требует вмешательства

Не каждый обнаруженный URL нужно срочно исправлять. Разовая задержка обхода новой статьи на несколько дней может быть нормальной. Массовый или длительный статус для приоритетных страниц требует анализа.

Проблема значима, если:

• важные категории и услуги не сканируются неделями;
• число URL в группе постоянно растёт;
• ранее Google регулярно обходил раздел, но перестал;
• проблема появилась после миграции или изменения структуры;
• в группе находятся карточки доступных товаров;
• новые статьи не получают ни одного визита Googlebot;
• серверные логи подтверждают падение обхода важных URL;
• Search Console показывает проблемы доступности хоста;
• sitemap содержит тысячи адресов, которые сайт не связывает внутренними ссылками.

Статус может быть ожидаемым для:

• случайных параметров сортировки;
• комбинаций фильтров без спроса;
• календарей с бесконечным числом дат;
• технических страниц поиска;
• устаревших URL из старого sitemap;
• дублей с идентификаторами сессий;
• автоматически создаваемых пустых профилей;
• URL, которые вообще не должны участвовать в поиске.

Определите целевую индексацию

Каждому сегменту назначьте решение:

Цель — не заставить Google просканировать всё подряд. Цель — освободить путь к важным страницам и перестать создавать ненужный инвентарь URL.

Как Google выбирает URL для обхода

Googlebot не загружает все известные адреса одновременно. Система формирует очередь и учитывает способность хоста отвечать на запросы, а также предполагаемую необходимость повторного или первичного обхода.

Упрощённо на решение влияют две группы факторов:

1. Crawl capacity — сколько запросов хост способен принять без перегрузки.
2. Crawl demand — насколько Google заинтересован загрузить конкретные страницы сейчас.

Это не два числа, которые можно увидеть для каждого URL. Модель помогает правильно разделить диагностику.

Ограничение по способности сервера

Если ответы быстрые и стабильные, Google может постепенно увеличивать параллельность. Ошибки 5xx, тайм-ауты, проблемы DNS и рост времени ответа сигнализируют о необходимости снизить нагрузку.

Спрос на сканирование

Google чаще возвращается к важным, популярным и изменяющимся документам. Дубли и малоизменяемые страницы обычно обходятся реже. Новому URL без внутренних связей сложнее конкурировать за приоритет с известными страницами сайта.

Crawl budget нужен не каждому небольшому сайту

На маленьком ресурсе с несколькими сотнями чистых URL проблема редко решается сложной «оптимизацией бюджета». Там сначала проверяют доступность, sitemap, ссылки, дубли и качество общей структуры. Crawl budget особенно важен для крупных сайтов и ресурсов, которые ежедневно создают или обновляют много страниц.

Подробнее механизм разобран в нашем руководстве о crawl budget.

Быстрая проверка одной страницы

Проверку начинайте с точного канонического URL.

1. Откройте инструмент проверки URL в Google Search Console.
2. Убедитесь, что причина действительно «Обнаружено, но не проиндексировано».
3. Проверьте отсутствие даты последнего обхода.
4. Посмотрите, через какой sitemap или ссылку мог быть обнаружен адрес.
5. Запустите проверку опубликованной страницы.
6. Независимо проверьте текущий HTTP-код и редиректы.
7. Найдите входящие внутренние ссылки.
8. Проверьте наличие URL в актуальном sitemap.
9. Сопоставьте страницу с другими URL того же шаблона.
10. Определите, должна ли она индексироваться.

Что показывает live-тест

Если проверка опубликованной версии успешна, текущий URL доступен инструменту Google. Это полезный сигнал, но он не доказывает, что обычная очередь Googlebot немедленно изменит приоритет или что документ обязательно попадёт в индекс.

Если live-тест обнаруживает блокировку, ошибку сервера, редирект или noindex, исправьте их. После этого URL всё равно должен пройти обычный обход и обработку.

Проверьте ответ вручную

curl -I https://example.ru/page/

Для целевой страницы ожидается прямой 200 OK. Изучите:

• цепочку редиректов;
• X-Robots-Tag;
• Content-Type;
• скорость первого ответа;
• различия для мобильного User-Agent;
• периодические 429, 500, 502, 503 и 504;
• защиту CDN, WAF и rate limit.

Статус относится к прошлому состоянию отчёта. Текущая доступность могла измениться, поэтому техническая проверка всё равно нужна.

Диагностика в Google Search Console

Используйте не один отчёт, а несколько.

Отчёт «Страницы»

В разделе индексирования откройте нужную причину и экспортируйте примеры. Search Console показывает доступную выборку, а не гарантированно полный список всех URL. Анализируйте динамику и шаблоны.

Проверьте:

• дату начала роста;
• количество затронутых страниц;
• типы URL;
• долю важных страниц;
• совпадение с релизами и миграциями;
• переходы в другие статусы.

Статистика сканирования

В отчёте Crawl Stats изучите:

• общее число запросов;
• среднее время ответа;
• объём загруженных данных;
• состояние доступности хоста;
• распределение кодов ответа;
• типы файлов;
• назначение обхода: обновление или обнаружение;
• виды Googlebot.

Если время ответа и ошибки выросли одновременно с накоплением необойдённых URL, проверяйте сервер и инфраструктуру. Если сервер стабилен, но Google расходует запросы на параметры, исправляйте инвентарь и ссылки.

Проверка URL

Индивидуальный инструмент помогает подтвердить конкретное состояние. Не проверяйте только один случайный URL: выберите несколько страниц каждого шаблона, включая индексируемые и необойдённые.

Отчёт об эффективности

У нового необойдённого URL показов не будет. Но данные раздела помогают определить приоритет тем и найти родительские страницы, с которых стоит дать контекстную ссылку.

Основные причины отложенного обхода

Статус не раскрывает точную причину, поэтому проверяют несколько направлений:

1. Сервер или CDN нестабильно отвечает Googlebot.
2. Сайт создаёт больше URL, чем способен эффективно обслуживать.
3. Фильтры и параметры формируют практически бесконечное пространство адресов.
4. Важные страницы находятся глубоко или остаются сиротами.
5. Sitemap содержит дубли, ошибки и неканонические URL.
6. Дата lastmod массово меняется без реального обновления.
7. Раздел новый и ещё не получил устойчивого спроса на обход.
8. Google видит много дублей среди уже просканированных страниц сайта.
9. URL обнаружены из старых источников, но больше не поддерживаются сайтом.
10. Клиентская навигация создаёт адреса, которые не нужны как документы.
11. После миграции остались цепочки редиректов и старые sitemap.
12. Сайт массово публикует низкоприоритетные страницы.

Контент конкретной необойдённой страницы нельзя назвать прямой причиной на основании статуса: Google его ещё не загрузил. Но качество уже известных страниц и повторяемость шаблона могут влиять на общий спрос на сканирование раздела.

Нагрузка и доступность сервера

Официальное описание статуса прямо связано с ожидаемой перегрузкой. Начните с фактов, а не с предположения, что Google «не любит сайт».

Какие проблемы искать

• частые 5xx;
• тайм-ауты;
• медленный TTFB;
• ошибки DNS;
• нестабильный TLS;
• ограничения WAF;
• CDN блокирует или проверяет Googlebot через CAPTCHA;
• хостинг режет частоту запросов;
• приложение исчерпывает память или подключения к базе;
• тяжёлые страницы создаются динамически при каждом запросе;
• деплой временно отдаёт 503 без корректного управления.

Проверяйте историю

Текущий запрос может вернуть 200, хотя во время визитов Google сервер падал. Используйте:

• Crawl Stats;
• access/error logs;
• мониторинг доступности;
• метрики CPU, памяти и базы данных;
• логи CDN и балансировщика;
• историю релизов.

Сопоставляйте время ошибок с изменением объёма обхода. Если проблемы коррелируют, сначала стабилизируйте инфраструктуру.

Как Google реагирует на коды ответа

Повторяющиеся 5xx и сетевые ошибки заставляют Google снижать скорость запросов. 429 Too Many Requests также сообщает о перегрузке или ограничении. Не используйте 429 как постоянный способ управлять поисковым роботом: устраните причину лишних URL или настройте понятные правила обхода.

Что исправлять

• кешировать готовые страницы;
• ускорять медленные запросы к базе;
• отдавать статический HTML, где это возможно;
• устранять циклы и бесконечные маршруты;
• корректно настраивать CDN/WAF;
• не блокировать подтверждённого Googlebot;
• масштабировать ресурсы, если Google регулярно достигает предела хоста;
• возвращать корректные коды во время обслуживания.

Не увеличивайте сервер только потому, что увидели статус у трёх новых страниц. Решение должно подтверждаться метриками.

Crawl demand и приоритет страницы

Даже быстрый сервер не гарантирует немедленный обход каждого адреса. Google распределяет внимание между URL.

Сигналы приоритета нельзя свести к одной формуле, но практическая проверка включает:

• место страницы в архитектуре;
• количество и контекст внутренних ссылок;
• ссылку с уже регулярно обходимого раздела;
• наличие в sitemap;
• реальность обновления;
• историю похожих URL;
• внешние упоминания;
• ценность и популярность раздела;
• частоту изменений родительских страниц.

Страница-сирота

URL, который присутствует только в sitemap, формально обнаружен, но архитектура не подтверждает его значение. Добавьте обычную HTML-ссылку из родительской категории, тематического хаба или связанной статьи.

Глубина

Число кликов не является официальным фиксированным порогом, но важные документы должны быть доступны по понятному пути. Если статья скрыта за шестью пагинациями, а товар открывается только после комбинации фильтров, сайт показывает их низкий приоритет.

Свежесть без манипуляций

Обновляйте страницу и lastmod, когда меняется основное содержание. Ежедневная смена даты на тысячах URL не создаёт реального спроса и затрудняет понимание обновлений.

Лишние URL, фильтры и параметры

Одна категория может породить тысячи комбинаций:

/catalog/shoes/?color=black
/catalog/shoes/?color=black&size=42
/catalog/shoes/?sort=price&size=42
/catalog/shoes/?session=123&utm_source=email

Календари, внутренний поиск и параметры могут создавать бесконечное пространство. Google обнаруживает адреса по ссылкам, но откладывает часть обхода, а важные карточки конкурируют с техническими URL за внимание.

Проведите инвентаризацию параметров

Для каждого параметра определите:

• меняет ли он основное содержание;
• существует ли отдельный поисковый спрос;
• должен ли URL быть постоянной посадочной;
• есть ли на него внутренние ссылки;
• должен ли он присутствовать в sitemap;
• как настроены canonical и robots;
• создаёт ли порядок параметров дубли.

Три группы URL

1. Индексируемые посадочные. Чистый стабильный адрес, уникальное назначение, self-canonical, ссылки и sitemap.
2. Пользовательские состояния. Фильтр полезен посетителю, но отдельный URL не продвигается.
3. Технический мусор. Сессии, трекинг, случайный порядок параметров и бесконечные даты не должны размножаться во внутренних ссылках.

Robots.txt применяйте осознанно

Robots.txt управляет обходом, а не гарантированным исключением адреса из поиска. Блокировка может быть уместна для бесконечных пространств, но робот не увидит noindex и canonical внутри заблокированной страницы. Сначала определите цель и последствия.

Sitemap.xml и корректный lastmod

Sitemap помогает Google обнаруживать страницы, но не гарантирует их обход или индексирование. Он должен содержать URL, которые сайт считает каноническими и важными.

В sitemap не должны попадать

• редиректы;
• 404 и 410;
• страницы с noindex;
• URL, заблокированные от обхода без понятной причины;
• параметры аналитики;
• дубли;
• неканонические варианты;
• пустые результаты поиска;
• временные preview-страницы.

Как использовать lastmod

Указывайте время последнего существенного обновления страницы. Не меняйте lastmod при каждом запуске сборки, если основной материал не изменился. Иначе Google не может отличить важное обновление от технического пересоздания файла.

Разделяйте большие sitemap

Для крупного сайта полезно разделение по типам и разделам: товары, категории, статьи, страны. Это облегчает мониторинг. Если проблема сосредоточена в одном sitemap, быстрее найти шаблон.

Практический опыт агентств подтверждает пользу раздельного анализа. Delante, например, описывает создание отдельных sitemap для языковых версий в международном проекте. Это частный кейс, а не гарантия результата, но он показывает ценность ясной сегментации.

Внутренняя перелинковка

Google использует ссылки, чтобы находить страницы и понимать их связь. Sitemap сообщает о существовании URL, а архитектура объясняет его место.

Проверьте, что:

• ссылка реализована как <a href="...">;
• она ведёт сразу на канонический URL;
• анкор описывает назначение страницы;
• родительский раздел доступен роботу;
• пагинация имеет последовательные ссылки;
• карточки не появляются только после клика или ввода;
• нет ссылок через длинные редиректы;
• важные новые страницы упомянуты из уже обходимых материалов.

Не создавайте механическую сетку

Ссылка должна помогать читателю. Не вставляйте 20 одинаковых анкоров во все статьи. Для новой инструкции уместна ссылка из абзаца о конкретном статусе Search Console, а не случайный блок в футере.

Проверьте страницы-сироты

Сопоставьте URL из sitemap с результатами краулера. Адреса без входящих HTML-ссылок вынесите в отдельную группу. Для каждого решите: встроить в структуру, объединить, удалить или исключить из sitemap.

Новые, крупные и быстрорастущие сайты

Причины различаются в зависимости от масштаба.

Новый сайт

У нового домена мало истории и внешних сигналов, а Google ещё изучает структуру. Важно:

• не публиковать сразу тысячи шаблонных URL;
• обеспечить ссылки от главной и разделов;
• отправить чистый sitemap;
• получить естественные упоминания;
• поддерживать стабильный сервер;
• дать Google время.

Небольшой сайт

Если на сайте 100–500 страниц, но важные URL неделями не обходятся, ищите не абстрактный «маленький бюджет», а конкретные проблемы: сироты, конфликтующие адреса, ошибки сервера, мусорные параметры, слабый sitemap и неправильные редиректы.

Крупный интернет-магазин

Основной риск — соотношение полезного инвентаря и технических URL. Управляйте фильтрами, товарами без наличия, пагинацией, дубликатами и обновлениями. Используйте логи и сегментированные sitemap.

Медиа и новости

Скорость публикации высока, поэтому важны быстрый сервер, корректный news sitemap для подходящих материалов, ссылки с разделов и реальные даты. Старые архивы не должны создавать бесконечные комбинации календаря.

Региональные страницы

Массовое создание городов без реального предложения увеличивает число URL, но не авторитет. Публикуйте страницы только там, где можно дать самостоятельные условия, проекты, специалистов, цены и полезную местную информацию.

JavaScript, навигация и архитектура

Статус относится к ожиданию сканирования, поэтому ошибки рендеринга ещё не являются подтверждённой причиной конкретного URL. Но JavaScript может создавать неправильный инвентарь и мешать обнаружению приоритетных страниц.

Проблемные схемы

• ссылки реализованы обработчиками onclick без href;
• бесконечная прокрутка не имеет URL пагинации;
• фильтры создают новый адрес при каждом состоянии;
• маршруты зависят от фрагментов #;
• сервер отдаёт одну оболочку для любого несуществующего пути;
• sitemap генерируется из маршрутов, которых нет в production;
• клиентский код добавляет ссылки на параметры сессии.

Gatsby

Для Gatsby проверьте:

• создалась ли страница в public после gatsby build;
• существует ли статический index.html;
• совпадают ли slug и canonical;
• попал ли URL в sitemap;
• ведёт ли на него список блога;
• нет ли дублирующего маршрута в src/pages;
• возвращает ли production сервер 200, а не универсальную страницу 404 с кодом 200.

Статическая генерация помогает скорости ответа, но не исправляет автоматически плохую архитектуру и избыток маршрутов.

WordPress

Проверьте архивы дат, авторов, вложений, тегов, внутренний поиск, параметры WooCommerce и sitemap SEO-плагина. Часто сайт создаёт больше индексируемых типов, чем владелец планировал.

Массовая диагностика необойдённых URL

Для большого списка нужна таблица, объединяющая источники.

Сегментируйте до исправления

Разделите URL по шаблонам и целям. Не смешивайте новые статьи, параметры сортировки и товары. Среднее значение по всей группе скрывает причину.

Сравните с контрольной группой

Для каждого типа найдите:

• необойдённый URL;
• недавно просканированный URL;
• индексируемый URL;
• страницу с большим числом ссылок;
• страницу-сироту.

Сравните возраст, sitemap, глубину, код ответа и серверные логи. Это помогает отделить системную проблему от нормальной очереди.

Логи важнее предположений

Access logs показывают, какие URL Googlebot запрашивал, когда и с каким ответом. Проверяйте подлинность робота через обратный и прямой DNS. По логам можно увидеть, тратится ли обход на параметры и возвращается ли робот к исправленным разделам.

Определите долю проблемы

Считайте отдельно:

• долю важных URL без обхода;
• долю технических URL;
• долю новых страниц моложе 7, 14 и 30 дней;
• долю каждого шаблона;
• изменение после релиза.

Если более 20% опубликованных страниц нашей партии не индексируются спустя 14–30 дней, это стоп-сигнал: новые статьи нужно приостановить и провести контрольную диагностику.

Пошаговый план исправления

Шаг 1. Отделите нужные URL от ненужных

Сначала решите, какие страницы должны получать поисковый трафик. Удалите технический мусор из sitemap и внутренних ссылок. Не добивайтесь обхода адресов, которые не имеют самостоятельного назначения.

Шаг 2. Проверьте доступность хоста

Изучите Crawl Stats, серверные ошибки, TTFB, CDN и WAF. Устраните 5xx, тайм-ауты и блокировки Googlebot.

Шаг 3. Сократите пространство URL

Исправьте бесконечные календари, параметры, сортировки и дубли. Не создавайте ссылки на состояния, которые не должны быть страницами поиска.

Шаг 4. Очистите sitemap

Оставьте канонические URL с кодом 200, корректным назначением и реальным lastmod. Разделите крупные карты по типам.

Шаг 5. Усильте архитектуру

Добавьте контекстные ссылки, родительские листинги и последовательную пагинацию. Уберите редиректы из внутренних ссылок.

Шаг 6. Проверьте несколько URL в Search Console

Запустите live-тест. Для нескольких наиболее важных адресов после исправлений можно запросить индексирование. Повторная отправка одного URL много раз не ускоряет обход.

Шаг 7. Дождитесь обычного сканирования

Google указывает, что обход может занять от нескольких дней до нескольких недель. Контролируйте дату обхода и переход в конечный статус.

Шаг 8. Оцените системный результат

Проверяйте не только один URL, а долю важных страниц шаблона. Если Google начал обход, но страницы перешли в «Просканировано, но не проиндексировано», переходите к диагностике содержания и дублей.

Практические сценарии

Сценарий 1. Новая статья блога

Материал опубликован три дня назад, находится в sitemap и связан со списком блога. Ошибок сервера нет.

Действие: проверить live URL, убедиться в корректной ссылке и подождать. Ежедневное редактирование и повторная отправка не нужны.

Если через несколько недель статус не меняется, сравните с другими статьями, проверьте серверные логи и наличие контекстных ссылок из тематического кластера.

Сценарий 2. Тысячи фильтров магазина

Google обнаружил десятки тысяч комбинаций цветов, размеров и сортировок, а новые карточки товаров обходятся медленно.

Действия:

• определить индексируемые фильтры;
• убрать ссылки на технические параметры;
• нормализовать порядок параметров;
• очистить sitemap;
• закрыть бесконечные пространства от обхода только после анализа;
• усилить ссылки на товары и категории;
• проверить изменения по логам.

Сценарий 3. Проблема после миграции

Новый сайт содержит старые и новые sitemap, внутренние ссылки ведут через цепочки, а часть URL открывается на другом хосте.

Действия:

• составить карту соответствий;
• оставить один переход 301;
• обновить ссылки;
• удалить старые URL из актуального sitemap;
• проверить canonical и доменное свойство Search Console;
• контролировать Googlebot на обоих хостах.

Сценарий 4. Слабый сервер

Crawl Stats показывает рост времени ответа и 5xx. В логах Googlebot получает ошибки при нагрузке.

Сначала исправляют инфраструктуру: кеш, запросы, ресурсы, CDN. Добавление ссылок не поможет, если сервер не способен стабильно отвечать.

Сценарий 5. Страницы-сироты

Карточки присутствуют в sitemap, но краулер сайта не находит входящих ссылок. Добавьте их в категории, пагинацию и связанные подборки либо удалите адреса, если они созданы ошибочно.

Сценарий 6. Массовые городские страницы

CMS создала сотни URL с одинаковым шаблоном. Даже до оценки каждого текста Google видит общий масштаб генерации и структуру уже известных страниц.

Проверьте реальность предложения в городах, сократите пустые регионы, добавьте самостоятельную ценность и не публикуйте новую партию, пока не понятен результат существующей.

Как отслеживать результат

Зафиксируйте дату и тип каждого системного изменения. Не меняйте одновременно сервер, sitemap, ссылки и шаблон без необходимости: иначе будет трудно понять эффект.

Контролируйте:

• переход URL из группы;
• появление даты последнего обхода;
• коды Googlebot в логах;
• изменение объёма запросов;
• время ответа;
• долю обхода важных и технических URL;
• конечную индексацию;
• появление показов.

Три уровня успеха

1. Технический: Googlebot начал запрашивать важные URL и получает 200.
2. Индексный: целевые страницы добавлены в индекс.
3. Поисковый: страницы получают релевантные показы и переходы.

Первый уровень не гарантирует два следующих, но без него они невозможны.

Срок наблюдения

Для новой страницы разумно учитывать нормальную задержку в несколько дней или недель. Для массового изменения отслеживайте контрольную группу. Не объявляйте исправление успешным после одного обхода.

Когда остановить публикации

Если накопление необойдённых страниц продолжается, не увеличивайте очередь новыми статьями. Сначала определите, почему Google не успевает или не хочет обходить уже опубликованные материалы.

Типичные ошибки при исправлении

Ошибка 1. Объявить контент плохим

Google ещё не загрузил конкретную страницу. Качество раздела может влиять косвенно, но статус не является прямой оценкой её текста.

Ошибка 2. Отправлять URL каждый день

Google предупреждает, что повторные запросы одного адреса не ускоряют обход. Исправьте системную причину и используйте инструмент для нескольких приоритетных страниц.

Ошибка 3. Добавить все URL в sitemap

Карта не гарантирует сканирование. Смешивание важных страниц с параметрами и ошибками ухудшает контроль.

Ошибка 4. Изменять lastmod при каждой сборке

Дата должна отражать существенное обновление, а не пересоздание файла. Массовые ложные даты не делают страницы важнее.

Ошибка 5. Закрыть важные URL в robots.txt

Так Googlebot вообще не сможет загрузить документ. Robots.txt нужен для управления обходом, а не для исправления каждой проблемы индексации.

Ошибка 6. Купить ссылки до проверки сервера

Внешняя ссылка поможет обнаружению, но URL уже обнаружен. Она не устранит 5xx, WAF, бесконечные параметры или неправильную архитектуру.

Ошибка 7. Увеличивать crawl rate вручную

Владелец не может потребовать неограниченный обход. Google подстраивает скорость под доступность и спрос. Сначала улучшайте способность хоста и качество инвентаря.

Ошибка 8. Смотреть только общий график

Разделите товары, статьи, фильтры и технические URL. Общий рост может состоять почти полностью из ненужных параметров.

Ошибка 9. Удалять все исключённые страницы

Некоторые URL просто ждут нормального обхода. Сначала классифицируйте их и проверьте возраст.

Ошибка 10. Считать исчезновение из группы успехом

URL может перейти в другую причину исключения. Проверьте конечный статус и индекс.

Чек-лист диагностики и исправления

Назначение URL

• Страница должна участвовать в поиске.
• У неё отдельный пользовательский интент.
• Это не параметр, сортировка или технический дубль.
• URL канонический и постоянный.

Search Console

• Проверена точная причина исключения.
• Дата последнего обхода отсутствует.
• Изучена дата отчёта.
• Выполнен live-тест.
• Проверены Crawl Stats и доступность хоста.

Сервер

• Страница возвращает прямой 200.
• Нет регулярных 5xx, 429 и тайм-аутов.
• DNS и TLS стабильны.
• CDN/WAF не блокирует Googlebot.
• Время ответа приемлемо.
• Логи сохраняют запросы поисковых роботов.

Инвентарь URL

• Фильтры разделены на индексируемые и технические.
• Параметры сессий и аналитики не создают ссылки.
• Нет бесконечного календаря и сортировок.
• Ошибочные маршруты возвращают 404/410.
• Старые URL удалены из sitemap.

Sitemap

• В карте только канонические URL с кодом 200.
• Нет noindex, редиректов и дублей.
• lastmod соответствует реальным изменениям.
• Крупные разделы сегментированы.
• Sitemap отправлен в нужное свойство Search Console.

Перелинковка

• На страницу ведёт обычная HTML-ссылка.
• URL доступен из родительского раздела.
• Анкор описывает содержание.
• Ссылка не проходит через редирект.
• Пагинация доступна роботу.
• Страниц-сирот среди целевых URL нет.

После исправления

• Зафиксирована дата изменений.
• Проверена контрольная группа URL.
• Один-два важных адреса отправлены на обход.
• По логам появился Googlebot.
• Проверен новый статус после обхода.
• Подтверждена индексация, а не только сканирование.

Частые вопросы о статусе

Что означает «Обнаружено, но не проиндексировано»?

Google знает URL, но ещё не просканировал страницу. Обычно система отложила обход, поскольку ожидала возможную перегрузку сайта. В отчёте, как правило, нет даты последнего сканирования.

Значит ли это, что текст плохой?

Нет, такой вывод из статуса сделать нельзя: Google ещё не загрузил текущий документ. Но дубли и низкая ценность уже известных страниц раздела могут снижать общий спрос на его обход.

Через сколько Google просканирует страницу?

Фиксированного срока нет. Google указывает диапазон от нескольких дней до нескольких недель для запросов на повторный обход. На практике срок зависит от сайта, доступности и приоритета URL.

Нужно ли нажимать «Запросить индексирование»?

Для нескольких важных страниц после проверки — можно. Многократная отправка одного адреса не ускоряет процесс. Полная инструкция находится в материале об отправке URL на переобход.

Поможет ли sitemap?

Он помогает обнаружить URL и передать дату обновления, но не гарантирует обход и индексирование. Sitemap должен быть чистым и содержать только приоритетные канонические адреса.

Может ли проблема быть на маленьком сайте?

Да. Причиной могут быть ошибки сервера, страницы-сироты, неправильные ссылки, мусорные параметры или новый домен. Не списывайте всё на crawl budget.

Нужно ли увеличивать мощность сервера?

Только если Crawl Stats, логи и мониторинг показывают, что Google достигает предела хоста или получает ошибки. Без данных увеличение ресурсов может ничего не изменить.

Как понять, что Googlebot не заблокирован?

Проверьте robots.txt, CDN/WAF, серверные логи и live-тест Search Console. Подлинность робота подтверждайте через обратный и прямой DNS.

Что делать со страницами-сиротами?

Если они нужны в поиске, добавьте ссылки из родительских и тематических страниц. Если URL созданы ошибочно и не имеют ценности, удалите их из sitemap и генерации.

Нужно ли ставить noindex на ненужные URL?

Это зависит от типа страницы. Чтобы Google увидел noindex, обход должен быть разрешён. Для бесконечных технических пространств иногда важнее прекратить генерацию и ссылки. Подробности — в руководстве по директиве noindex.

Чем этот статус отличается от «Просканировано, но не проиндексировано»?

При «Обнаружено» Google ещё не загрузил страницу. При «Просканировано» загрузка уже состоялась, но документ не добавлен в индекс. Причины и порядок диагностики различаются.

Что делать, если после обхода URL не попал в индекс?

Посмотрите новый статус. Если он перешёл в «Просканировано, но не проиндексировано», проверяйте содержание, дубли, canonical, Soft 404 и назначение страницы.

Как массово проверить проблему?

Объедините выгрузку Search Console, sitemap, данные краулера и серверные логи. Сегментируйте URL по шаблонам и сравните важные страницы с техническими.

Когда нужен технический аудит?

Если проблема массовая, длительная, возникла после миграции или сопровождается ошибками сервера, нужен комплексный анализ. Можно заказать SEO-аудит сайта или техническую SEO-оптимизацию.

Что делать: краткий вывод

Статус «Обнаружено, но не проиндексировано» означает, что URL уже известен Google, но ещё не загружен Googlebot. Это состояние очереди обхода, а не готовая оценка качества конкретного текста.

Правильная последовательность:

1. определить, нужен ли URL в поиске;
2. проверить возраст страницы и актуальность отчёта;
3. изучить доступность хоста и Crawl Stats;
4. найти 5xx, тайм-ауты, WAF и ограничения;
5. сократить параметры, дубли и бесконечные пространства;
6. очистить sitemap и правдиво настроить lastmod;
7. встроить важные URL во внутреннюю архитектуру;
8. проверить несколько страниц через Search Console;
9. дождаться обычного обхода;
10. проверить конечную индексацию и показы.

Не стремитесь сканировать каждый технический адрес. Сайт должен ясно показывать Google, какие страницы важны, стабильно отвечать на запросы и не создавать бесконечную очередь из дублей. Если после обхода документ остаётся вне индекса, переходите к следующему этапу диагностики — качеству, canonical и самостоятельной ценности страницы.

Источники

• Отчёт об индексировании страниц — Google Search Console
• Как работает Google Поиск
• Диагностика проблем сканирования
• Рекомендации по sitemap
• Рекомендации по внутренним ссылкам
• Управление структурой URL
• Практический кейс Delante