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

Статус «Просканировано, но не проиндексировано» (Crawled — currently not indexed) означает, что Googlebot уже загрузил страницу, но Google пока не добавил её в поисковый индекс. URL известен системе и этап обхода состоялся, однако сам факт успешного ответа сервера не гарантирует появления документа в результатах поиска.

Этот статус часто воспринимают как техническую ошибку и пытаются исправить повторной отправкой URL через Google Search Console. Но Google прямо указывает: страница может быть проиндексирована позднее, а повторно отправлять неизменённый адрес на сканирование не требуется. Поэтому задача специалиста — не заставить робота ещё раз открыть тот же документ, а понять, почему URL не был выбран для индекса и нужно ли индексировать его вообще.

В руководстве разберём проверку одной страницы и массовую диагностику раздела, отличия от статуса «Обнаружено, но не проиндексировано», влияние дублей, качества, canonical, внутренней перелинковки, JavaScript и архитектуры сайта. Отдельно рассмотрим интернет-магазины, сайты услуг, блоги, WordPress и Gatsby. Если сначала нужно проверить сам факт присутствия URL в поиске, воспользуйтесь инструкцией по проверке индексации страницы.

Содержание

• Что означает статус
• Чем он отличается от «Обнаружено, но не проиндексировано»
• Нужно ли исправлять все исключённые URL
• Быстрая проверка одной страницы
• Как анализировать статус в Google Search Console
• Основные причины исключения
• Слабое или неуникальное содержание
• Дубли и выбор другого canonical
• Недостаточная внутренняя перелинковка
• Страницы фильтров и параметры
• JavaScript и неполный HTML
• Soft 404 и ложные страницы
• Массовая диагностика раздела
• Порядок исправления
• Практические сценарии
• Как отслеживать восстановление
• Типичные ошибки
• Чек-лист
• FAQ
• Вывод

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

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

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

1. Google обнаружил URL.
2. Googlebot смог запросить страницу хотя бы один раз.
3. После обработки Google не сохранил этот URL как самостоятельный индексируемый документ на момент обновления данных.

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

Сканирование не равно индексированию

Работу поиска удобно представить как последовательность:

Обнаружение URL → очередь обхода → загрузка → рендеринг → анализ → canonical → индекс

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

Это состояние, а не постоянный приговор

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

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

Главная мысль: Google уже получил URL. Повторный обход без содержательных или технических изменений обычно не устраняет причину исключения.

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

Два статуса похожи только итогом — URL отсутствует в индексе. Диагностика у них различается.

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

У статуса «Обнаружено» дата обхода обычно отсутствует. Там важнее понять, почему Google откладывает загрузку: сайт создаёт слишком много параметрических адресов, сервер отвечает нестабильно, важная страница находится глубоко или весь раздел выглядит малоприоритетным.

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

Нужно ли исправлять все исключённые URL

Нет. Цель SEO-аудита — не добиться индексации максимального количества адресов, а оставить в индексе страницы, которые отвечают самостоятельному поисковому спросу и полезны пользователю.

Нормально, если Google не индексирует:

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

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

Сначала классифицируйте URL по назначению

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

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

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

Начните с конкретного URL, а не с общего списка Search Console. Это позволяет увидеть сохранённые Google сведения и сравнить их с текущей версией.

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

Проверьте текущий ответ сервера

Индексируемый HTML-документ обычно должен возвращать прямой 200 OK. Проверьте адрес командой:

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

Обратите внимание на:

• итоговый HTTP-код;
• заголовок Location;
• X-Robots-Tag;
• тип содержимого Content-Type;
• отличия ответа для Googlebot;
• нестабильные 5xx и тайм-ауты;
• редиректы между HTTP/HTTPS, www/non-www и вариантами слеша.

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

Проверьте индексируемость HTML

В исходном коде должен быть ожидаемый robots meta tag:

<meta name="robots" content="index, follow">

Явное значение index необязательно, если запрета нет. Важно исключить noindex, включая директиву в HTTP-заголовке. Проверьте canonical:

<link rel="canonical" href="https://example.ru/page/">

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

Посмотрите полученный Google HTML

В проверке опубликованной страницы откройте просмотр протестированной страницы и HTML. Убедитесь, что там есть:

