Как проверить индексацию страницы сайта в Яндексе и Google

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

Для надёжного вывода недостаточно ввести адрес страницы в обычный поиск. Google Search Console и отчёты Яндекс Вебмастера показывают данные по подтверждённому сайту, оператор site: помогает быстро оценить видимость, а технический аудит объясняет, почему URL не попал в индекс. Публичный инструмент Яндекса «Анализ индексации страницы» можно использовать и без добавления сайта в Вебмастер. В этой инструкции разберём каждый способ, расшифруем статусы и составим порядок проверки одной страницы и большого списка URL. Если сначала нужно разобраться в самом процессе, начните с руководства о том, что такое индексация сайта.

Содержание

• Что означает индексация страницы
• Быстрая проверка за несколько минут
• Проверка в Google Search Console
• Проверка в Яндекс Вебмастере
• Оператор site и поиск по URL
• Почему способы дают разные результаты
• Как проверить много страниц
• Техническая диагностика URL
• Основные статусы Google
• Основные статусы Яндекса
• Проверка JavaScript-страниц
• Проверка после публикации и изменений
• Мониторинг индексации
• Типичные ошибки
• Практические сценарии
• Чек-лист
• FAQ
• Вывод

Что означает индексация страницы

Поисковая система сначала обнаруживает URL по внутренней ссылке, sitemap.xml или внешнему источнику. Затем робот ставит адрес в очередь, загружает документ, анализирует HTML и отрисованный контент, сопоставляет страницу с дублями и выбирает канонический URL. Только после этого документ может быть добавлен в индекс.

Упрощённая цепочка выглядит так:

Обнаружение → обход → обработка → выбор canonical → индексация → ранжирование

Проверка должна отвечать не на один, а на три вопроса:

1. Известен ли URL поисковой системе?
2. Разрешены ли обход и индексация?
3. Какой адрес выбран каноническим и присутствует в индексе?

Важно: сообщение «URL известен» ещё не означает, что он проиндексирован. А отсутствие страницы по одному запросу не доказывает её исключение из индекса.

Индексация и ранжирование — разные процессы

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

Проверяйте точный вариант адреса

Для поисковика это могут быть разные URL:

https://example.ru/page/
https://example.ru/page
http://example.ru/page/
https://www.example.ru/page/
https://example.ru/page/?utm_source=test

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

Быстрая проверка за несколько минут

Для одной страницы используйте следующий порядок:

1. Откройте URL в режиме без авторизации и убедитесь, что он доступен.
2. Проверьте код ответа: индексируемая страница обычно должна возвращать 200 OK.
3. Запустите «Проверку URL» в Google Search Console.
4. Проверьте адрес в Яндекс Вебмастере через Индексирование → Проверка страницы или запустите публичный «Анализ индексации страницы».
5. Сравните заявленный и выбранный canonical.
6. Убедитесь, что нет noindex и блокировки, мешающей роботу получить документ.
7. Используйте site: как дополнительную, а не единственную проверку.

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

Проверка в Google Search Console

Инструмент проверки URL — основной источник данных Google для конкретной страницы подтверждённого ресурса. Вставьте полный адрес в верхнюю строку Search Console и дождитесь отчёта.

«URL есть в Google»

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

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

Особенно важна строка «Каноническая страница, выбранная Google». Если система выбрала другой URL, проверяемый адрес может не участвовать в поиске как самостоятельный документ, даже при корректном rel="canonical" на самого себя.

«URL нет в Google»

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

Не нажимайте сразу «Запросить индексирование». Сначала откройте подробности и устраните причину. Повторная отправка технически ошибочного или слабого URL редко меняет решение.

Проверка опубликованной версии

Отчёт по индексу показывает последнюю известную Google сохранённую информацию. Кнопка проверки опубликованной страницы выполняет тест текущей версии. Она полезна после исправления noindex, robots.txt, серверной ошибки или HTML.

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

Как читать дату последнего обхода

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

Проверка мобильным роботом

Google использует мобильную версию контента для индексирования и ранжирования. Убедитесь, что мобильный робот получает основной текст, ссылки, canonical и meta robots. Различия между мобильной и десктопной версиями, ошибки адаптивного шаблона или загрузки JavaScript способны дать неожиданный результат.

Проверка в Яндекс Вебмастере

Для своего подтверждённого сайта используйте в Яндекс Вебмастере раздел Индексирование → Проверка страницы: выберите мобильную или десктопную версию, отправьте URL на проверку и после завершения откройте подробности. Там можно сопоставить версию страницы в базе с текущей версией и проверить её состояние в поиске.

