«Обнаружена, но не проиндексирована» означает, что 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 Google рекомендует sitemap. В документации о повторном сканировании сказано прямо: запрос не гарантирует ни немедленное попадание в индекс, ни попадание вообще, а увеличение числа запросов не ускоряет обход.
Зафиксируйте дату исправления, затронутый шаблон и один контрольный URL. Затем наблюдайте группу в пространстве индексирования SEOKit. Результат — не нажатая кнопка, а прекращение появления новых URL в кластере и получение существующими страницами даты обхода либо более информативного статуса.
Чего этот метод не определяет?
Четыре сигнала не предсказывают расписание Google и не гарантируют индексирование. Search Console показывает примеры, а не полный список, сохранённые данные могут отставать от живой страницы, успешный live-тест подтверждает только доступ сейчас. SEOKit читает доказательства и расставляет приоритеты; он не меняет Search Console, не отправляет скрытые команды и не видит внутреннюю очередь Google.
Метод также не превращает каждый URL в кандидата на индексирование. Для большого кластера фильтров правильный вывод может быть «перестать открывать эти адреса роботу», а отдельная стратегическая посадочная заслуживает стабильного ответа и сильной навигации. Это различие полезнее универсального совета.
Что делать дальше?
Экспортируйте группу «Обнаружена, не проиндексирована», загрузите её в GSC URL Auditor и сгруппируйте результаты до изменения страниц. Сначала исправьте повторяющиеся технические противоречия, затем усилите обнаружение нужных сирот и уберите ненужный инвентарь из сигналов. Разницу между обнаружением, сканированием и индексированием объясняет наш урок об индексации; если после обхода страница отвечает 200, но выглядит отсутствующей, используйте разбор soft 404.