Проверка индексации сайта в Google: страницы в индексе и процент покрытия
Представьте, что вы купили сайт с «пятью тысячами страниц», а через неделю выясняется, что в индексе Google их меньше сотни. Или вы выкатили обновлённую структуру интернет-магазина и через месяц заметили, что трафик просел, хотя ничего «вроде бы не ломали». В обоих случаях первый вопрос звучит одинаково: сколько страниц вообще видит Google? Родительская статья этой серии уже разобрала базовые понятия и показала, что цифра из оператора site: — это ориентир, а не отчёт. Здесь мы идём дальше и разбираем, как собрать эталонный список URL, рассчитать процент покрытия по разделам и понять, какие статусы стоят за расхождениями.
Сразу зафиксируем главное различие, на котором строится вся методика. Сканирование — это визит робота на адрес, индексирование — решение сохранить страницу в базе, показ в выдаче — отдельный этап, зависящий от запроса. Страница может быть просканирована и не проиндексирована, а проиндексирована и никогда не показываться по нужным фразам. Поэтому разговор о том, сколько страниц в Google, всегда нужно вести в терминах проиндексированных URL, а процент покрытия считать относительно того, что вы сами считаете подлежащим индексации. Инструмент для быстрой оценки доступен без регистрации, а методику полезно освоить самостоятельно, чтобы проверять чужие и свои проекты одинаково. Чтобы понять, насколько сайт представлен в поиске, удобно начать с проверки того, сколько страниц сайта в индексе на данный момент, ведь именно эта цифра показывает реальную картину без догадок.
Что нужно подготовить до первой цифры
Работа начинается не с поиска, а со сбора данных. Понадобятся три источника: экспорт отчёта «Страницы» из Google Search Console с правами владельца или полного пользователя, актуальная карта сайта sitemap.xml и выгрузка всех внутренних URL из CMS или краулера вроде Screaming Frog. Без второго и третьего источника вы получите покрытие, но не будете знать, от какого числа его считать, а это главная методологическая ошибка при аудите.
Карту сайта нужно проверить на полноту. Если она собрана из sitemap-индекса, все вложенные файлы должны быть учтены, сжатые .xml.gz — распакованы. Пропуск одного файла на тридцать тысяч адресов даёт ложное покрытие: знаменатель занижен, и цифра выглядит лучше реальности. Отдельно проверьте, что карта действительно указана в robots.txt или лежит по стандартному пути, иначе автоматическая сверка её не найдёт.
- Доступ к Search Console с полномочиями, достаточными для экспорта отчёта «Страницы»
- Все файлы sitemap, включая вложенные и сжатые, с подтверждённым адресом в robots.txt
- Выгрузка внутренних URL из CMS или краулера с кодами ответа и canonical-метками
- Понимание границ версии домена: https или http, www или без www — и выбор одной основной версии для всех расчётов
- Даты последних релизов, миграций и изменений шаблонов, чтобы потом сопоставить их с динамикой индекса
Оператор site: и отчёт покрытия: что показывает каждый
Запрос site:example.com выдаёт строку «Результатов: примерно N». Эта цифра рассчитывается поисковиком по эвристике, меняется от запроса к запросу и иногда вовсе не показывается. Практическое правило простое: если вы видите только первую страницу выдачи без итогового числа, оценивать покрытие по ней нельзя. Сам оператор захватывает поддомены, поэтому для отделения основного домена используйте site:example.com -site:www.example.com, а для изоляции разделов — пути вроде site:example.com/blog/.
Отчёт «Страницы» в Search Console — единственный источник точных статусов. Он делит известные Google адреса на «Проиндексировано» и «Не проиндексировано» и указывает причину: тег noindex, «Найдена, но не просканирована», «Дубликат, пользователь выбрал другую каноническую страницу», «Мягкая ошибка 404». Отчёт показывает только адреса, которые Google знает, поэтому его нужно сверять с CMS и картой сайта. Именно из этого экспорта считается числитель, а из эталонного списка — знаменатель.
Оператор site: годится для порядка величин и для сравнения «было — стало» по одинаковой методике. Отчёт покрытия годится для диагностики и итоговой отчётности. Когда две проверки site: в течение недели дают расхождение вдвое, это повод смотреть технику, а не верить цифре. Расхождение в пределах шума означает, что ничего не изменилось.
Порядок расчёта процента покрытия от URL до цифры
Первый шаг — сформировать эталонный список, то есть решить, какие адреса вообще должны быть в индексе. В него входят канонические страницы с кодом 200, которые вы хотите видеть в поиске. Из него исключаются параметрические дубли, служебные разделы, страницы пагинации и адреса, закрытые noindex сознательно. Знаменатель формируется только из этого списка. Если делить индекс на все страницы домена, включая закрытые, покрытие будет выглядеть хуже реальности, что тоже искажает решения.
Второй шаг — сопоставить три набора: карту сайта, внутренние ссылки и данные краулера. Адреса, которые есть в CMS, но не попали в карту, и адреса, на которые не ведёт ни одна внутренняя ссылка, — это «сироты». Их индексация почти всегда слабая, потому что робот приходит к ним только по карте, а сигналов для важности у них мало. Такие адреса нужно отдельно выписать и решить, возвращать в перелинковку или закрывать.
Третий шаг — расчёт самого покрытия: количество адресов из эталонного списка, которые есть в индексе, делим на общее количество эталонных адресов и умножаем на сто. Считайте отдельно по каждому разделу, а не только по сайту целиком. Общая цифра 85% может скрывать раздел с фильтрами, где индексируется едва треть страниц, и именно он станет главной проблемой.
Четвёртый шаг — отдельно проверить адреса в индексе, которых нет в эталонном списке. Это либо забытые полезные страницы, либо мусор: фильтры, параметры сортировки, старые копии, технические дубли. Покрытие под сто процентов при большом количестве мусора в индексе — признак того, что картина маскирует проблему, поэтому одну цифру смотреть недостаточно.
Статусы исключений: как читать причины, а не только числа
Цифра покрытия отвечает на вопрос «сколько», но не на вопрос «почему». Причины раскрывают статусы Search Console, и их разница принципиальна. Статус «Обнаружено, не просканировано» означает, что Google знает адрес, но ещё не дошёл до него: проблема в очереди сканирования, скорости сайта или количестве внешних ссылок. Статус «Просканировано, не проиндексировано» говорит о том, что робот был на странице, но решил не сохранять её в базе, — чаще всего из-за тонкого или похожего на другие контента. Такой подход особенно полезен после изменений структуры или переезда, когда важно сразу увидеть, какие адреса попали в базу, а какие остались вне неё, и при необходимости перепроверить результат через Проверка индексации сайта в Google онлайн.
Статус «Дубликат, у пользователя выбрана другая каноническая страница» указывает, что вы сами или шаблон CMS передали canonical на другой адрес. Если canonical указывает не туда, из индекса выпадает нужная страница. Статус «Страница с редиректом» означает, что адрес в карте перенаправляет на другой URL, и его включение в карту уже ошибочно. Для точечной проверки каждого подозрительного адреса используйте инспекцию URL: она показывает, индексирован ли адрес, когда был последний обход и какой canonical выбрал Google.
Цифра покрытия указывает, где искать проблему. Причину показывают только статусы исключений и разбор конкретных адресов.
Что сопоставлять с индексом и на что смотреть в динамике
Полезно раскладывать индекс по типам шаблонов: категории, карточки товаров, статьи, фильтры, страницы пагинации. Соотношение индексируемых и неиндексируемых адресов внутри каждого типа показывает, где система работает, а где нет. Если все карточки товаров в индексе, но категории выпадают, проблема в структуре и перелинковке верхнего уровня. Если выпадают карточки, а категории стабильны, стоит проверить уникальность описаний и шаблон страницы товара.
Резкие изменения после релиза почти всегда связаны с техникой: noindex попал в общий шаблон, robots.txt закрыл раздел, canonical сломался при миграции. Здесь важно сопоставлять даты: откройте журнал изменений и сверьте момент падения индекса с датой выкатки. Постепенное снижение покрытия на протяжении нескольких месяцев указывает на другие причины: тонкий контент, дубли и слабую перелинковку. Смотрите динамику за четыре-восемь недель, а не разовый срез, потому что данные Search Console обновляются с задержкой и один день ничего не доказывает.
Отдельный признак — несоответствие индекса и трафика. Страницы, которые проиндексированы, но за месяц не получили ни одного показа, — сигнал о слабом качестве, неверном таргетинге или недостаточной внутренней ссылочной поддержке. Такие страницы стоит либо усилить, либо объединить с более сильными, а не оставлять висеть в индексе без пользы.
Типичные ошибки и что делать при низком покрытии
Самая распространённая ошибка — принимать приблизительную цифру из site: за окончательный ответ и на её основе решать, чистить сайт или нет. Вторая — делить индекс на неправильный знаменатель, например на все адреса домена, включая закрытые. Третья — смешивать версии домена, у каждой из которых может быть свой индекс и своя карта. Четвёртая — игнорировать поддомены, мобильные версии и параметры URL, которые как раз создают дубли. Пятая — делать разовую проверку вместо мониторинга: одна цифра ничего не говорит о динамике.
Если покрытие низкое, начинайте с очистки карты: в sitemap должны оставаться только адреса с кодом 200, без noindex и с canonical на саму себя. Затем занимайтесь внутренней перелинковкой: важные разделы должны быть доступны в один-два клика от главной и связаны с соседними материалами. Тонкие страницы с похожим текстом часто выгоднее объединить в одну содержательную, чем держать десяток почти одинаковых адресов. После изменений подождите три-четыре недели и повторите расчёт, потому что скорость индексации зависит от очереди сканирования.
Когда общая картина понятна, переходите к конкретным адресам. Чтобы понять, есть ли в индексе отдельная страница и что ей мешает, полезна точечная проверка индексации страниц через инспекцию и разбор статусов исключений. Так вы переходите от вопроса «сколько» к списку «какие и почему», а именно такой список нужен для исправления.
Итог такой: приблизительная цифра из site: даёт быстрый ориентир, карта сайта задаёт эталон для сравнения, Search Console объясняет причины, а регулярная фиксация динамики позволяет заметить падение раньше, чем оно обернётся потерей трафика. Когда эти элементы работают вместе, процент покрытия перестаёт быть абстрактной цифрой и становится рабочим инструментом: по нему видно, какие разделы требуют внимания, какие шаблоны ломаются при релизах и где начинается реальная потеря видимости.