Агрегатные страницы фильтра и управление индексацией на 1С-Битрикс

Умный фильтр — одновременно самый мощный источник коммерческого трафика интернет-магазина и самый частый источник его SEO-проблем. Из одного раздела каталога фильтр способен породить тысячи комбинаций значений характеристик, и каждая такая комбинация — это потенциальный URL. Часть из них — золото: «смартфоны Samsung», «красные платья», «шины 205/55 R16» — люди ищут это в поиске, и под каждый такой запрос магазину выгодно иметь свою посадочную страницу. Другая часть — мусор: бессмысленные пересечения десятка параметров, сортировки, режимы отображения, служебные состояния, которые никто не ищет, но которые робот честно обходит и пытается проиндексировать. В этом и состоит двойственность фильтра: он приносит пользу и плодит мусор одним и тем же механизмом. Задача технического SEO — разделить одно и другое: открыть в индекс полезное и закрыть всё остальное. Именно об этом статья — про агрегатные страницы фильтра и управление индексацией на 1С-Битрикс.

Мы разберём всё по порядку: что такое агрегатные страницы фильтра и почему нельзя «просто открыть всё»; какие комбинации открывать в индекс (спросовые — бренд, цвет, «бренд плюс цена») и какие закрывать (много параметров, сортировки, служебные); чем чистый SEF-URL отличается от GET-параметров с точки зрения индексации; как настроить canonical и обработку пагинации; как работают Clean-param в robots для Яндекса, Disallow и noindex; что такое «бесконечные» URL и как они съедают краулинговый бюджет; как бороться с дублями фильтра и раздела; как строить шаблоны метатегов и уникализировать контент агрегатной страницы; как всё это связано с семантическим ядром и как технически настроить catalog.smart.filter в SEF-режиме. Материал вырос из практики нашей команды по SEO-продвижению интернет-магазинов на 1С-Битрикс — по делу, без обещаний «топа за неделю».

Зачем управлять индексацией фильтра

Первый вопрос, который стоит задать перед настройкой умного фильтра: какие его страницы должны попасть в поиск, а какие — нет? Если ответа нет, всё решается «по умолчанию» — а по умолчанию фильтр либо генерирует технические URL, которые робот пытается обойти, либо, наоборот, вовсе не даёт индексируемых посадочных страниц. Оба варианта плохи. Управление индексацией — это осознанный выбор: что открыть, что закрыть и какими инструментами.

Разложим, зачем вообще нужно управлять индексацией фильтра и что это даёт магазину:

• Приносит трафик по «длинному хвосту». Открытые спросовые агрегатные страницы собирают среднечастотный и низкочастотный коммерческий спрос вида «категория плюс параметр» — большой и конверсионный пласт, недоступный обычным разделам.
• Защищает от дублей. Правильная настройка не даёт тысячам почти одинаковых комбинаций попасть в индекс и размыть вес между дублями и родительским разделом.
• Экономит краулинговый бюджет. Когда мусорные URL закрыты, робот тратит ресурсы на важные страницы — карточки, категории, спросовые агрегатные страницы — и быстрее их индексирует и обновляет.
• Держит структуру чистой. В индексе оказываются только осмысленные посадочные страницы, а не технические состояния фильтра, — так проще управлять сайтом и анализировать его.
• Делает работу управляемой. Явные правила «что открываем, что закрываем» превращают хаос комбинаций в понятный список посадочных страниц под конкретные запросы.

Важно сразу задать рамку: управление индексацией фильтра — это не «включить галочку ЧПУ» и не «закрыть весь фильтр в robots». Это система из нескольких согласованных решений — какие комбинации перевести в SEF и открыть, как настроить canonical, что отдать Clean-param и Disallow, где поставить noindex, как обработать пагинацию. Каждый инструмент решает свою часть задачи, и работают они только вместе. Дальше разберём каждый по отдельности, но держите в голове главное: конечная цель — чтобы в поиске были только полезные страницы, а весь технический мусор фильтра оставался за его пределами.

Что такое агрегатные страницы фильтра

Агрегатная страница фильтра (её ещё называют SEO-страницей фасетной навигации или посадочной страницей фильтра) — это самостоятельная страница каталога, которая собирает товары по одной или нескольким выбранным характеристикам и оптимизирована под конкретный поисковый запрос. Не «весь раздел смартфонов», а «смартфоны Samsung»; не «все платья», а «красные платья»; не «все шины», а «шины 205/55 R16». Слово «агрегатная» — от «агрегировать», собирать: страница агрегирует подмножество каталога по заданному признаку.

Чтобы техническое состояние фильтра стало полноценной агрегатной страницей, ему нужно несколько вещей:

• Чистый ЧПУ (SEF-URL). Человекопонятный адрес вида /katalog/smartfony/samsung/, а не набор GET-параметров. Это делает страницу «настоящей» для поиска и для пользователя.
• Уникальные метатеги. Свои title, description и H1, отражающие именно эту комбинацию, а не общий раздел. Обычно генерируются по шаблону на основе выбранных фасетов.
• Вводный текст и контент. Хотя бы небольшой уникальный блок, отличающий страницу от родительского раздела и других комбинаций.
• Открытость для индексации. Страница явно разрешена к обходу и попаданию в поиск (в отличие от закрытых мусорных комбинаций).
• Корректный canonical. Указание на саму себя как на основную страницу этой выборки (а не на родительский раздел).

Ключевое отличие агрегатной страницы от «просто применённого фильтра» — в намеренности. Обычная работа фильтра — это интерактивное состояние: пользователь тыкает галочки, URL меняется, но это техническая выборка, не рассчитанная на индексацию. Агрегатная же страница — это заранее отобранная, подкреплённая спросом комбинация, которой осознанно придали статус посадочной: дали адрес, метатеги, текст и открыли для поиска. Один и тот же механизм умного фильтра обслуживает и то, и другое — поэтому вся сложность SEO здесь в том, чтобы отделить намеренные, полезные страницы от бесконечного множества технических состояний. Об этой двойственности — следующий раздел.