Если сайт не добавлен в Вебмастер, откройте Инструменты → Анализ индексации страницы. Этот публичный инструмент проверяет технические сигналы URL; авторизация и подтверждение прав не обязательны, хотя без авторизации может потребоваться капча. Для полноценного мониторинга собственного сайта всё равно удобнее отчёты подтверждённого ресурса.

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

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

Страница исключена

Вебмастер может сообщить о запрете индексирования, дублировании, перенаправлении, ошибке ответа, недостаточном качестве или другой причине. Сопоставьте сообщение с фактическим HTML и серверными заголовками.

Проверка ответа сервера

Инструмент анализа robots.txt и проверки ответа помогает увидеть страницу глазами робота Яндекса. Это важно, если сайт использует CDN, защиту от ботов, географические правила или разные ответы по User-Agent.

Различия между Google и Яндексом

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

Оператор site: и поиск по точному URL

Для быстрой ориентировочной проверки введите:

site:example.ru/page/

или сочетание домена и уникального фрагмента заголовка:

site:example.ru "Уникальный заголовок страницы"

Если документ показан, это сильный признак присутствия в поисковой базе. Но отсутствие результата не является окончательным доказательством: оператор site: не предназначен для полного и стабильного подсчёта индекса.

Почему site: нельзя считать точным отчётом

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

Поиск по фрагменту текста

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

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

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

Почему результаты не совпадают

Расхождение между Search Console, Вебмастером, site: и сторонним сервисом встречается регулярно. Причины обычно относятся к одной из следующих групп.

Данные обновляются в разное время

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

Проверяется другой вариант URL

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

Выбран другой canonical

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

Сторонний сервис использует неполные данные

SEO-сервисы часто проверяют операторы поиска или собственную базу. Они полезны для массового скрининга, но не имеют полного доступа к внутреннему индексу Google или Яндекса.

Страница недавно выпала или появилась

Переиндексация распределена во времени. В переходный период разные источники закономерно расходятся. Зафиксируйте дату изменения и повторите проверку после нового обхода.

Практическое правило: для Google доверяйте подробной проверке URL в Search Console, для Яндекса — данным Вебмастера. Операторы и сторонние сервисы используйте для дополнительной выборки и поиска аномалий.

Как проверить много страниц

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

Сформируйте эталонный список

Источниками могут быть:

• sitemap.xml;
• выгрузка CMS;
• список посадочных страниц аналитики;
• URL из внутреннего краулера;
• страницы с показами Search Console;
• отчёты Вебмастера;
• серверные логи.

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

Сопоставьте источники

Полезная таблица содержит столбцы:

Проверяйте выборки по шаблонам

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

API и ограничения

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

Индексируемость не равна индексации

Краулер может подтвердить, что страница технически индексируема: код 200, нет noindex, canonical корректен. Но только поисковая система сообщает, включён ли документ в её индекс. В отчёте разделяйте эти два признака.

Как посчитать полезный показатель индексации

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

Базовый показатель можно считать так:

Доля индексации = проиндексированные канонические URL / все целевые канонические URL × 100%

Общая доля полезна для наблюдения за динамикой, но скрывает проблемы отдельных типов. Рассчитывайте её отдельно для статей, услуг, категорий, товаров и региональных страниц. Например, 95% товаров могут находиться в индексе, а 20% статей — выпадать из-за ошибки нового шаблона. Средний показатель сайта будет выглядеть приемлемо и не покажет реальную аварию.

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

Начинайте не со случайных URL, а со страниц, потеря которых сильнее влияет на бизнес:

1. Страницы с органическим трафиком и конверсиями за предыдущий период.
2. Основные коммерческие посадочные и категории.
3. Новые материалы, на которые уже ведут внутренние и внешние ссылки.
4. Типовые представители каждого шаблона.
5. URL из sitemap, которые долго остаются без обхода.
6. Страницы, для которых поисковик выбрал неожиданный canonical.

После приоритетной выборки переходите к массовому исправлению шаблона. Не редактируйте вручную сотни карточек, если один компонент генерирует для всех неправильный noindex.

Как проверять отчёты без ложной паники

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

Ожидаемые исключения:

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

Неожиданные исключения:

