Индекс раздувается: как найти страницы, которые поиску не нужны

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

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

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

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

Соберите карту ценности, а не список URL

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

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

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

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

Четыре решения для страницы, которая не выглядит сильной

После карты ценности работа становится проще. Не каждая слабая страница требует noindex, не каждый похожий URL нуждается в редиректе. Выбирайте действие по функции страницы, а не по тревожному цвету в отчете.

rel="canonical" нужен для группы дублирующих или очень похожих страниц, когда команда определила представительную версию. Google отдельно рекомендует не использовать noindex как способ выбора canonical внутри сайта: эта директива исключает URL из поиска, а не объясняет, какая версия должна стать основной. Подробнее логика сигналов разобрана в документации Google о canonical и в материале Медиакода про canonical и дубли.

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

Каноникализация отвечает на вопрос «какая версия главная», а noindex - «должна ли эта страница вообще быть в выдаче». Смешивать эти решения опасно: потом сложно объяснить, почему URL отсутствует в поиске, куда ведут ссылки и какие страницы должны быть в Sitemap.

Не превращайте robots.txt в кнопку удаления

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

Практическое правило: для каждого массового изменения заранее зафиксируйте ожидаемый сигнал: canonical, noindex, редирект или статус удаления. Тогда у задачи есть конкретная приемка, а не расплывчатая формулировка «почистить индекс».

Проверьте связи вокруг выбранного URL

Страница редко живет отдельно. Она получает ссылки из меню, тегов, карточек, подборок, Sitemap, хлебных крошек и рекламных меток. Поэтому корректный тег в head не завершает работу. Если внутренние ссылки продолжают вести на устаревший URL, а Sitemap предлагает другую версию, команда снова создает конфликт.

Если у проекта уже есть сомнения по конкретному URL, не нужно угадывать по одному site:-запросу. Пройдите диагностику индексирования: она помогает разделить проблему обхода, canonical, noindex, статуса и фактической индексации. А затем вернитесь к карте ценности: технический сигнал важен только в связке с решением, зачем страница существует.

Введите короткий цикл проверки, а не бесконечную уборку

Индекс всегда меняется вместе с сайтом. Новая функциональность создает параметры, редакторы добавляют теги, каталог получает новые фильтры, а старые страницы перестают соответствовать услугам. Одно разовое «очищение» полезно, но устойчивее работает короткий цикл: увидеть новый класс URL, выбрать действие, выпустить небольшую группу, проверить сигналы и закрепить правило в шаблоне или процессе публикации.

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

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