Проблема умного фильтра для SEO

Умный фильтр создаёт для SEO уникальную ситуацию: один и тот же инструмент одновременно источник огромной пользы и источник огромного мусора. Понять эту двойственность — значит понять, зачем вообще нужно управление индексацией. Разберём обе стороны.

Польза. Спрос в магазине многомерен: одну категорию ищут по бренду, цвету, размеру, цене, назначению и десяткам других признаков и их сочетаний. Обычные разделы каталога закрывают только широкие запросы («смартфоны», «платья»), а весь «длинный хвост» коммерческих запросов вида «категория плюс параметр» — «смартфоны Samsung до 30000», «красные платья в пол» — остаётся без своих страниц. Фильтр позволяет закрыть этот спрос почти без ручного создания разделов: любую комбинацию можно превратить в агрегатную страницу. Это самый большой резерв конверсионного трафика в магазине, потому что такие запросы конкретны, близки к покупке и менее конкурентны, чем широкие категории.

Мусор. Обратная сторона той же гибкости — комбинаторный взрыв. Каждый фасет умножается на все остальные: если в разделе десяток характеристик и у каждой несколько значений, число теоретических комбинаций исчисляется десятками и сотнями тысяч. Добавьте диапазоны цен с мелким шагом, сортировки, режимы отображения, постраничную навигацию, перестановки и повторы параметров — и множество URL становится практически бесконечным. Подавляющее большинство этих адресов никто не ищет, они почти дублируют друг друга и родительский раздел, но робот идёт по внутренним ссылкам фильтра и пытается всё это обойти и проиндексировать.

В этом и заключается проблема: польза и мусор рождаются одним механизмом. Нельзя просто «включить фильтр для SEO» — вы получите и трафикоприносящие страницы, и тысячи дублей. Нельзя и «закрыть весь фильтр» — потеряете весь длинный хвост коммерческого спроса. Единственный рабочий путь — избирательность: открыть в индекс осознанно отобранные полезные комбинации и целенаправленно закрыть всё остальное. Как отличить одно от другого и какими инструментами это реализовать — предмет всей остальной статьи. Общий принцип фасетной навигации и её связи с SEO мы разбирали в отдельном материале про фасетную навигацию и SEO — эта статья продолжает тему уже с фокусом на управлении индексацией.

Какие комбинации открывать в индекс

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

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

Ещё один критерий, помимо частотности, — содержательность выборки. Комбинацию стоит открывать, если она возвращает достаточное число товаров и заметно отличается от родительского раздела. Если фасет отбирает две-три позиции или почти совпадает с разделом по составу, отдельная страница под него мало что даёт и рискует стать «тонкой» малоценной страницей. Поэтому финальное решение — на пересечении двух условий: есть спрос (из семантического ядра) и есть содержательная, отличимая выборка товаров. Всё, что этим критериям не отвечает, идёт в закрытие — о нём следующий раздел.

Какие комбинации закрывать

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

• Комбинации из многих параметров. Сочетания трёх и более фасетов почти никогда не имеют спроса, зато их комбинаторно бесконечно много. «Смартфоны Samsung чёрные 128 ГБ 6.5 дюймов с NFC до 40000» — такую фразу в поиск не вводят. Закрывают.
• Сортировки. Порядок вывода (по цене, по популярности, по новизне) не меняет содержимое выборки — это одни и те же товары в другом порядке. Отдельные URL под сортировки — чистые дубли.
• Режимы отображения. Количество товаров на странице, вид «список/плитка», размер превью — техническое состояние, не влияющее на смысл. В индекс не пускают.
• Служебные параметры и метки. Идентификаторы сессий, метки переходов (utm и подобные), параметры сравнения, отложенного, состояния «применить фильтр» — всё это технический шум.
• Диапазоны цен с мелким шагом. Произвольные ценовые интервалы порождают бесконечное множество почти одинаковых URL. Открывают, если вообще, только несколько заранее заданных востребованных диапазонов, остальное закрывают.
• Пустые и «тонкие» выборки. Комбинации, возвращающие ноль или единицы товаров, — малоценные страницы; их не индексируют.
• Пагинация как самостоятельные страницы. Страницы 2, 3, 4… — не посадочные под запрос; их обрабатывают отдельно (об этом дальше), но как отдельные индексируемые агрегатные страницы не открывают.

Логика простая и её удобно держать в голове одной фразой: открываем осмысленное и востребованное, закрываем техническое и невостребованное. Всё, что меняет только форму подачи (сортировка, отображение), а не состав выборки, — дубль. Всё, что порождает бесконечное множество (мелкие диапазоны, глубокие комбинации), — ловушка для краулера. Всё, чего никто не ищет, — балласт в индексе. Ниже разберём конкретные инструменты, которыми это закрывается: SEF против GET, canonical, Clean-param, Disallow, noindex. Но принцип отбора именно такой, и он важнее любого отдельного инструмента.

SEF-URL фильтра против GET-параметров

Одно из самых важных технических различий в этой теме — между чистым ЧПУ (SEF-URL) и адресом с GET-параметрами. От того, в каком виде живёт страница фильтра, напрямую зависит, можно ли её нормально индексировать. Сравним оба формата.

Суть в том, что это две разные сущности, а не два написания одного адреса. Чистый SEF-URL — это витрина: под ним живёт спросовая агрегатная страница, которую вы хотите видеть в поиске, на которую ставите внутренние ссылки, которую прописываете в карту сайта и снабжаете уникальными метатегами. GET-адрес — это «кухня»: техническое состояние, которое возникает, когда пользователь интерактивно перебирает фасеты. Один и тот же выбор «смартфоны Samsung» может существовать в обоих видах, но в индексе должен быть только чистый.