• основная услуга получила noindex;
• статья выбрала каноническим чужой URL;
• категория отвечает мягкой 404;
• важные страницы заблокированы robots.txt;
• новый шаблон месяцами остаётся в статусе «обнаружено»;
• робот получает 5xx, хотя пользователи видят страницу.

Цель аудита — не свести число исключений к нулю, а добиться корректного статуса для каждого типа URL.

Техническая диагностика проверяемого URL

Если страница отсутствует в индексе, пройдите сигналы в фиксированном порядке.

1. Код ответа

Основной документ должен отвечать 200 OK. Проверьте также цепочку перенаправлений. 3xx означает, что индексироваться должен конечный адрес; 404 и 410 сообщают об отсутствии; 5xx мешают обходу; мягкая 404 может возвращать 200, но выглядеть для поисковика как пустая ошибка.

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

2. Robots.txt

Убедитесь, что нужный робот может запросить URL и ресурсы, необходимые для понимания страницы. Запрет в robots.txt управляет обходом и не гарантирует удаление уже известного адреса из поиска: закрытый URL может оставаться известным без содержимого. Google и Яндекс рекомендуют не блокировать страницу в robots.txt, если робот должен прочитать установленный на ней noindex. Подробнее о различии сигналов читайте в руководстве про noindex.

3. Meta robots и X-Robots-Tag

Проверьте HTML и HTTP-заголовки:

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

Даже если в HTML нет запрета, сервер или CDN может отправлять:

X-Robots-Tag: noindex

4. Canonical

Для самостоятельной страницы ожидается корректная абсолютная ссылка на основной URL:

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

Проверьте, что canonical отвечает 200, индексируем, не перенаправляет и не противоречит sitemap и внутренним ссылкам. Подробные сценарии конфликтов разобраны в статье про rel="canonical".

5. Sitemap.xml

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

6. Внутренние ссылки

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

7. Качество и уникальная ценность

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

8. Доступность ресурсов и рендеринг

Если основной текст создаётся JavaScript, проверьте отрисованную версию. Ошибки API, бесконечные загрузчики и заблокированные скрипты способны оставить роботу пустой шаблон.

9. Заголовки и основной контент

Убедитесь, что страница не только технически открыта, но и однозначно описывает тему. H1, title, первый экран и основной текст должны соответствовать одному интенту. Автоматически созданный title без содержимого не превращает пустой шаблон в качественный документ.

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

10. Глубина вложенности

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

11. Стабильность сервера

Однократный запрос с 200 не гарантирует стабильность. Проверьте логи за несколько дней: поисковый робот мог регулярно получать 429, 502, 503 или таймауты. Защитные системы иногда блокируют дата-центры роботов, чрезмерно ограничивают частоту или требуют JavaScript-проверку, которую crawler не проходит.

12. Язык, регион и альтернативные версии

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

13. Структурированные данные

Ошибки schema.org обычно не являются прямой причиной отсутствия обычной страницы в индексе, но могут указывать на поломку шаблона. Проверьте, что разметка описывает видимый контент и содержит правильный URL. Не отвлекайтесь на предупреждение о расширенном результате, пока страница закрыта noindex или отвечает 500.

14. Согласованность всех сигналов

Итоговая картина должна быть однозначной:

Когда часть сигналов говорит «индексировать», а часть — «считать дублем», поисковая система вынуждена выбирать самостоятельно. Именно такие конфликты часто объясняют нестабильный статус.

Основные статусы Google

Просканировано, но пока не проиндексировано

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

Обнаружено, но пока не проиндексировано

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

Страница с переадресацией

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

Дубликат: Google выбрал другой канонический URL

Система объединила страницу с другим документом. Сравните содержание, canonical, ссылки, sitemap и редиректы. Если оба URL должны ранжироваться отдельно, у каждого должна быть собственная ценность и ясный интент.

Исключено тегом noindex

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

Заблокировано robots.txt

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

Не найдено 404 или мягкая 404

Проверьте, существует ли полноценный документ. Не заменяйте полезную страницу пустым шаблоном с 200. Если URL удалён без замены, корректный 404 или 410 является нормальным результатом.

Основные статусы Яндекса

Яндекс группирует исключения по техническим и алгоритмическим причинам. Формулировки интерфейса могут обновляться, но логика проверки сохраняется.

Запрещено индексирование

Проверьте meta robots, X-Robots-Tag и доступ робота. После исправления дождитесь повторного обхода и убедитесь, что запрет действительно исчез из ответа.

Неканоническая страница или дубль

