Коротко. Проверить индексацию сайта можно четырьмя способами: оператором site: в поиске (быстро, но приблизительно), через панели Яндекс.Вебмастер и Google Search Console (точно, по каждому URL, с причиной исключения), сторонним краулером типа Screaming Frog в связке с API поисковика (для массовой проверки сотен страниц) и по логам сервера (показывает, заходил ли робот вообще, а не только результат). Для разового вопроса «эта страница в поиске?» хватает панели вебмастера — ответ приходит за минуту. Для проверки сотен страниц каталога вручную способом не обойтись, нужна автоматизация.
Способ 1: оператор site: — быстрая, но грубая проверка
Самый простой способ — ввести в строку поиска site:адрес-сайта.ru или для конкретной страницы site:адрес-сайта.ru/stranica. Если страница выводится в результатах — формально она в индексе. Способ хорош для мгновенной проверки одной-двух страниц, но у него два серьёзных ограничения. Во-первых, число результатов по site: в Google давно не отражает реальный размер индекса — компания официально предупреждает, что это приблизительная оценка, а не точная цифра. Во-вторых, способ не показывает причину, если страницы нет: не отличить блокировку в robots.txt от того, что робот пока просто не дошёл до страницы. Для быстрой проверки «жива ли страница в принципе» подходит, для диагностики проблем — нет.
Способ 2: панели Яндекс.Вебмастер и Google Search Console — точный статус по каждому URL
Это основной рабочий инструмент, и у него есть решающее преимущество перед site: — он показывает не просто «да/нет», а причину. В Google Search Console это инструмент «Проверка URL»: вводится точный адрес страницы, и система показывает, проиндексирована ли она, когда её последний раз сканировал робот, и если не проиндексирована — конкретную причину («Обнаружено, не проиндексировано», «Страница с переадресацией», «Заблокировано robots.txt» и другие категории). В Яндекс.Вебмастере аналогичная функция — раздел «Индексирование» → «Страницы в поиске», плюс отдельная проверка конкретного URL с указанием статуса и, если страницы нет в индексе, причины исключения.
Оба инструмента требуют предварительного добавления и подтверждения прав на сайт в соответствующей панели — это разовая настройка на 10-15 минут, которая окупается тем, что дальше проверка любой страницы занимает секунды, а не догадки по косвенным признакам.
Способ 3: массовая проверка через краулер — когда нужно проверить не одну страницу, а весь сайт
Ручная проверка через панель вебмастера работает для одной-двух страниц, но не масштабируется на каталог из нескольких сотен позиций — вводить каждый URL вручную нереально по времени. Здесь применяют краулеры (например, Screaming Frog SEO Spider) в связке с индексной проверкой: краулер сначала обходит весь сайт и собирает список реальных URL, затем через API Google или выгрузку из Яндекс.Вебмастера эти адреса сверяются с фактическим статусом индексации. Результат — таблица, где по каждой странице сайта видно: есть в индексе / нет в индексе / причина исключения. Такая проверка — стандартный первый шаг при аудите сайта с большим каталогом, потому что вручную такой объём не проверить, а выборочная проверка «на глаз» пропускает системные проблемы, которые касаются не одной страницы, а целого раздела.
| Способ | Скорость | Точность | Когда подходит |
|---|---|---|---|
| Оператор site: | Секунды | Низкая, без причины | Быстрая проверка 1-2 страниц |
| Панель вебмастера | Минуты (после настройки) | Высокая, с причиной | Точечная диагностика конкретных URL |
| Краулер + API | От часа на сайт | Высокая, массово | Проверка каталога из сотен и тысяч страниц |
| Логи сервера | Требует доступа и разбора | Показывает факт визита, не решение об индексации | Диагностика, почему робот вообще не заходит |
Способ 4: анализ логов сервера — увидеть, что реально делал робот
Панели вебмастера показывают результат решения поисковой системы, но не всегда объясняют, что происходило на стороне сервера в момент визита робота. Логи сервера — единственный источник, где видно каждый запрос от Googlebot или YandexBot: точную дату, запрошенный URL и код ответа сервера в этот момент. Это полезно в конкретных ситуациях: страница не индексируется, а панель вебмастера показывает общую формулировку без деталей; нужно убедиться, что робот вообще посещал сайт в даты, когда упал трафик; или нужно понять, не отдавал ли сервер роботу ошибку 500 именно в моменты сканирования — при том что обычным посетителям сайт открывался нормально. Способ требует доступа к серверу и навыка фильтрации логов по user-agent, поэтому на практике его применяют не для разовой проверки, а при более глубокой технической диагностике.
Как выбрать способ под конкретную задачу
Если вопрос разовый — «эта одна страница в поиске или нет» — достаточно панели вебмастера, это займёт минуту и даст точный ответ с причиной. Если нужно проверить состояние всего сайта или крупного раздела каталога — нужен краулер с массовой сверкой, разовая проверка вручную здесь физически невозможна за разумное время. Логи сервера подключают отдельно, когда первые два способа показали проблему, но не объяснили её причину — это уже не проверка «индексируется или нет», а поиск корня технической неполадки. Для регулярного контроля состояния индексации имеет смысл настроить это как часть постоянного мониторинга в рамках веб-аналитики, а не проверять от случая к случаю.
Типичные ошибки при проверке индексации
Первая ошибка — судить об индексации только по позициям в выдаче: страница может быть в индексе, но не показываться по нужным запросам просто потому, что не ранжируется высоко — это другая задача, не связанная с фактом индексации. Вторая — проверять через site: и делать вывод «сайта нет в поиске», хотя реальная причина в том, что запрос был неточным (например, с www при индексации без www). Третья — не различать статусы «Обнаружено, не проиндексировано» и «Заблокировано robots.txt» в Search Console: первое означает, что робот видел страницу, но пока не решил её индексировать (часто само решается со временем или после улучшения контента), второе — что робот вообще не может её прочитать, пока не будет снят технический запрет через SEO-аудит.
FAQ
Какой способ проверки индексации самый точный?
Панели Яндекс.Вебмастер и Google Search Console — они показывают решение самой поисковой системы по конкретному URL, а не косвенную оценку через выдачу.
Почему количество страниц по site: не совпадает с реальным размером индекса?
Google официально называет число результатов по site: приблизительной оценкой, а не точным подсчётом — оно может заметно отличаться от факта в обе стороны.
Нужен ли доступ к серверу, чтобы проверить индексацию?
Нет, для панелей вебмастера и оператора site: доступ к серверу не нужен. Он требуется только для анализа логов — самого глубокого, но и самого редко используемого способа.
Как быстро проверить сотни страниц каталога сразу?
Вручную — никак, для этого нужен краулер (например, Screaming Frog), который соберёт список всех URL сайта, а дальше эти адреса сверяются с данными панели вебмастера или через API.
Если страница не показывается по site:, значит она точно не в индексе?
Не обязательно — точность этого оператора невысока. Прежде чем делать вывод, стоит перепроверить статус через панель вебмастера по точному URL.
Получить полную картину индексации сайта
Бесплатный аудит проверит статус всех страниц сайта и покажет, какие исключены из индекса и почему.
Канонический адрес
Указывает основную версию страницы при дублях с параметрами. Канониклы должны быть абсолютными и вести на код 200.
# проверить, что отдаётся один канонический адрес
curl -s https://example.ru/uslugi/seo/ | grep -i canonical