Отсюда практическая стратегия: спросовые комбинации переводят в SEF-режим и открывают именно чистые адреса, а параметрические URL самого фильтра (то, что генерируется при интерактивном переборе) закрывают от индексации. При этом важно не допустить, чтобы одна выборка была доступна и по ЧПУ, и по GET одновременно как две индексируемые страницы — это прямой дубль. Механизмы разведения (canonical, Clean-param, Disallow) разберём в следующих разделах. А в 1С-Битрикс за перевод фильтра в SEF отвечает настройка компонента catalog.smart.filter — о ней в разделе про практику. Пока запомните главное правило: в индексе — только чистые SEF-URL спросовых комбинаций, параметрический фильтр — вне индекса.

Индексация ЧПУ и служебных параметров

Даже когда спросовые комбинации переведены в SEF, к чистому адресу почти всегда «прилипают» служебные параметры: сортировка, режим показа, метки переходов, параметры пагинации. Важно понимать, как поиск относится к таким «хвостам» и почему их нужно отдельно обрабатывать.

Проблема в том, что любой добавленный параметр формально создаёт новый URL, а значит потенциальный дубль. Адреса /smartfony/samsung/, /smartfony/samsung/?sort=price и /smartfony/samsung/?show_by=60 для поиска — три разных адреса, хотя содержимое у них по сути одно и то же (те же товары, лишь в другом порядке или количестве на странице). Если ничего не делать, робот обойдёт все три, попытается их проиндексировать и либо сочтёт дублями (потратив бюджет), либо, хуже, проиндексирует лишние варианты.

Служебные параметры удобно разложить на группы по тому, как с ними поступать:

Общий принцип: чистый SEF-URL спросовой комбинации — единственный индексируемый вариант, а все параметрические «хвосты» к нему должны либо не создавать отдельной индексируемой страницы (canonical ведёт на чистый адрес), либо вовсе не обходиться роботом (Disallow, Clean-param для Яндекса). Дальше разберём каждый инструмент — canonical, пагинацию, Clean-param, Disallow, noindex — по отдельности, но держите в голове цель: за каждой выборкой в поиске стоит ровно один чистый адрес, а вся служебная «обвязка» вокруг него нейтрализована.

Canonical для страниц фильтра

Атрибут rel="canonical" — один из главных инструментов управления дублями фильтра. Он указывает поисковой системе, какой URL считать основным среди похожих. На страницах фильтра важно применять его избирательно, потому что и переусердствовать, и недоглядеть здесь одинаково вредно.

Правильная логика canonical для фильтра выглядит так:

• Спросовая агрегатная страница — canonical на себя. Открытая SEF-страница вроде /smartfony/samsung/ получает canonical на собственный чистый URL. Она самостоятельная посадочная и должна индексироваться отдельно, собирая свой трафик.
• Служебные «хвосты» — canonical на чистый URL. Варианты с сортировкой, режимом показа, метками (?sort=price, ?show_by=60, ?utm_...) указывают canonical на чистый адрес без этих параметров.
• Мусорные комбинации без спроса — canonical на канон. Глубокие сочетания фасетов, которые не открывают отдельно, указывают canonical на ближайшую осмысленную открытую страницу — на подходящую агрегатную или на родительский раздел.
• Параметрический фильтр — canonical на раздел или чистую страницу. Интерактивные GET-состояния фильтра канонизируют на соответствующий чистый адрес.

Ещё один нюанс — canonical это рекомендация, а не жёсткая директива: поисковая система учитывает её вместе с другими сигналами и может проигнорировать при противоречиях. Поэтому canonical не работает в одиночку. Его подкрепляют согласованными сигналами: закрытые комбинации не должны получать внутренних ссылок как посадочные, должны иметь корректные метатеги, а где нужно — Clean-param и Disallow. Когда все сигналы говорят поиску одно и то же («вот эта страница основная, а эти — её служебные варианты»), канонизация работает надёжно. Противоречивые сигналы (canonical на раздел, но при этом страница в sitemap и с уникальными метатегами) сбивают поиск с толку.

Пагинация: rel-next/prev и «Показать ещё»

Постраничная навигация внутри раздела или агрегатной страницы — отдельный источник дублей и вопросов по индексации. Когда товаров много, они разбиваются на страницы 2, 3, 4… и каждая — это новый URL (обычно с параметром вроде PAGEN_1). Как их индексировать — тема, по которой рекомендации со временем менялись, поэтому разберём аккуратно.

Ключевая идея: страницы пагинации — не самостоятельные посадочные страницы под запрос. Никто не ищет «смартфоны Samsung страница 3». Поэтому цель — чтобы в поиске фигурировала первая (основная) страница выборки, а остальные не создавали дублей и не размывали её сигналы. Есть несколько подходов, и их часто комбинируют:

• rel="next" / rel="prev". Исторически — разметка связи между страницами последовательности, подсказывавшая поиску, что это части одного набора. Сейчас её роль как сигнала снизилась, но как аккуратная разметка навигации она не вредит и её нередко оставляют.
• Canonical страниц пагинации. Распространённый подход — canonical со всех страниц пагинации на первую (основную). Он гасит дубли, но есть нюанс: товары со вторых страниц могут хуже попадать в обход, поэтому подход применяют с оглядкой на глубину каталога.
• Self-canonical + доступность для обхода. Альтернатива — каждая страница пагинации канонична сама на себя и доступна роботу для обхода (чтобы он дошёл до всех товаров), но при этом не оптимизируется под запрос и обычно не даёт метатеговых дублей за счёт шаблона.
• «Показать ещё» и бесконечная прокрутка. Если товары догружаются скриптом, важно, чтобы под этим была нормальная постраничная навигация обычными ссылками — иначе робот не доберётся до товаров с глубоких «страниц».

Практический ориентир для магазина на 1С-Битрикс: первая страница выборки — основная и индексируемая; страницы пагинации не должны плодить дубли метатегов (в шаблоне к title/description добавляют признак номера страницы или канонизируют на первую); товары со всех страниц должны быть доступны роботу для обхода — либо через доступную пагинацию, либо через карту сайта. Конкретную схему выбирают под глубину каталога и поведение робота, но принцип общий: пагинация обслуживает доступность товаров, а не создаёт новые посадочные страницы. Подробнее вопросы дублей, канонических адресов и индексации мы разбирали в материале про технический SEO-аудит магазина на 1С-Битрикс.

