Как настроить отчёт по проиндексированным страницам в 2026

Я обычно настраиваю отчёт по проиндексированным страницам не «для галочки», а чтобы быстро видеть, где сайт теряет трафик: лишние URL, пропавшие страницы, дубли, мусорные параметры и просевшие разделы. В 2026 году это уже не просто SEO-табличка, а нормальный рабочий контроль индексации, особенно если сайт живёт на Bitrix, WordPress или Laravel и меняется каждую неделю.

Зачем нужен отчёт по проиндексированным страницам

Если грубо говоря, индекс — это список страниц, которые поисковик считает достойными показа в выдаче. И отчёт по проиндексированным страницам помогает понять не только «сколько страниц в индексе», но и какие именно страницы туда попали.

На моей практике чаще всего всплывают такие проблемы:

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

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

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

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

Google Search Console

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

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

Если проект живёт в России или СНГ, Яндекс тоже надо держать в отчёте. У Яндекса полезно отслеживать страницы в поиске, обход, исключения, зеркала, загрузку robots.txt и ошибки обхода. Для некоторых ниш Яндекс даёт совсем другую картину, чем Google.

Внутренний краулер сайта

Я обычно добавляю сюда Screaming Frog, Netpeak Spider или аналоги. Они нужны не для подтверждения индекса, а для проверки того, что вообще доступно к индексации. То есть краулер отвечает на вопрос: «почему эта страница может попасть в индекс?»

Как собрать отчёт вручную

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

1. Берёте список URL из Sitemap.
2. Сопоставляете его с данными из Search Console и Яндекс Вебмастера.
3. Отдельно выгружаете страницы, которые реально обходятся краулером.
4. Сравниваете, что есть в sitemap, что доступно по ссылкам и что реально в индексе.

Дальше я обычно делаю простую разбивку в таблице:

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

Честно говоря, этого уже достаточно, чтобы поймать 80% типовых проблем. Главное — не пытаться сразу построить «идеальный BI-отчёт». Сначала нужен рабочий список, а потом уже красота.

Как автоматизировать отчёт

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

Через API и регулярную выгрузку

Самый нормальный вариант — забирать данные из Google Search Console API и Яндекс Вебмастера по расписанию. Дальше складывать их в таблицу, Google Sheets, базу данных или дашборд в Looker Studio, если он вам подходит.

Я обычно смотрю, чтобы в отчёте были такие срезы:

• новые проиндексированные URL за период;
• выпавшие URL;
• страницы с параметрами;
• дубли canonical;
• страницы с noindex, но попавшие в обход;
• разделы с резким ростом или падением индексации.

Через крон и внутренний парсер

Если у вас Laravel или Bitrix-проект, можно собирать такой отчёт по крону и складывать в отдельную таблицу в MySQL 8.0. Я иногда делал это и на PHP 8.1, и на PHP 8.2 — ничего сложного там нет, если не пытаться высосать из отчёта «супер-дашборд» на старте.

Смысл прост: крон ночью забирает данные, сравнивает с предыдущим снимком, помечает изменения и отправляет уведомление, если что-то пошло не так. Например, если количество индексируемых URL в категории упало больше чем на 20% за сутки, это уже повод смотреть руками.

На что смотреть в отчёте в первую очередь

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

1. Неожиданный рост индекса

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

2. Выпадение важных страниц

Если просели карточки товаров, статьи или посадочные, я смотрю на статус ответа, canonical, robots meta, noindex, карту сайта и внутреннюю перелинковку. Иногда проблема банальная: страница есть, но на неё никто не ссылается.

3. Смешение канонических версий

Бывает, что в индекс попадает не та версия страницы — с www, с параметрами, с лишним слэшем или с дублем из старой структуры. Это почти всегда лечится не отчётом как таковым, а правильной настройкой canonical, редиректов и sitemap.

4. Страницы, которые не должны индексироваться

Тут речь про корзину, личный кабинет, внутренний поиск, фильтры, тестовые разделы, staging и прочий мусор. Если они в индексе, это уже не мелочь. Это прямой сигнал к настройке noindex и nofollow или к доработке шаблонов индексации.

Для меня хороший отчёт — это тот, где сразу видно, что делать: закрывать, объединять, перенаправлять, усиливать внутренними ссылками или оставлять как есть. Если отчёт просто красивый, но не ведёт к действию, он бесполезен.

Как связать отчёт с другими проверками

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

Полезно проверить:

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

На практике самая частая связка такая: сначала я нахожу лишние URL в индексе, потом смотрю robots, потом canonical и редиректы, и только после этого лезу в sitemap. Если перепутать порядок, можно долго править не то.

Как часто обновлять отчёт

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

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

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