Яндекс считает другой адрес основным. Проверьте зеркала, протокол, слеши, параметры, canonical, внутренние ссылки и карту сайта.

Перенаправление или ошибка

Индексироваться должен конечный URL с 200. Устраните циклы, длинные цепочки, нестабильные ответы и редиректы на нерелевантные страницы.

Малополезная или маловостребованная страница

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

Страница ещё не обойдена

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

Проверка JavaScript-страниц

Для Gatsby, React и других JavaScript-сайтов важно различать исходный HTML, серверный результат и содержимое после выполнения скриптов.

Что должен увидеть робот

В полученном документе или корректно отрисованной версии должны присутствовать:

• основной текст и H1;
• title и description;
• canonical;
• meta robots;
• внутренние ссылки;
• структурированные данные;
• изображения с понятными alt;
• статус 200.

Типичные проблемы

Клиентский компонент может временно установить noindex, сформировать неправильный canonical или не загрузить текст из API. При ошибке гидратации пользователь видит часть интерфейса, а инструмент проверки — пустой контейнер.

Как проверять

Сравните исходный HTML, DOM браузера и результат проверки опубликованной страницы. Посмотрите скриншот и загруженные ресурсы в Search Console. Проверьте серверные логи: получил ли Googlebot или YandexBot 200 и какой объём ответа был отправлен.

Для Gatsby: страница статьи обычно должна быть сгенерирована на этапе сборки. Если важный контент появляется только после клиентского запроса, это отдельный риск, который стоит устранить до повторной отправки URL.

Проверка после публикации и изменений

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

В день публикации

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

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

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

После миграции

Проверяйте выборки старых и новых URL, карту редиректов, canonical, sitemap, внутренние ссылки и ответы обоих хостов. Отдельно контролируйте самые трафиковые страницы и каждый тип шаблона.

Контрольный график после публикации

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

Если статус не изменился, записывайте не только итог, но и следующий проверяемый фактор. Например: «обнаружено, обхода нет — усилили внутренние ссылки» или «просканировано, не индексируется — объединили дубли и расширили полезный блок». Такой журнал отделяет реальные эксперименты от повторного нажатия одной кнопки.

Когда не нужно ждать

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

Когда страницу лучше не возвращать

Аудит иногда показывает, что исключение логично. Пустой тег, бесполезная комбинация фильтров, архив без материалов или почти идентичная городская страница не обязаны находиться в поиске. В этом случае зафиксируйте целевое состояние, уберите URL из sitemap и внутренних индексируемых маршрутов либо объедините его с полезной страницей. Качество индекса важнее максимального количества адресов.

Регулярный мониторинг индексации

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

Еженедельный контроль

Для активно меняющегося сайта отслеживайте:

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

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

Рост исключённых страниц не всегда проблема: интернет-магазин мог добавить параметры фильтрации, которые правильно закрыты. Важнее доля индексируемых канонических страниц и наличие в индексе приоритетных посадочных.

Храните историю

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

Сигналы для тревоги

Проверка нужна немедленно, если:

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

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

Ошибка 1. Доверять только site:

Оператор удобен, но неполон. Подтверждайте вывод в панелях вебмастеров.

Ошибка 2. Путать отсутствие позиции с отсутствием в индексе

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

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

Всегда смотрите конечный URL после редиректов и выбранный поисковиком canonical.

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

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

Ошибка 5. Отправлять URL повторно без исправлений

Запрос на индексирование не отменяет noindex, ошибочный canonical, пустой контент или серверную проблему.

Ошибка 6. Считать sitemap гарантией

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

Ошибка 7. Одновременно закрывать URL в robots.txt и ставить noindex

Если робот не может загрузить документ из-за robots.txt, он не увидит noindex в HTML или HTTP-заголовке. В результате URL может оставаться в поиске без сохранённого содержимого. Для удаления через noindex откройте обход страницы и проверьте, что робот получил директиву.

Ошибка 8. Проверять только главную страницу

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

Ошибка 9. Не различать Google и Яндекс

У каждой системы собственный индекс. Положительный статус в одной не подтверждает присутствие в другой.

Ошибка 10. Игнорировать качество

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

Практические сценарии диагностики

Новая статья не появилась за несколько дней

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

Статья была в поиске и исчезла

Сравните текущую и предыдущую версии: директивы, canonical, код ответа, содержание и внутренние ссылки. Проверьте, не объединил ли поисковик её с похожим материалом. Посмотрите динамику показов и дату последнего обхода.