Clean-param в robots для Яндекса

Clean-param — специальная директива файла robots.txt, которую понимает Яндекс. Она сообщает роботу, что перечисленные GET-параметры не влияют на содержимое страницы, поэтому их нужно игнорировать: не обходить лишние варианты и склеивать все URL с этими параметрами в один адрес без них. Для магазина с фильтром это точечный и удобный инструмент против параметрического мусора.

Синтаксис простой: Clean-param: p0[&p1&p2&...] [path], где через & перечисляют параметры, а необязательный путь ограничивает область действия. Несколько примеров, что обычно отдают Clean-param в магазине:

• Сортировки и отображение: Clean-param: sort&order&show_by — робот не плодит отдельные URL под каждый порядок и режим показа.
• Метки трафика: Clean-param: utm_source&utm_medium&utm_campaign&gclid — рекламные метки не создают дублей.
• Состояния фильтра: Clean-param: set_filter&del_filter — служебные флаги применения фильтра не индексируются как отдельные страницы.

Чем Clean-param удобнее, чем закрытие тех же URL через Disallow: при Disallow робот просто перестаёт обходить адрес, а накопленные им сигналы (например, ссылки на такой URL) могут теряться; Clean-param же явно склеивает варианты в один канонический адрес и переносит на него показатели. Поэтому для параметров, которые именно «загрязняют» существующие полезные страницы (метки, сортировки), Clean-param часто предпочтительнее.

Важно помнить границы применимости. Clean-param — инструмент только Яндекса. Google эту директиву не поддерживает; там управление параметрами строится на canonical, robots и внутренней логике поиска. Поэтому Clean-param — это не замена остальным инструментам, а часть системы: для Яндекса добавляете Clean-param на параметрический шум, а корректный canonical, разумный Disallow и чистые SEF-URL под спрос работают на обе системы. Настраивая robots, держите в голове, что у поисковиков разные механизмы, и стройте правила так, чтобы результат — «в индексе только полезные чистые страницы» — достигался для каждого из них своими средствами.

robots.txt и Disallow для фильтра

Файл robots.txt управляет обходом: директива Disallow запрещает роботу скачивать URL, попадающие под указанный шаблон. Для фильтра это грубый, но нужный инструмент — им закрывают целые классы технических адресов от обхода, экономя краулинговый бюджет. Но именно из-за «грубости» с ним легко навредить, поэтому разберём аккуратно.

Что обычно закрывают в robots.txt у магазина на 1С-Битрикс:

• Параметрические состояния фильтра. Правила, отсекающие URL с параметрами применения фильтра и служебными «хвостами», чтобы робот не обходил интерактивные состояния.
• Технические разделы движка. Служебные пути /bitrix/, /local/, личный кабинет, корзину, сравнение, оформление заказа, поиск по сайту — всё, что не должно быть в индексе.
• Действия и AJAX-эндпоинты. URL добавления в корзину, в избранное, обработчики форм — не контент, а действия.

Главная опасность Disallow — закрыть лишнее. Если правило написано слишком широко, под него легко попадают полезные спросовые агрегатные страницы. Например, неаккуратный запрет всего, что содержит определённый сегмент пути, может заодно закрыть чистые SEF-URL комбинаций, которые вы хотели видеть в индексе. Поэтому правила пишут точечно и обязательно проверяют, что под них не попадают открытые агрегатные страницы. Ещё тонкость: Disallow запрещает обход, но не гарантирует отсутствие в индексе — закрытый в robots URL, на который есть внешние ссылки, иногда всё же попадает в поиск «без содержимого». Для гарантированного исключения из индекса нужен noindex (о нём дальше), а его робот увидит, только если страница НЕ закрыта в robots. Отсюда важное следствие: нельзя одновременно и закрывать страницу в robots, и рассчитывать, что поиск увидит на ней noindex, — эти инструменты применяют к разным случаям.

Практический вывод: robots.txt используют для запрета обхода массового технического мусора и служебных разделов, а тонкое управление индексацией отдельных страниц (что должно быть в поиске, что нет) отдают canonical и noindex. И обязательно после правок проверяют файл инструментами веб-мастеров: не закрыты ли важные страницы, корректно ли составлены директивы для Яндекса и Google. Ошибка в одной строке robots способна выкинуть из индекса целые разделы, поэтому этот файл правят внимательно и с проверкой.

noindex мусорных комбинаций

Метатег <meta name="robots" content="noindex, follow"> (или аналогичный заголовок X-Robots-Tag) — это прямое указание поисковой системе не включать страницу в индекс. В отличие от robots, который управляет обходом, noindex управляет именно присутствием в поиске, и это делает его точным инструментом для мусорных комбинаций фильтра.

Где noindex уместен на страницах фильтра:

• Комбинации без спроса, которые робот всё же может обойти. Глубокие сочетания фасетов, которые вы не открываете как агрегатные, но которые доступны по внутренним ссылкам, помечают noindex, чтобы они гарантированно не попали в индекс.
• Пустые и «тонкие» выборки. Комбинации, вернувшие ноль или единицы товаров, — кандидаты на noindex как малоценные страницы.
• Служебные страницы результата фильтрации, которые по каким-то причинам должны оставаться доступными пользователю, но не должны индексироваться.

Важный технический момент — сочетание noindex и robots. Чтобы поиск увидел noindex, он должен иметь возможность скачать страницу, а значит она НЕ должна быть закрыта в robots.txt. Если вы одновременно запретили обход в robots и поставили noindex в метатеге, робот просто не дойдёт до метатега и не узнает о запрете индексации. Поэтому для одной группы URL выбирают что-то одно: либо закрывают обход в robots (для массового технического мусора, который не жалко «не показывать» роботу), либо оставляют доступным для обхода и ставят noindex (для страниц, которые нужно точечно исключить из индекса, но позволить роботу их увидеть и пройти по ссылкам дальше — отсюда follow).