• основной заголовок и текст;
• уникальное описание товара или услуги;
• ссылки навигации;
• правильные meta robots и canonical;
• контент, который не появляется только после клика;
• отсутствие шаблонного сообщения об ошибке;
• корректные данные для мобильного робота.

Если исходный HTML содержит только контейнер приложения, а важная информация появляется после сложного JavaScript-запроса, диагностика должна включать рендеринг.

Как анализировать статус в Google Search Console

Откройте Индексирование → Страницы, выберите причину «Просканировано, но не проиндексировано» и экспортируйте примеры. Search Console показывает не полный реестр всех URL, а доступную выборку, поэтому не воспринимайте список как точную базу сайта.

Смотрите динамику, а не только количество

Ответьте на вопросы:

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

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

Не путайте проверку опубликованной страницы с индексом

Сообщение «URL доступен Google» в live-тесте означает, что текущая версия технически может быть обработана. Оно не отменяет статус исключения и не обещает индексацию. Live-тест не воспроизводит все системы выбора canonical и оценки качества.

Когда нажимать «Проверить исправление»

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

Основные причины исключения из индекса

Google не публикует индивидуальное объяснение для каждого URL в этой группе. На практике проверяют несколько классов причин.

1. Страница не обладает самостоятельной ценностью.
2. Содержание слишком короткое, шаблонное или повторяет другие документы.
3. Google объединил URL с дублем либо сомневается в canonical.
4. Внутренние ссылки показывают низкую важность страницы.
5. Параметры и фильтры создают множество почти одинаковых адресов.
6. Основной контент недоступен или неполон при рендеринге.
7. Страница выглядит как Soft 404.
8. Сервер периодически возвращает ошибки или неполный ответ.
9. Мобильная версия отличается от основной.
10. Сайт массово публикует страницы быстрее, чем способен поддерживать их качество.

Обычно действует не одна причина. Например, карточка товара содержит описание производителя, находится на пятом уровне вложенности, доступна по нескольким параметрическим URL и показывает «нет в наличии». Исправление только canonical может оказаться недостаточным.

Слабое или неуникальное содержание

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

Признаки слабой страницы

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

Что улучшать

Не добавляйте текст ради объёма. Раскройте реальную задачу посетителя:

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

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

Проверка на каннибализацию

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

1. перенесите в неё полезные части;
2. настройте редирект с полностью заменённых URL;
3. обновите внутренние ссылки;
4. оставьте отдельные страницы только при различающихся интентах.

Дубли и выбор другого canonical

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

Проверьте:

• заявленный пользователем canonical;
• canonical, выбранный Google;
• редиректы;
• наличие URL в sitemap;
• ссылки на странице и ссылки на неё;
• варианты с параметрами;
• HTTP/HTTPS и www/non-www;
• завершающий слеш;
• версии для печати и AMP, если они сохранились;
• одинаковые страницы в нескольких категориях.

Согласуйте сигналы

Для основного URL желательно, чтобы:

• он возвращал 200 OK;
• canonical указывал на него самого;
• именно он присутствовал в sitemap;
• внутренние ссылки вели сразу на него;
• альтернативные версии перенаправлялись или корректно канонизировались;
• hreflang ссылался на индексируемые канонические страницы;
• контент действительно отличался от соседних документов.

Конфликт выглядит так: sitemap содержит /product/, меню ссылается на /product?ref=menu, canonical ведёт на /catalog/product/, а сервер открывает все три адреса с кодом 200. Google получает противоречивые сигналы и выбирает вариант самостоятельно.

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

Недостаточная внутренняя перелинковка

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

Проблемные признаки:

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

Как усилить страницу

Добавьте ссылки из действительно связанных документов:

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

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

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

Страницы фильтров, сортировки и параметры

Интернет-магазин может создавать тысячи URL из десятков реальных категорий:

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

Если все комбинации доступны для обхода, Google просматривает множество похожих страниц и может не индексировать значительную часть. Это не всегда ошибка. Ошибка — отсутствие стратегии: в sitemap попадает всё, меню создаёт бесконечные комбинации, canonical меняется непоследовательно, а полезные посадочные страницы не отличаются от фильтра.

