Сайты на типовых движках почти всегда обрастают страницами, повторяющими друг друга. Одна статья попадает в три рубрики и пять тегов, товар выводится сразу в четырёх категориях, архивы по месяцам создают пустые подборки, а пагинация добавляет к каждой из них ещё десяток адресов. Поисковая система видит каждый адрес как самостоятельную страницу и сама решает, какую копию показывать в выдаче. Такое решение редко совпадает с интересами владельца. В статье разобрана рабочая схема из двух инструментов, rel="canonical" и noindex, которая собирает сигналы на эталонных страницах, выводит из индекса архивы без ценности и при этом не теряет внутренние ссылки.
Откуда берутся дубли между категориями, тегами и архивами
Механика почти всегда одинаковая. Система управления контентом строит адрес для каждой комбинации материала и подборки, и один текст начинает жить по нескольким адресам сразу. Статья из блога с адресом /blog/tekhnicheskoe-seo/ попадает в рубрику /blog/optimizaciya/, в рубрику /blog/kontent/ и ещё в теги /tag/canonical/, /tag/indeksaciya/ и /tag/tekhnicheskoe-seo/. Текст везде один, адреса разные, и для робота это пять разных страниц с совпадающим содержанием.
В интернет-магазине картина шире. Карточка кроссовок лежит в /catalog/obuv/krossovki/ и одновременно в /catalog/letnyaya-kollekciya/krossovki/. Фильтры добавляют параметры вроде ?color=white, сортировка ставит ?sort=price, пагинация наращивает /page/2/, /page/3/ и так до конца каталога, а рекламные ссылки приписывают ?utm_source=partner. Отдельный пласт составляют технические зеркала: адреса с www и без него, http и https, слэш на конце и без него.
Масштаб легко оценить на числах. Условный блог с 300 статьями, 12 рубриками и 40 тегами, где материал в среднем попадает в 2 рубрики и 4 тега, отдаёт роботу по 7 адресов на каждый текст. Добавим 72 страницы архивов по месяцам за шесть лет и по странице на каждого из 12 авторов. Итог превышает 2 200 адресов при 300 самостоятельных материалах. Ни один из этих адресов не появился по злому умыслу, платформа просто честно выполняет свои функции.
Чем грозит размытие сигналов и переполненный индекс
Когда поисковая система находит несколько одинаковых страниц, она выбирает одну в качестве основной и игнорирует остальные. Проблема в том, что выбор делается автоматически, по косвенным признакам, и не всегда в пользу той страницы, которую продвигает владелец. Робот может оставить в выдаче категорию с параметрами сортировки вместо чистого адреса, и тогда весь труд по внутренней перелинковке уйдёт мимо.
Сигналы, на которых держится ранжирование, размываются между копиями. Внешние ссылки могут стоять на одном адресе, упоминания достаться второму, внутренний вес перетечь в третий, и ни одна копия не получает полную силу. Две категории за один запрос начинают конкурировать между собой и ослабляют друг друга, а пользователь видит в выдаче не тот адрес, который задумывался как витрина. Знакомая картина: в топе оказалась страница /tag/sales/ вместо /catalog/akcii/, и переехать обратно без вмешательства уже не получается.
Вторая беда касается обхода. У робота есть ограничение на количество обращений к сайту за один визит, и каждый служебный адрес съедает свою долю. Когда индекс забит дубликатами, новые товары и статьи попадают в обход позже, а обновления дольше доходят до выдачи. Магазину с 1 200 товарами и 3 400 проиндексированными адресами приходится тратить обход почти на три четверти балласта. Отчёты о состоянии индекса тоже теряют смысл: половина строк в них описывает мусор, и реальную картину приходится вытаскивать вручную.
rel canonical выбирает эталон и собирает сигналы в одном месте
Тег rel="canonical" говорит роботу прямо: эта страница и её копия одно и то же, объединяй их, эталон записан в атрибуте href. Размещают его в блоке head каждой страницы, включая сам эталон:
<head>
<link rel="canonical" href="https://site.ru/catalog/krossovki/">
</head>Копия /catalog/letnyaya-kollekciya/krossovki/ получает тот же тег и указывает на главный адрес. После переиндексации сигналы с копий перетекают на эталон: ссылки, вес и поведение посетителей засчитываются одной странице, а не размазываются по пяти. Копия при этом не исчезает из браузера, она остаётся рабочей, просто перестаёт конкурировать в выдаче.
Правила обращения с тегом короткие, но жёсткие. Адрес в href пишут абсолютным, с доменом и протоколом, иначе часть роботов трактует его как относительный путь. Один тег на страницу, размещение только в head, указание на реально существующую страницу, которая отвечает кодом 200. Цепочки вида страница A ссылается на B, а B на C, работают плохо, указывать нужно сразу на конечный эталон. Самоссылающийся canonical на обычных страницах считается хорошей практикой, он закрепляет за адресом статус эталона по умолчанию.
Выбирать эталон между несколькими копиями помогает короткий чек-лист. Сильнее тот адрес, на который чаще ссылаются внутри сайта, тот, что собрал больше внешних ссылок и переходов, тот, что короче и понятнее человеку, и тот, что исторически продвигался. Если магазин годы собирал ссылки на /catalog/krossovki/, именно он и остаётся витриной, даже когда админка выводит товар и по другому пути.
Для документов без HTML-разметки существует заголовочный вариант, например для PDF-файлов:
Link: <https://site.ru/docs/price-list.pdf>; rel="canonical"noindex, follow убирает архив из индекса, но сохраняет обход
Директива noindex решает другую задачу. Она не объединяет страницы, а выводит конкретный адрес из индекса после следующего обхода. Значение follow в паре с ней сохраняет проход по ссылкам, поэтому вес с архивной страницы продолжает перетекать на статьи и товары:
<meta name="robots" content="noindex, follow">Разницу подходов видно на одном примере. Пусть есть два тега с одинаковым наполнением и одна категория с тем же ассортиментом. Canonical на категорию склеит теги с ней и соберёт все сигналы в одном месте. Noindex на тегах очистит выдачу от них, но сигналы распределятся по исходящим ссылкам, а не сконцентрируются на эталоне. Для рубрик, которые владелец хочет развивать и продвигать, объединение выгоднее. Для служебных подборок без поискового спроса достаточно простого вывода из индекса.
Для массового применения на уровне сервера удобнее заголовок X-Robots-Tag, он не требует правки шаблонов и действует на весь ответ:
X-Robots-Tag: noindex, followЗдесь живёт главная ловушка. Директиву робот видит только при обходе страницы. Если адрес одновременно закрыт в robots.txt через Disallow, робот на него не заходит, директиву не читает, и страница может висеть в выдаче сколь угодно долго. Чтобы noindex сработал, страница должна открываться роботу свободно. И второй нюанс, о котором забывают: удаление из индекса происходит не мгновенно. Крупный сайт отдаёт копии по мере переобхода, на это уходят недели, и медленное очищение здесь не баг, а нормальный режим работы поисковой машины.
Критерии выбора метода для разных типов архивных страниц
Выбор сводится к одному вопросу: есть ли у страницы самостоятельная ценность и поисковый спрос. Крупная категория с уникальным описанием и трафиком остаётся в индексе и развивается. Тег, повторяющий категорию другим адресом, ценности не несёт. Архив мая 2019 года никто не ищет. Между этими полюсами и раскладываются решения, а для типовых ситуаций ориентир выглядит так:
- теги и метки, дублирующие рубрики, закрывают связкой noindex, follow и оставляют в обходе, чтобы ссылки с них продолжали передавать вес статьям;
- категории, совпадающие по ассортименту из-за пересечения каталога, объединяют через rel="canonical" с одной эталонной страницей, которую продвигают;
- архивы по датам и авторам без спроса выводят из индекса тем же noindex, follow, а отжившие разделы целиком закрывают в robots.txt;
- пагинацию оставляют индексируемой с самоссылающимся canonical, потому что страницы /page/2/ и дальше ведут к материалам из глубины сайта;
- результаты поиска и параметры сортировки отдают через canonical на базовый адрес категории, а служебные разделы вроде /?s= закрывают от обхода в robots.txt.
С файлом robots.txt связана отдельная экономика. Полный запрет обхода на раздел экономит краул-бюджет сильнее всего, но страницы внутри вообще не обходятся, их ссылки не учитываются, поэтому инструмент уместен там, где передавать вес нечего. Файл sitemap.xml должен содержать только эталоны: карта с дубликатами или с закрытыми noindex адресами подаёт роботу противоречивые сигналы. Сам canonical, в отличие от Disallow, обход не блокирует никогда, он лишь рекомендует объединение.
Ошибки внедрения, при которых дубли остаются в индексе
Первая по частоте ошибка это canonical на саму страницу при желании из неё выйти. Владелец хочет убрать категорию из выдачи, ставит на неё самоссылающийся тег и ждёт исчезновения, но тег лишь подтверждает статус эталона. Выйти из индекса можно только noindex, а canonical служит объединению.
Вторая классика это noindex вместе с Disallow в robots.txt. Оба инструмента по отдельности рабочие, вместе они отменяют друг друга: без обхода директива невидима. Правильно либо снять блокировку и дать роботу прочитать noindex, либо закрыть адрес только через Disallow и принять, что ссылки из него не передаются.
Дальше идут механические промахи. Несколько тегов canonical на одной странице, из которых робот берёт первый, а остальные игнорирует. Относительный адрес без домена. Тег, размещённый не в head. Эталон, отвечающий ошибкой 404 или уходящий в редирект, из-за чего склейка теряет силу. Noindex-страницы, включённые в sitemap, где робот ожидает только чистые эталоны. Canonical на страницу, закрытую в robots.txt, эталон недоступен, и объединение не подтверждается. Отдельный сюжет это противоречивая пара, когда canonical указывает на соседний адрес, а в карте сайта лежит сама копия.
Ожидания по срокам тоже стоит откалибровать. После установки директив копии покидают индекс по мере обхода, и на крупных сайтах это недели. Резкое обнуление числа страниц в отчётах за сутки скорее говорит о технической аварии, чем об успехе.
Проверка результатов в Search Console и цифры до и после чистки
Отчёт "Индексирование страниц" в Search Console показывает, куда система отнесла каждую копию. Статус "Повторяющаяся страница, Google выбрал другой канонический адрес" означает, что робот проигнорировал подсказку или не нашёл её. Статус "Проиндексировано без явного канонического адреса" сигнализирует, что тег отсутствует и система решает сама. Цель настройки выглядит просто: перевести копии в состояние, где явный канонический адрес признан, а лишние страницы ушли из индекса.
Проверка URL-адреса даёт быстрый ответ по отдельной странице. Ввод адреса дубликата показывает строку с каноническим адресом от пользователя и тем, который система выбрала фактически. Совпадение двух значений означает, что склейка принята. Расхождение подсказывает, где искать противоречия, обычно в карте сайта или в блокировке обхода. Отчёты по файлам Sitemap дополняют картину: отправленная карта из одних эталонов должна со временем показать высокий процент проиндексированных адресов, и любое отставание возвращает к списку ошибок из предыдущего раздела.
Считать эффект удобно на условном примере. Магазин с 1 200 товарами до настройки держал в индексе 3 400 адресов, из них две трети приходились на дубли категорий, фильтры и теги. После расстановки canonical на эталонные категории и noindex на архивы индекс сжался примерно до 1 500 страниц. Робот стал чаще заходить на карточки, новые позиции попадали в обход за два-три дня вместо недели. Блог из первого раздела, сократившийся с 2 200 адресов до 380, показал тот же эффект на меньших числах.
Дальше проверка становится короткой рутиной. Раз в месяц стоит открывать отчёт "Индексирование страниц", проверять по пять-шесть случайных дубликатов через проверку URL и смотреть, не вернули ли новые теги и фильтры мусор в индекс. Стратегия работает не как разовая чистка, а как режим сопровождения: структура сайта меняется, категории появляются и исчезают, и каждая новая подборка требует короткого решения, остаться эталоном, склеиться с соседом или уйти из индекса, сохранив ссылки.