Практический баланс для фильтра такой: массовый параметрический шум и служебные разделы — через robots (Disallow) и Clean-param; отдельные мусорные комбинации, которые остаются в навигации, — через noindex; спросовые агрегатные страницы — открыты и с canonical на себя. Три инструмента делят между собой зоны ответственности и не конфликтуют, если понимать, какой из них к какому случаю применять. Именно согласованность этих сигналов и отличает грамотно настроенный фильтр от «закрыли всё в robots и надеемся».

Бесконечные URL и краулинговый бюджет

Одна из самых коварных проблем фильтра — так называемые бесконечные URL, они же ловушки для краулера (crawler traps). Речь о ситуации, когда фильтр порождает практически неограниченное множество адресов, по которым робот может ходить бесконечно, так и не добравшись до по-настоящему важных страниц. Разберём, откуда они берутся и чем опасны.

Источники «бесконечности» в фильтре:

• Комбинаторный взрыв фасетов. Любые сочетания значений характеристик — это экспоненциально растущее число URL. Робот, идущий по ссылкам фильтра, генерирует всё новые и новые комбинации.
• Диапазоны цен с шагом. Произвольные ценовые интервалы (от-до с мелким шагом) дают почти непрерывное множество адресов.
• Перестановки и повторы параметров. Один и тот же набор фильтров в разном порядке или с повторами формально даёт разные URL.
• Сцепление с пагинацией и сортировками. Каждая комбинация умножается на страницы пагинации и варианты сортировки — и множество разрастается ещё кратно.

Теперь про краулинговый бюджет (crawl budget) — условный объём ресурсов, который поисковая система готова потратить на обход вашего сайта за период. Он не бесконечен: у робота есть лимиты и на частоту запросов, и на общее число обходимых страниц. Когда бюджет уходит на десятки тысяч мусорных URL фильтра, важные страницы — карточки товаров, категории, спросовые агрегатные страницы — обходятся реже, позже попадают в индекс и медленнее обновляются. Для крупного магазина это ощутимая потеря: новинки и изменения цен долго не отражаются в поиске, а часть глубоких карточек робот может вовсе не успевать обходить.

Как закрывают ловушки и берегут бюджет:

1. Не давайте роботу лишних ссылок. Внутри интерфейса фильтра ссылки на непредназначенные для индексации комбинации делают недоступными для обхода (например, не обычными href, а через скрипт), чтобы робот по ним не расползался.
2. Закройте параметрический шум. Сортировки, отображение, метки, состояния фильтра — через Clean-param (Яндекс) и Disallow, чтобы под них не плодились URL.
3. Ограничьте глубину комбинаций. Индексируемы только заранее отобранные спросовые страницы; всё глубже — noindex или недоступно для обхода.
4. Уберите бесконечные диапазоны. Вместо произвольных ценовых интервалов оставляют несколько фиксированных востребованных, остальное не индексируют.
5. Дайте роботу карту важного. В sitemap.xml перечисляют именно нужные страницы (категории, спросовые агрегатные, карточки), направляя обход на ценное.

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

Дубли фильтра и раздела каталога

Отдельная и очень частая проблема — дубли между страницей фильтра и родительским разделом каталога. Возникает она незаметно и бьёт по обеим страницам сразу, поэтому важно понимать её механику и как её гасить.

Классический сценарий: есть раздел /smartfony/ и есть агрегатная страница /smartfony/samsung/. Всё в порядке — это разные выборки. Но проблемы начинаются, когда одна и та же выборка становится доступна по нескольким адресам. Типичные источники таких дублей:

• Фильтр по единственному значению, совпадающий с разделом. Если у раздела фактически один бренд или одно значение характеристики, страница фильтра по нему дублирует сам раздел по составу товаров.
• Одна выборка по ЧПУ и по GET одновременно. /smartfony/samsung/ и /smartfony/?arrFilter...=samsung — два адреса одной выборки; если оба индексируются, это прямой дубль.
• Разный порядок фасетов. /smartfony/samsung/chernyy/ и /smartfony/chernyy/samsung/ — одна и та же выборка под двумя URL.
• Пагинация и сортировки поверх выборки. Обсуждали выше — те же товары под множеством адресов.
• Пересечение агрегатной страницы и подкатегории. Если под один и тот же признак есть и подкатегория в дереве, и страница фильтра, они конкурируют за один интент.

Чем опасны такие дубли: поисковая система видит несколько почти одинаковых страниц и не понимает, какую показывать. Она «размазывает» сигналы между ними, и в итоге ни раздел, ни страница фильтра не ранжируются так, как могла бы одна сильная страница. В худшем случае в выдачу попадает «не та» версия (например, параметрический URL вместо чистого ЧПУ), и пользователь видит технический адрес.

Как разводят дубли фильтра и раздела на практике: во-первых, каждая выборка должна иметь ровно один индексируемый адрес — чистый SEF-URL, а все прочие варианты (GET, другой порядок фасетов, сортировки) канонизируют на него; во-вторых, фиксируют порядок фасетов в ЧПУ, чтобы одна выборка не порождала перестановочные дубли; в-третьих, следят, чтобы под один интент не существовало и подкатегории, и страницы фильтра одновременно — выбирают что-то одно (об этом — в разделе про связь с семантикой). Ключевой принцип тот же, что во всём SEO каталога: один интент — один URL. Когда каждой выборке и каждому запросу соответствует ровно одна страница, дубли фильтра и раздела просто не возникают.

Шаблоны метатегов агрегатных страниц

Агрегатных страниц много — десятки и сотни на крупный магазин. Прописывать каждой title, description и H1 вручную нереально, поэтому их генерируют по шаблонам на основе выбранных фасетов. Хороший шаблон — тот, что даёт уникальные и осмысленные метатеги, а не одинаковые «купить {товар}» на весь каталог.