Разделите фильтры на группы

1. Посадочные со спросом. Постоянный URL, уникальные метаданные, полезное содержание, товары, внутренние ссылки и self-canonical.
2. Пользовательские фильтры без поискового спроса. Доступны покупателю, но не продвигаются как отдельные страницы.
3. Технические параметры. Сортировка, сессии, трекинг и представление списка не должны создавать самостоятельные посадочные.
4. Пустые комбинации. Не должны выглядеть как полноценные страницы с кодом 200 и обещанием ассортимента.

Не закрывайте весь каталог в robots.txt без анализа: робот перестанет получать содержимое и не сможет увидеть canonical или noindex. Управление обходом, канонизацией и индексированием — связанные, но разные задачи.

JavaScript и неполный HTML

Google умеет обрабатывать JavaScript, но рендеринг добавляет этап и создаёт точки отказа. Страница может вернуть 200 OK, после чего приложение не загрузит основной контент из-за ошибки API, авторизации, тайм-аута или зависимости от действий пользователя.

Проверьте в HTML Googlebot:

• присутствует ли основной текст;
• есть ли H1;
• совпадают ли title, robots и canonical;
• выводятся ли ссылки обычными элементами <a href>;
• доступен ли контент без прокрутки, клика или ввода;
• не появляется ли сообщение «ничего не найдено»;
• не меняет ли клиентский код canonical после загрузки;
• нет ли ошибок ресурсов в скриншоте и консоли.

Gatsby и статическая генерация

Для Gatsby основное содержание статьи обычно формируется при сборке и находится в готовом HTML. Это снижает зависимость от рендеринга, но не исключает ошибки:

• страница не создалась из Markdown;
• slug конфликтует с другим маршрутом;
• шаблон вернул пустое тело;
• важный блок загружается только клиентским запросом;
• метаданные устанавливаются после гидратации;
• сборка использует устаревшие данные;
• canonical получает неправильный pathname.

После gatsby build откройте соответствующий public/<slug>/index.html и найдите основной текст, robots и canonical. Проверяйте production HTML, а не только страницу в режиме develop.

WordPress

В WordPress проверьте глобальную настройку видимости для поисковиков, robots meta от SEO-плагина, canonical, архивы таксономий, вложения, параметры пагинации и доступность REST-запросов. Конфликт двух SEO-плагинов может создать несколько canonical или robots meta tags.

Soft 404 и ложные страницы

Soft 404 — URL, который отвечает кодом 200 OK, но по содержанию похож на отсутствующий или бесполезный документ. Это может быть пустая карточка, категория без товаров, профиль без данных или страница с сообщением «материал не найден» внутри общего шаблона.

Примеры:

• удалённый товар продолжает возвращать пустую карточку 200;
• любой несуществующий slug открывает главную страницу;
• региональная посадочная сообщает, что услуга в городе не оказывается;
• категория не содержит товаров и полезной альтернативы;
• страница события после завершения полностью теряет содержание;
• API вернул ошибку, но серверный шаблон всё равно ответил 200.

Выберите корректное действие

• Верните 404 Not Found или 410 Gone, если документа нет и замены не существует.
• Настройте 301 на максимально близкий аналог, если он действительно заменяет исходную страницу.
• Сохраните URL с полезной информацией, если товар временно отсутствует, но ожидается возвращение.
• Для пустой категории добавьте альтернативы только тогда, когда страница остаётся полезной и соответствует своему назначению.

Редирект всех удалённых URL на главную не помогает: такая замена нерелевантна и сама может восприниматься как Soft 404.

Массовая диагностика раздела сайта

Для десятков или тысяч URL ручной проверки недостаточно. Выгрузите доступные примеры из Search Console и дополните их URL из sitemap, базы сайта и результатов краулинга.

Создайте таблицу со столбцами:

Сегментируйте до поиска причины

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

Полезные группы:

• новые статьи;
• старые статьи после обновления;
• категории;
• товары в наличии;
• товары без наличия;
• регионы;
• теги;
• пагинация;
• фильтры;
• параметры;
• страницы, ранее приносившие трафик.

Выберите репрезентативные примеры

Из каждой группы проверьте не менее нескольких URL:

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

