Нужно ли закрывать /filter в robots.txt и как краулер находит фильтры?

Если URL вида /filter не должны участвовать в поиске, а фильтр способен создавать множество комбинаций, их стоит закрыть от обхода в robots.txt. Рассчитывать на то, что поисковая система не узнает о них без внешних ссылок, нельзя.

Поисковому роботу не нужна внешняя ссылка, чтобы обнаружить страницу фильтра. Например, Googlebot получает новые URL из внутренних ссылок сайта, Sitemap, редиректов и ссылок с других ресурсов. Ссылки, добавленные JavaScript, также могут быть обнаружены после рендеринга страницы, если они представлены как обычные ссылки с атрибутом href.

Поэтому ситуация вида:

/filter?brand=bosch /filter?brand=bosch&power=1000 /filter?brand=bosch&power=1000&price=5000-10000

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

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

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

Проблема возникает прежде всего тогда, когда комбинации становятся обнаруживаемыми. Например:

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

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

Если весь раздел /filter является техническим и ни одна его страница не должна получать поисковый трафик, можно закрыть его так:

User-agent: * Disallow: /filter

Такое правило остановит поддерживающих robots.txt роботов от загрузки URL, начинающихся с /filter.

Но robots.txt управляет прежде всего обходом, а не гарантированным удалением URL из поискового индекса.

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

Поэтому для уже проиндексированных страниц схема другая.

Если нужно именно удалить страницы /filter из индекса:

1. Не блокировать их в robots.txt.
2. Отдавать на этих страницах meta robots:

или аналогичный HTTP-заголовок X-Robots-Tag: noindex. 3. Дать поисковым роботам повторно обойти страницы и увидеть noindex. 4. После удаления URL из индекса при необходимости закрыть /filter в robots.txt, чтобы больше не расходовать ресурсы на их обход.

Одновременно ставить noindex и запрещать страницу через robots.txt для этой задачи неправильно: если робот не может загрузить страницу, он не увидит находящийся на ней noindex.

Другая ситуация — когда часть фильтров должна ранжироваться. Например, страницы «ноутбуки Lenovo», «красные платья» или «шины R17» могут соответствовать самостоятельному поисковому спросу.

Тогда закрывать весь /filter одним правилом нельзя. Нужно разделить:

• фильтры, которые являются полноценными поисковыми посадочными страницами;
• технические комбинации, сортировки и малополезные пересечения параметров.

Индексируемым страницам нужны стабильные URL и доступные внутренние ссылки. Остальное пространство фильтров можно ограничивать от обхода.

Canonical не стоит использовать как основной способ борьбы с бесконечным пространством фильтров. Google указывает, что canonical со временем может уменьшить обход неканонических вариантов, но считает robots.txt более эффективным решением, если фасетные URL вообще не нужны для поиска.

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