Из чего состоит шаблон метатегов агрегатной страницы:

• Переменные фасетов. Подстановки вроде названия раздела, бренда, цвета, размера, ценового диапазона — то, что отличает эту комбинацию от других.
• Каркас фразы. Устойчивая конструкция, в которую подставляются фасеты: «{Раздел} {Бренд} — купить в {Город}», «{Цвет} {раздел}: цены и наличие».
• Коммерческие маркеры. «купить», «цена», «доставка», «в наличии» — под коммерческий интент запроса.
• Динамические элементы. Количество товаров, диапазон цен, наличие — если они корректно подставляются, метатег становится живым и уникальным.

Ключевой принцип — уникальность и релевантность каждого сгенерированного метатега. Если шаблон один на все страницы и просто подставляет название комбинации в шаблонную фразу, есть риск получить массу однотипных title, которые поиск сочтёт малоценными. Поэтому шаблоны делают достаточно гибкими: разные каркасы для разных типов фасетов (бренд, цвет, цена), учёт числа товаров, подстановка города для гео-версий. И обязательно предусматривают возможность ручного переопределения — для важных, высокоспросовых агрегатных страниц метатеги дописывают руками, а шаблон оставляют для массы средне- и низкочастотных.

Тема шаблонов метатегов для фильтра большая и заслуживает отдельного разбора — как строить каркасы, какие переменные подставлять, как избегать однотипности и как всё это реализуется на 1С-Битрикс. Мы подробно разобрали её в отдельном материале про SEO-шаблоны метатегов для страниц фильтра. Здесь важно зафиксировать связь: индексация и метатеги работают в паре — открытая для поиска агрегатная страница обязательно должна иметь уникальные, осмысленные метатеги, иначе открытость не даст трафика, а лишь добавит в индекс «пустую» с точки зрения оптимизации страницу.

Уникализация контента: H1 и текст

Открытая для индексации агрегатная страница должна отличаться от родительского раздела и от других комбинаций не только метатегами, но и содержимым. Иначе поиск справедливо сочтёт её малоценным дублем. Уникализация контента — то, что превращает «применённый фильтр» в полноценную посадочную страницу.

Что уникализируют на агрегатной странице:

• H1. Заголовок должен отражать именно эту комбинацию: «Смартфоны Samsung», «Красные платья», а не общий «Смартфоны» или «Каталог». H1 обычно генерируется по тому же принципу, что метатеги, но остаётся человеческим и читаемым.
• Вводный текст. Небольшой уникальный блок про эту выборку: чем хороши смартфоны именно этого бренда, что учесть при выборе платья этого цвета. Даже пара абзацев отличают страницу от раздела.
• Хлебные крошки. Путь навигации, отражающий место страницы: Каталог → Смартфоны → Samsung. Помогает и пользователю, и поиску понять иерархию.
• Сама выборка товаров. Уже уникальна по составу, но важно, чтобы она была содержательной (достаточно товаров) и действительно отличалась от раздела.
• Перелинковка. Ссылки на смежные осмысленные комбинации (другие бренды, другие цвета) и на родительский раздел — это и навигация, и распределение веса.

Практический вывод: связка «открыто для индексации + уникальные метатеги + уникальный H1 и хотя бы минимальный контент» — это и есть определение полноценной агрегатной страницы. Открыть комбинацию без уникализации — значит добавить в индекс дубль раздела. Уникализировать, но не открыть — значит сделать страницу, которую никто не увидит в поиске. Оба элемента нужны вместе, поэтому решения об открытии индексации и о наполнении страницы принимают заодно, для одного и того же списка спросовых комбинаций.

Связь с семантикой: только под спрос

Мы много раз повторили: открывают только спросовые комбинации. Пора объяснить это прямо — управление индексацией фильтра невозможно без семантического ядра. Именно ядро отвечает на главный вопрос: какие комбинации ищут, а какие нет. Без него решение «открыть или закрыть» превращается в гадание.

Как семантика управляет индексацией фильтра:

• Ядро даёт список кандидатов в агрегатные страницы. Из семантики видно, какие сочетания «категория плюс параметр» реально ищут — это и есть комбинации, которые стоит открыть и оптимизировать.
• Ядро отсекает мусор. Комбинации, под которые нет запросов, остаются закрытыми. Не «закрываем всё подряд», а «закрываем то, чего не ищут», — а это знание даёт именно ядро.
• Ядро задаёт метатеги и H1. Центральный запрос кластера ложится в основу title, H1 и текста агрегатной страницы — страница оптимизируется под реальную формулировку.
• Ядро предотвращает каннибализацию. Карта релевантности «запрос → URL» показывает, чтобы под один интент не было и подкатегории, и страницы фильтра, — иначе они конкурируют.

Особенно важна развилка «подкатегория или страница фильтра». Один и тот же признак иногда можно реализовать и как раздел в дереве каталога, и как агрегатную страницу фильтра. Если сделать оба — получите дубль и каннибализацию. Решает семантика и логика структуры: устойчивую самостоятельную группу товаров, которую логично видеть в дереве («игровые ноутбуки»), делают подкатегорией; одно из значений характеристики, которое комбинируется с другими (бренд, цвет, цена), — страницей фильтра. Главное — под один интент ровно один URL.

Отсюда порядок работы: сначала собирают и кластеризуют семантическое ядро, из него получают список спросовых комбинаций и карту релевантности, и только потом настраивают индексацию фильтра под этот список. Пытаться управлять индексацией «от техники», не зная спроса, — значит либо открыть лишнее, либо закрыть нужное. Как собирать и кластеризовать ядро магазина, распределять кластеры по типам страниц и строить карту релевантности, мы подробно разобрали в статье про семантическое ядро интернет-магазина на 1С-Битрикс. Управление индексацией фильтра — это техническая реализация решений, которые принимает семантика.

Настройка catalog.smart.filter в SEF