Сравнение пары «индексируется / не индексируется» одного шаблона часто даёт больше информации, чем проверка сотни одинаковых исключённых страниц.

Используйте серверные логи

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

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

Проверяйте подлинность Googlebot через прямой и обратный DNS, а не только по строке User-Agent.

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

Исправляйте причины по приоритету, а не все возможные элементы одновременно.

Шаг 1. Определите, нужен ли URL в поиске

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

Шаг 2. Устраните жёсткие технические препятствия

Проверьте код ответа, robots meta, X-Robots-Tag, canonical, редиректы, доступность мобильному Googlebot и полноту HTML. Хотя статус говорит об успешном прошлом обходе, текущая версия могла измениться.

Шаг 3. Уберите дубли и конфликтующие сигналы

Выберите основной URL, согласуйте sitemap, canonical, внутренние ссылки и редиректы. Удалите параметры из ссылок, если они не должны продвигаться.

Шаг 4. Улучшите самостоятельную ценность

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

Шаг 5. Встройте URL в архитектуру

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

Шаг 6. Обновите sitemap

В sitemap должны оставаться канонические URL с кодом 200, которые сайт действительно хочет видеть в поиске. lastmod меняйте только при значимом обновлении основного содержания.

Шаг 7. Проверьте опубликованную версию

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

Шаг 8. Дайте системе время и измеряйте результат

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

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

Сценарий 1. Новая экспертная статья

Статья опубликована неделю назад, добавлена в sitemap и связана с разделом блога. Google просканировал её, но не проиндексировал.

Проверяем:

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

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

Сценарий 2. Сотни карточек товаров

В исключение попали карточки одного бренда. Все используют описание производителя и отличаются несколькими характеристиками.

Решение может включать:

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

Массовая ручная отправка не устранит шаблонность.

Сценарий 3. Региональные страницы услуг

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

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

Сценарий 4. Категория без товаров

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

Если ассортимент появится скоро, добавьте релевантные альтернативы и объяснение. Если категория закрыта окончательно, выберите 404/410 или редирект на действительно заменяющую категорию. Не маскируйте отсутствие длинным общим текстом.

Сценарий 5. Страница React/Gatsby

Пользователь видит материал, но в production HTML находится только оболочка, а запрос к API блокируется для робота. Исправление — обеспечить серверный рендеринг или статическую генерацию основного содержания, вернуть осмысленный HTTP-код при ошибке и проверить HTML в Search Console.

Сценарий 6. URL ранее был в индексе

Если страница приносила показы, а затем перешла в исключение, сравните состояние до и после события:

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

История трафика делает такой URL приоритетнее новой страницы без спроса.

Как отслеживать восстановление индексации

Создайте контрольную выборку по каждому исправленному шаблону. Запишите дату изменения, URL, внесённые правки и исходный статус.

Проверяйте:

• дату повторного обхода;
• статус конкретного URL;
• canonical, выбранный Google;
• число исключённых и индексируемых страниц группы;
• появление показов в отчёте эффективности;
• частоту обхода в логах;
• отсутствие возврата технической ошибки.

Не используйте site: как единственный KPI

Оператор site: подходит для быстрой ориентировочной проверки, но не даёт полного и стабильного списка. Основные источники — проверка URL, отчёт индексирования, Search Console API при допустимом сценарии, серверные данные и органические показы.

Как оценивать эффект

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

Когда пересматривать решение

Если после повторного обхода и разумного периода Google стабильно не индексирует улучшенную страницу:

1. ещё раз сравните её с индексируемыми конкурентами и соседними URL;
2. проверьте выбранный canonical;
3. оцените соответствие поисковому интенту;
4. рассмотрите объединение с более сильным документом;
5. проверьте системные признаки низкого качества всего раздела;
6. не продолжайте бесконечные косметические правки.

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

Ошибка 1. Ежедневно запрашивать индексирование

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

Ошибка 2. Добавлять «водный» текст

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

Ошибка 3. Покупать ссылки до технической проверки

Внешние упоминания способны помочь обнаружению и оценке страницы, но не исправляют noindex, пустой HTML, ошибочный canonical или Soft 404.

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

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

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

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

Ошибка 6. Канонизировать всё на главную

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

