Статус «Indexed, though blocked by robots.txt» в Google Search Console — это не предупреждение «на будущее», а сигнал о конкретной проблеме прямо сейчас: страница уже сидит в индексе и может показываться в выдаче, но Google не может прочитать её содержимое, потому что путь закрыт в robots.txt. На практике это означает: вместо нормального сниппета в выдаче — обрезанная надпись «Информация о странице недоступна», просевший CTR по этому URL и мусор в отчёте «Страницы», который мешает видеть реальные проблемы индексации. Ниже — рабочий план: как отличить безобидный случай от системной утечки, и что сделать руками за один заход.
Почему это не «предупреждение ни о чём»: механика в двух предложениях
Googlebot узнаёт об URL из ссылок — внешних или внутренних — независимо от robots.txt. Файл robots.txt управляет только сканированием (заходом робота внутрь страницы), а не индексацией: если на закрытый URL ведёт хотя бы одна ссылка с анкором, Google может добавить адрес в индекс по этому анкору, ни разу не открыв саму страницу.
Отсюда конкретный сценарий, который встречается почти на каждом сайте с фильтрами или личным кабинетом: страница /catalog/?sort=price&color=red закрыта в robots.txt через Disallow: /*?sort=, но на неё стоят внутренние ссылки из блока «Похожие товары». Через 2–3 месяца в отчёте «Страницы» накапливается статус «Индексировано, несмотря на блокировку в файле robots.txt» — по одной строке на каждый уникальный набор параметров.
Главная ошибка: robots.txt не убирает страницу из индекса
Если страница уже проиндексирована, а вы задним числом закрыли её в robots.txt — она никуда не денется. Google просто перестанет заходить и обновлять сниппет, а сам URL продолжит висеть в выдаче со старым, всё более устаревающим описанием. Это подтверждает и Google Search Central
: чтобы гарантированно убрать страницу из поиска, робот должен иметь доступ к ней и увидеть команду noindex — либо в мета-теге, либо в HTTP-заголовке. Закрыв доступ раньше времени, вы просто «запираете» бота снаружи и лишаете его возможности прочитать команду на удаление.
Практический тест: откройте site.ru/robots.txt и найдите правило, блокирующее нужный раздел. Если правило появилось позже даты первой индексации страницы (проверить дату первого показа можно в URL Inspection, поле «Первое сканирование») — вы и есть тот случай, который надо чинить по схеме ниже, а не «просто подождать».
Пошаговая схема: снять статус за 3 шага
Шаг 1 — временно снимаем блокировку в robots.txt
Удалите или закомментируйте строку Disallow, которая закрывает нужный URL или раздел. Проверить, что правило реально снято (а не закешировано CDN), — командой:
curl -IL https://site.ru/robots.txt
и визуально открыв файл в браузере. Дополнительно сверьтесь с отчётом Search Console: Настройки → Сканирование → Отчёт о файле robots.txt — там видно, когда Google последний раз забирал файл и нет ли ошибок 5xx при его получении.
Шаг 2 — ставим noindex, а не полагаемся на Disallow
В <head> страницы добавьте:
<meta name="robots" content="noindex, follow">
Для не-HTML файлов (PDF, изображения, XML-фиды) — HTTP-заголовок:
X-Robots-Tag: noindex
Проверить, что тег реально отдаётся, можно за 10 секунд: Ctrl+U на странице и поиск по noindex в исходном коде, либо для заголовка — та же команда curl -IL https://site.ru/page/, смотрим строку x-robots-tag. Если noindex стоит, а страница построена на JS-рендеринге и мета-тег добавляется скриптом — Google может не увидеть его при первом сканировании; в этом случае используйте HTTP-заголовок вместо мета-тега, он надёжнее.
Шаг 3 — просим Google перечитать страницу
Через URL Inspection (строка поиска вверху Search Console) вставьте адрес → «Запросить индексирование». По опыту SEO-специалистов, ручная отправка через этот инструмент ограничена примерно 10–12 URL в сутки на проект — для одной проблемной страницы этого достаточно, но не для чистки раздела из тысяч адресов.
Если счёт идёт на десятки и сотни URL, ручная отправка не масштабируется физически — здесь имеет смысл прогнать переобход через индексатор-бот, например SpeedyIndex: он «подсовывает» URL поисковику через сторонние сигналы посещения, а не ждёт очереди ручных запросов, и закрывает чистку раздела за дни, а не недели.
Отчёт обновится не мгновенно: ждите 1–3 недели. Как только в блоке «Страницы» появится статус «Исключено тегом noindex» — можно (не обязательно) вернуть блокировку в robots.txt на постоянку.
Разбор трёх реальных сценариев
Сценарий А: статус висит 3 недели после снятия блокировки без изменений. Проверьте в URL Inspection поле «Последнее сканирование» — если дата не сдвинулась, робот так и не зашёл. Причина обычно в низком crawl budget на разделе (он давно помечен как неважный) или в том, что внутренние ссылки на страницу по-прежнему единичны и слабые. Здесь ручной «Запросить индексирование» плюс размещение временной ссылки с высокотрафиковой страницы сайта ускоряют переобход сильнее, чем ожидание.
Сценарий Б: тысячи страниц со статусом сразу (фильтры, корзина, результаты поиска, личный кабинет).
Это не баг индексации, а утечка внутренней перелинковки в закрытые разделы. Прежде чем чинить noindex на каждой странице поштучно, найдите источник ссылок: прогоните полный обход домена парсером вроде A-Parser с фильтром по путям из вашего Disallow — конфиг вытащит список страниц‑доноров, где стоят ссылки на /cart/, /search/?q=, /account/. Дальше правите не тег, а сам шаблон — убираете прямые <a href> на служебные URL или добавляете rel="nofollow" там, где ссылка нужна пользователю, но не боту. Отдельно выгрузите список всех проблемных URL через Страницы → экспорт CSV и прогоните массовую проверку текущего статуса индексации по списку в Rush Analytics — это быстрее, чем открывать URL Inspection по одному, и покажет, где noindex уже отработал, а где ещё нет.
Сценарий В: нужно снять конкретный URL с выдачи прямо сегодня, техническое решение ещё не готово.
Используйте Удаления (Removals) в Search Console → вкладка «Временные удаления» → «Новый запрос» → вставьте URL → выберите «Скрыть только этот URL» (или «Скрыть URL с этим префиксом» для целого раздела) → отправьте. Это скрывает адрес из выдачи примерно на 6 месяцев, но не трогает базу Google — если за это время вы не поставите noindex или не отдадите 404/410, страница вернётся. Removals — это пластырь на время, пока вы разворачиваете шаги 1–3, а не замена им. Подробнее о том, почему страницы могут выпасть из индекса, читайте в статье Страница выпала из индекса: как найти причину за 10 минут и вернуть её обратно
.
Быстрый чек статуса конкретной страницы
Если нужно за минуту понять, что происходит с одним URL, не открывая полный аудит: экспресс-проверка через PR-CY покажет текущие мета-теги, robots‑директивы и статус индексации страницы в одном отчёте — удобно как первая диагностика перед тем, как лезть в Search Console.
Когда статус можно не трогать
Единичные технические URL (служебные параметры, дубли с UTM), которые не воруют трафик и не тянут за собой краулинговый бюджет всего сайта, можно оставить как есть — гнаться за нулём в этой строке отчёта не нужно. Тревожный порог — не конкретное число, а тренд: если строка растёт из месяца в месяц, а не остаётся плоской, это верный признак утечки перелинковки из сценария Б, и откладывать разбор не стоит: чем больше таких URL накопится, тем дольше потом придётся ждать переобхода после исправления.
Чек-лист перед тем, как закрыть задачу
- Правило
Disallowдля нужного URL снято, файл robots.txt проверен черезcurl -IL. - Тег
noindex(или заголовокX-Robots-Tag) стоит и подтверждён черезCtrl+U/curl -IL. - Запрос на переобход отправлен через URL Inspection (для массовых случаев — через индексатор).
- Источник внутренних ссылок на закрытый раздел найден и починен, а не просто замаскирован тегом.
- Через 2–3 недели статус в отчёте «Страницы» сменился на «Исключено тегом noindex», после чего блокировку в robots.txt можно вернуть.