Перейдём к практике на платформе. За умный фильтр в 1С-Битрикс отвечает компонент bitrix:catalog.smart.filter, а за отображение отфильтрованных товаров — bitrix:catalog.section. Чтобы фильтр давал индексируемые агрегатные страницы, а не только интерактивные GET-состояния, его переводят в SEF-режим (человекопонятные URL). Разберём, что для этого делают.

1. Включите SEF-режим фильтра. В настройках компонента catalog.smart.filter активируют работу через ЧПУ и задают шаблон SEF-URL (по какому пути формируются адреса комбинаций относительно раздела).
2. Настройте соответствие фасетов и сегментов URL. Определяют, какие свойства и значения участвуют в формировании ЧПУ и в каком порядке они идут в адресе, чтобы одна выборка не давала перестановочных дублей.
3. Задайте правила открытия комбинаций. Отмечают, какие комбинации становятся индексируемыми агрегатными страницами (по списку из семантики), а какие остаются техническими и закрываются.
4. Подключите шаблоны метатегов и текста. Настраивают генерацию title, description, H1 и вводного текста для агрегатных страниц по фасетам (часто через SEO-свойства инфоблока и правила подстановки).
5. Настройте canonical. Спросовые агрегатные страницы канонизируют на себя, служебные «хвосты» и параметрический фильтр — на чистый URL или раздел.
6. Пропишите robots и Clean-param. В robots.txt закрывают параметрические состояния и служебные разделы, для Яндекса добавляют Clean-param на сортировки, метки и состояния фильтра.
7. Добавьте нужные страницы в sitemap. В карту сайта включают спросовые агрегатные страницы, категории и карточки, направляя обход робота на ценное.

Часть этих задач решается штатными средствами Битрикса (SEF-режим компонента, SEO-свойства разделов и инфоблоков, настройки ЧПУ), часть — доработкой шаблона и логики (правила открытия комбинаций, гибкие шаблоны метатегов, управление canonical). На практике для среднего и крупного магазина настройку индексации фильтра обычно выносят в отдельный управляемый механизм: список спросовых комбинаций (из семантики) хранится и сопоставляется с ЧПУ, а всё, чего в списке нет, автоматически получает noindex/canonical на канон. Такой подход масштабируется и не требует ручной пометки каждой комбинации.

Важно тестировать результат: после настройки проверяют, что спросовые комбинации отдают чистый SEF-URL с кодом ответа 200 и уникальными метатегами, что параметрический фильтр не индексируется, что canonical проставлен корректно, а robots не закрывает лишнего. Ошибки в настройке фильтра особенно коварны, потому что затрагивают не одну страницу, а сразу целый класс URL, — поэтому изменения вносят аккуратно и с проверкой на тестовом окружении.

Правила индексации: как решать

Сведём всё в понятный алгоритм принятия решения по каждой комбинации фильтра. Когда правил много (SEF, canonical, robots, Clean-param, noindex), легко запутаться, поэтому полезно иметь единую матрицу «тип URL → что делаем».

Читать матрицу удобно так: сначала спрашиваем «есть ли под эту комбинацию спрос и содержательная выборка?». Если да — открываем как агрегатную страницу (SEF, canonical на себя, метатеги, текст). Если нет — закрываем, а метод закрытия зависит от природы URL: параметрический шум и служебные разделы — через robots и Clean-param; отдельные мусорные комбинации, оставшиеся в навигации, — через noindex; дублирующие «хвосты» — через canonical на канон.

Главное, чтобы правила были согласованы между собой и не противоречили друг другу. Типичные конфликты, которых избегают: closed в robots + noindex одновременно (робот не увидит noindex); canonical на раздел у полезной страницы (вылетит из индекса); открытая в индекс страница без уникальных метатегов и текста (дубль). Когда матрица применяется последовательно и сигналы не спорят друг с другом, индексация фильтра становится предсказуемой: в поиске оказывается ровно то, что вы задумали, а весь технический мусор остаётся за его пределами. Эту матрицу удобно закрепить в регламенте проекта и сверяться с ней при каждом изменении фильтра.

Мониторинг индексации в Вебмастере

Настроить индексацию — половина дела; вторая половина — регулярно проверять, что всё работает как задумано. Индексация фильтра меняется при каждой правке структуры, добавлении товаров и характеристик, поэтому мониторинг ведут постоянно. Основные инструменты — панели веб-мастеров поисковых систем.

Что смотрят в Яндекс.Вебмастере:

• Страницы в поиске. Попали ли в индекс нужные спросовые агрегатные страницы; нет ли там мусорных комбинаций и параметрических URL.
• Исключённые страницы и причины. «Дубль», «Малоценная или маловостребованная», «Запрещено в robots», «Неканоническая» — по причинам видно, правильно ли отрабатывают ваши правила.
• Статистика обхода. Сколько и каких URL скачивает робот; если большая доля обхода уходит на параметрический мусор — ловушки не закрыты.
• Мониторинг Clean-param и robots. Проверка, что директивы применяются корректно и не закрывают лишнего.

Что смотрят в Google Search Console:

• Отчёт об индексировании страниц. Группировка по статусам: проиндексировано, не проиндексировано и почему.
• Причины исключения. «Страница просканирована, но пока не проиндексирована», «Обнаружена, но не просканирована», «Дубль, канонический вариант выбран Google», «Дубль без canonical», «Исключено тегом noindex», «Заблокировано в robots.txt».
• Статистика сканирования. Динамика обхода — не тратит ли робот ресурсы на мусор.
• Проверка URL. Точечная диагностика конкретной агрегатной страницы: как её видит поиск, какой canonical выбран, индексируется ли она.

На что реагировать: если нужные агрегатные страницы не индексируются — проверяют, не закрыты ли они по ошибке (robots, noindex, canonical на раздел), есть ли на них внутренние ссылки и уникальный контент; если растёт число исключённых дублей или в индекс лезут параметрические URL — донастраивают canonical, Clean-param, robots; если обход уходит в мусор — закрывают ловушки. Мониторинг индексации — это не разовая проверка после запуска, а постоянная гигиена: фильтр живёт вместе с каталогом, и правила приходится актуализировать. Более широкий набор проверок индексации, дублей и технических параметров магазина мы собрали в материале про технический SEO-аудит на 1С-Битрикс.