Ошибка 7. Исправлять весь сайт по одному примеру

Один URL может быть аномалией. Сравните несколько страниц каждого шаблона и найдите общую закономерность.

Ошибка 8. Считать любой статус санкцией

Исключение из индекса не доказывает ручные меры или алгоритмический фильтр. Проверяйте соответствующие разделы Search Console и общую динамику видимости отдельно.

Ошибка 9. Игнорировать дату данных

Групповой отчёт запаздывает. Перед повторным редактированием убедитесь, что Google уже просканировал исправленную версию.

Ошибка 10. Требовать индексации ненужных страниц

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

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

Назначение страницы

• URL должен участвовать в поиске.
• Для него определён самостоятельный интент.
• Он не является техническим параметром или случайным дублем.
• Содержание соответствует обещанию title и H1.

Техническая доступность

• URL возвращает прямой 200 OK.
• Нет периодических 5xx и тайм-аутов.
• Отсутствует noindex в HTML и HTTP-заголовках.
• Googlebot не получает иной ответ.
• Мобильная версия содержит основной материал.
• В HTML есть ожидаемый контент.

Канонизация

• Self-canonical указан на основном URL.
• Google не выбрал неожиданный canonical.
• Sitemap содержит только основной адрес.
• Внутренние ссылки ведут на основной адрес.
• Параметры и варианты протокола обработаны последовательно.
• Нет нескольких конкурирующих страниц с тем же интентом.

Качество и полезность

• Страница даёт самостоятельный ответ.
• Основная часть не повторяет соседние URL.
• Есть собственные примеры, данные или опыт.
• Информация актуальна.
• Нет пустых или автоматически подставленных блоков.
• Коммерческая страница содержит реальные условия предложения.

Архитектура

• Есть входящие контекстные ссылки.
• Страница доступна из родительского раздела.
• Глубина перехода соответствует важности.
• Ссылки являются обычными <a href>.
• Хлебные крошки и пагинация работают.

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

• Production HTML проверен.
• Live-тест Search Console успешен.
• Обновлён sitemap и корректный lastmod.
• Один важный URL отправлен на повторный обход.
• Зафиксированы дата и состав изменений.
• Настроена контрольная выборка для мониторинга.

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

Означает ли статус, что Google считает контент плохим?

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

Нужно ли повторно отправить URL на индексирование?

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

Сколько ждать после исправления?

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

Поможет ли добавление URL в sitemap.xml?

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

Поможет ли внутренняя ссылка?

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

Нужно ли закрыть исключённые страницы в robots.txt?

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

Может ли причина быть в crawl budget?

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

Что делать с товарами не в наличии?

Если товар временно отсутствует и страница полезна, сохраните её с информацией о сроках и аналогах. Если товар удалён навсегда, выберите 404/410 либо релевантный 301 на фактическую замену. Не перенаправляйте всё на главную.

Может ли страница сама появиться в индексе?

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

Почему похожая страница индексируется, а эта нет?

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

Нужно ли менять дату публикации после исправления?

Только если материал действительно существенно обновлён и редакционная политика это допускает. Искусственная смена даты без содержательных правок не создаёт ценности. В sitemap также указывайте реальный lastmod.

Как отправить исправленную страницу на переобход?

Проверьте опубликованную версию в Search Console и используйте «Запросить индексирование» для важного URL. Полный порядок описан в инструкции по отправке страницы на переобход.

Связан ли статус с noindex?

Страница с обнаруженным noindex обычно попадает в отдельную причину исключения. Но текущую версию всё равно нужно проверить: директива могла появиться после последнего отчёта или передаваться только определённому роботу. О правилах применения директивы читайте в материале про noindex.

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

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

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

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

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

1. определить, нужен ли URL в поиске;
2. проверить точный адрес и дату обхода;
3. изучить HTML, HTTP-код, robots и canonical;
4. сравнить страницу с индексируемыми URL того же типа;
5. устранить дубли, Soft 404 и проблемы рендеринга;
6. усилить самостоятельную пользу документа;
7. встроить его в понятную архитектуру;
8. запросить повторный обход после реального исправления;
9. контролировать повторное сканирование и индексирование группы.

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

Источники

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