Категория есть в Google, но отсутствует в Яндексе

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

В индексе оказался URL с параметрами

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

Сотни городских страниц индексируются частично

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

Товар временно отсутствует

Если он вернётся и страница полезна, сохраните 200, информацию о наличии и альтернативы. Не удаляйте URL автоматически и не ставьте noindex только из-за краткосрочного отсутствия. Для снятого навсегда товара выберите релевантный редирект или корректный статус.

После обновления сайта выпали статьи

Проверьте общий шаблон: SEO-компонент, meta robots, canonical, рендеринг, маршруты и ответы CDN. Массовое одновременное изменение чаще указывает на системную ошибку, чем на качество каждой статьи.

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

• Проверяется точный канонический URL.
• Страница доступна пользователю без авторизации.
• Сервер возвращает 200 OK.
• Нет цепочки или цикла редиректов.
• robots.txt разрешает необходимый обход.
• В HTML нет случайного noindex.
• В HTTP-заголовках нет X-Robots-Tag: noindex.
• Canonical указывает на правильный URL.
• Канонический адрес отвечает 200 и индексируем.
• URL включён в sitemap, если должен индексироваться.
• На страницу ведут контекстные внутренние ссылки.
• Основной контент доступен в отрисованной версии.
• Мобильный робот видит тот же важный контент.
• Google Search Console проверен по точному URL.
• Яндекс Вебмастер проверен отдельно.
• Учтена дата последнего обхода.
• Оператор site: используется только как дополнительный сигнал.
• Проверен выбранный поисковиком canonical.
• Страница обладает самостоятельной ценностью.
• После исправления выполнена проверка опубликованной версии.
• Результат повторно оценён после нового обхода.

Частые вопросы об индексации страниц

Как узнать, проиндексирована ли страница в Google?

Используйте инструмент проверки URL в Google Search Console. Статус «URL есть в Google» является главным подтверждением для сайта, к которому у вас есть доступ. Дополнительно проверьте выбранный canonical.

Как проверить индексацию в Яндексе?

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

Можно ли доверять оператору site:?

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

Почему URL есть в Search Console, но не находится по site:?

Данные и выдача обновляются по-разному, а site: показывает неполную выборку. Также проверьте точный вариант URL и canonical. Приоритет имеет подробный статус Search Console.

Через сколько индексируется новая страница?

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

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

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

Страница индексируема, но её нет в индексе. Почему?

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

Как проверить индексацию всего сайта?

Объедините данные sitemap, краулера, Search Console, Вебмастера, аналитики и логов. Сравнивайте долю индексирования по шаблонам, а не число из оператора site:.

Если страница получает показы, она точно в индексе?

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

Может ли страница быть в Google и не быть в Яндексе?

Да. Это независимые поисковые системы с разными роботами, очередями обхода и алгоритмами. Проверяйте и исправляйте причины отдельно.

Нужно ли добавлять каждую страницу в sitemap.xml?

Добавляйте канонические индексируемые URL, которые важны для поиска. Технические параметры, редиректы, ошибки, noindex и дубли в sitemap не нужны.

Что делать, если Google выбрал другой canonical?

Проверьте сходство документов, rel="canonical", редиректы, sitemap и внутренние ссылки. Все сигналы должны последовательно поддерживать нужный основной URL.

Может ли robots.txt удалить страницу из индекса?

Не следует использовать robots.txt как надёжный способ удаления уже известного URL из поиска. Закрытая страница может оставаться в базе без сохранённого содержимого, а робот не сможет прочитать noindex. Для удаления доступного документа используйте noindex при разрешённом обходе; удалённый URL должен возвращать корректный 404/410 или вести по релевантному редиректу.

Как часто проводить аудит?

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

Вывод: проверяйте статус, причину и сигналы

Надёжная проверка индексации строится на данных поисковой системы и техническом анализе страницы. Для Google используйте проверку URL в Search Console, для Яндекса — инструменты Вебмастера. Оператор site: и сторонние сервисы ускоряют выборочную проверку, но не заменяют первичные источники.

Если URL отсутствует в индексе, не ограничивайтесь кнопкой переобхода. Проверьте код ответа, robots.txt, noindex, canonical, sitemap, внутренние ссылки, отрисованный контент и самостоятельную ценность документа. Зафиксируйте дату исправления и дождитесь нового обхода. Такой порядок позволяет отличить задержку обновления от системной ошибки и не тратить время на повторные действия без результата.

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

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