Частые ошибки

Эти промахи встречаются чаще всего и либо лишают магазин трафика с фильтра, либо топят сайт в дублях:

• В индекс улетели все комбинации. Фильтр включили «для SEO», но не настроили правила — и в индекс попали десятки тысяч мусорных URL. Сайт тонет в дублях, краулинговый бюджет уходит впустую. Самая частая и тяжёлая ошибка.
• Обратная крайность — закрыли весь фильтр. Испугались дублей и закрыли фильтр в robots целиком — потеряли весь длинный хвост коммерческого спроса по комбинациям «категория плюс параметр».
• Canonical всех страниц фильтра на раздел. Полезные спросовые агрегатные страницы «схлопнулись» на родительский раздел и вылетели из индекса вместе с трафиком.
• Дубли фильтра и раздела. Одна выборка доступна по ЧПУ и по GET, или порядок фасетов не зафиксирован — плодятся дубли, сигналы размазываются.
• Одновременно robots-disallow и noindex. Страницу закрыли в robots и поставили noindex — робот не дошёл до метатега и не узнал о запрете индексации.
• Открыли без уникализации. Комбинацию открыли для индекса, но не дали ей уникальных метатегов, H1 и текста — получили дубль раздела вместо посадочной страницы.
• Бесконечные URL не закрыты. Сортировки, ценовые диапазоны с шагом, глубокие комбинации доступны роботу по ссылкам — краулинговый бюджет уходит в ловушку.
• Открыли без спроса. Настроили открытие комбинаций «по технике», не сверившись с семантикой, — в индексе куча страниц, которые никто не ищет.
• Clean-param перепутали с универсальным решением. Понадеялись только на Clean-param, забыв, что это инструмент Яндекса, — для Google параметры остались неуправляемыми.
• Пагинация плодит дубли. Страницы пагинации индексируются с одинаковыми метатегами или, наоборот, недоступны роботу, и он не доходит до глубоких товаров.
• Слишком широкий Disallow. Правило в robots написали грубо, и под него попали полезные агрегатные страницы — целый класс URL выпал из индекса.
• Настроили и забыли. Индексацию фильтра не мониторят; после изменений каталога правила устаревают, и в индекс снова начинает лезть мусор.

Чек-лист

Практический список для настройки и ведения индексации умного фильтра магазина на 1С-Битрикс:

1. Список спросовых комбинаций получен из семантики. Из ядра и карты релевантности выбраны комбинации со спросом — кандидаты в агрегатные страницы.
2. SEF-режим фильтра включён. Спросовые комбинации отдают чистый ЧПУ; порядок фасетов в URL зафиксирован.
3. Правила «открыть/закрыть» заданы. Открыты только спросовые и содержательные выборки, остальное закрыто.
4. Метатеги и контент уникализированы. У открытых страниц свои title, description, H1, вводный текст и крошки.
5. Canonical настроен избирательно. Полезные — на себя, служебные «хвосты» и параметрический фильтр — на канон.
6. robots.txt проверен. Закрыты параметрические состояния и служебные разделы; полезные страницы не попали под Disallow.
7. Clean-param настроен для Яндекса. Сортировки, отображение, метки трафика, состояния фильтра переданы в Clean-param.
8. noindex у мусорных комбинаций. Комбинации без спроса, оставшиеся в навигации, помечены noindex (и не закрыты в robots одновременно).
9. Ловушки для краулера закрыты. Бесконечные URL (диапазоны, глубокие комбинации, перестановки) недоступны для обхода; ссылки на них не индексируемые.
10. Пагинация обработана. Первая страница индексируется, остальные не плодят дубли, товары со всех страниц доступны роботу.
11. Sitemap содержит нужное. В карте сайта — категории, спросовые агрегатные страницы и карточки.
12. Мониторинг в Вебмастере налажен. Регулярно проверяются страницы в поиске, исключённые, обход и причины; правила донастраиваются.

Вывод

Агрегатные страницы фильтра — это самый большой резерв конверсионного трафика интернет-магазина и одновременно самый частый источник его SEO-проблем, потому что и польза, и мусор рождаются одним механизмом умного фильтра. Тысячи комбинаций одновременно и полезны (спросовые «категория плюс параметр»), и вредны (бесконечные технические URL). Задача управления индексацией — разделить одно и другое: открыть в индекс осознанно отобранные спросовые комбинации (бренд, цвет, «бренд плюс цена») как полноценные агрегатные страницы с чистым SEF-URL, уникальными метатегами и текстом, и целенаправленно закрыть всё остальное — глубокие комбинации, сортировки, служебные параметры и метки.

Инструменты для этого работают только вместе: чистый SEF-URL под спрос вместо GET-параметров; canonical избирательно (полезное — на себя, мусор — на канон); Clean-param в robots для Яндекса на параметрический шум; Disallow для массового технического мусора и служебных разделов; noindex для отдельных мусорных комбинаций; продуманная обработка пагинации; контроль дублей фильтра и раздела по принципу «один интент — один URL». Всё это закрывает ловушки для краулера и бережёт краулинговый бюджет, направляя обход робота на важные страницы. А основой всех решений остаётся семантика: открывать нужно только то, что ищут, — иначе сайт либо теряет трафик, либо тонет в дублях. Настройте catalog.smart.filter в SEF под список спросовых комбинаций, согласуйте сигналы индексации между собой и держите картину под контролем через Вебмастер — тогда умный фильтр из источника проблем превращается в мощный и предсказуемый канал трафика.

Другие разборы по техническому и контентному продвижению магазина на 1С-Битрикс — в рубрике SEO и продвижение: от фасетной навигации и шаблонов метатегов до семантического ядра, технического аудита и аналитики.