Когда мне присылают сайт на аудит со словами «у нас всё чисто, дублей нет», я почти всегда нахожу их в первые двадцать минут. Не потому что владелец врёт — он действительно их не видит. Дубли, о которых пойдёт речь, не лежат на поверхности в виде двух одинаковых статей. Они прячутся в технике: в адресах с параметрами, в номерах страниц каталога, в хвостах рекламных ссылок. Глазами по сайту вы их не поймаете, а робот Яндекса находит их тысячами и честно тащит в индекс.
За двадцать лет работы я убедился: именно эти «невидимые» дубли чаще всего стоят бизнесу позиций. Не переспам, не плохой контент, а банальные технические копии, которые никто не закрыл вовремя. Давайте разберём четыре главных источника по порядку — пагинацию, фильтры, UTM и сессии — и я покажу, что с каждым делать на практике, а не в теории.
Почему скрытые дубли опаснее тех, что видно глазами
Обычный дубль — например, две одинаковые карточки товара под разными адресами — заметит даже начинающий оптимизатор. Открыл сайт, прошёлся по разделам, нашёл повтор. Скрытые дубли так не ловятся, и в этом вся беда. Они рождаются автоматически: движок сам генерирует адрес при каждом клике по фильтру, при каждом переходе со второй страницы на третью, при каждом заходе из рекламы. Владелец видит один красивый URL, а в индексе их пятьсот.
Чем это бьёт по сайту? Во-первых, размывается ссылочный и поведенческий вес. Вместо одной сильной страницы категории поисковик видит десяток её клонов, и сигналы доверия делятся между ними. Ни одна копия не набирает достаточно, чтобы выйти в топ. Во-вторых, тратится краулинговый бюджет — то самое ограниченное количество страниц, которое робот готов обойти за визит. Пока он ходит по мусорным адресам с параметрами, до новых важных страниц у него руки не доходят, и они неделями ждут индексации.
В-третьих, и это самое неприятное, Яндекс может сам выбрать в качестве основной не ту страницу, что вам нужна. Вы оптимизировали чистый адрес категории, а в выдачу попадает её версия с хвостом ?sort=price&page=3 — без нормального заголовка, с обрезанным текстом и кривым сниппетом. Пользователь видит это в поиске, не кликает, поведенческие падают, позиции сползают. Замкнутый круг, который начинается с одной незакрытой технической мелочи.
Пагинация: как страницы 2, 3, 4 растаскивают вес категории
Пагинация — это разбивка списка товаров или статей на страницы. В каталоге из тысячи позиций их физически нельзя показать на одном экране, поэтому появляются адреса вида /category/?page=2, /category/?page=3 и так далее. Сами по себе они нужны и пользователю, и роботу для обхода. Проблема начинается, когда их оформляют неправильно.
Самая частая ошибка, которую я вижу годами: на всех страницах пагинации стоит canonical на первую страницу категории. Логика вроде здравая — «это же одна категория, пусть склеивается в одну». Но на практике это говорит роботу: страниц 2, 3, 4 как будто не существует, индексируй только первую. А товары, которые лежат на глубоких страницах, в итоге выпадают из индекса вообще, потому что других путей к ним часто нет. Я лично разгребал интернет-магазины, где половина ассортимента была недоступна поиску именно из-за такого «удобного» canonical.
Когда-то спасал тег rel="next" и rel="prev" — он связывал страницы пагинации в цепочку. Google официально перестал его учитывать ещё несколько лет назад, и сегодня закладываться на него бессмысленно. Что работает сейчас: каждая страница пагинации должна ссылаться canonical сама на себя, оставаться открытой для индексации и иметь хотя бы минимально уникальный title с указанием номера страницы — «Категория — страница 2». Так робот спокойно обходит весь каталог, добирается до всех товаров, но при этом понимает, где «материнская» страница, по которой надо ранжировать.
Альтернатива для крупных каталогов — страница «Показать всё», на которую и ведёт canonical со всех частей пагинации. Решение хорошее, но капризное: если товаров слишком много, такая страница грузится медленно и проваливает Core Web Vitals, а это уже отдельная техническая боль. Если у вас сложный каталог и вы не уверены, какую схему выбрать, это как раз тот случай, когда лучше заказать технический SEO-аудит сайта и получить решение под конкретную структуру, а не наугад.
Фильтры и сортировки: бесконечные комбинации адресов
Фильтры — это вообще отдельная вселенная дублей. Представьте каталог обуви: цвет, размер, бренд, цена, материал, сортировка по популярности и по цене. Каждая галочка добавляет в адрес параметр. Пользователь выбрал «чёрные кроссовки 42 размера до 5000 рублей, сортировка по новизне» — и движок сгенерировал уникальный URL. Теперь посчитайте, сколько комбинаций даёт пересечение всех значений всех фильтров. Тысячи. Десятки тысяч. И каждый — отдельная страница в глазах робота.
Это явление называют фасетной навигацией, и она способна раздуть индекс до неприличных размеров. Контент на таких страницах почти одинаковый — те же товары, переставленные местами или слегка отфильтрованные. Для поисковика это near-duplicate, почти-дубли, и относится он к ним соответственно: тратит на них бюджет обхода, путается, какую считать главной, и в худшем случае помечает раздел как низкокачественный из-за обилия тонких однотипных страниц.
Но рубить все фильтры под корень тоже неправильно — и вот тут начинается искусство. Часть фильтрованных страниц имеет реальный поисковый спрос. «Купить чёрные кроссовки» люди ищут, и под такой запрос фильтрованная страница может и должна ранжироваться. Поэтому я всегда делю фильтры на две группы. Первая — коммерчески ценные комбинации, под которые есть частотность: их превращаем в полноценные посадочные страницы с уникальным заголовком, текстом и человекопонятным адресом, открываем для индексации и продвигаем. Вторая — всё остальное, бесконечные сочетания без спроса: их закрываем от индексации и склеиваем canonical на базовую категорию.
Технически непродвигаемые фильтры закрывают несколькими способами в связке. Canonical с фильтрованной страницы на чистую категорию убирает дубль из ранжирования. Мета-тег robots со значением noindex, follow на мусорных комбинациях убирает их из индекса, но оставляет робота ходить по ссылкам. А в robots.txt директивой Disallow можно закрыть от обхода целые шаблоны параметров, чтобы не жечь краулинговый бюджет. Какой инструмент применять, зависит от движка и от того, что важнее — убрать из индекса или сэкономить обход. Часто грамотная настройка фильтров требует правок прямо в коде CMS, и тогда без технической доработки сайта не обойтись — шаблонными галочками в админке тут не закроешь.
UTM-метки: рекламный трафик, который плодит копии страниц
UTM-метки — это параметры, которые маркетологи цепляют к ссылкам, чтобы в аналитике видеть, откуда пришёл трафик. Выглядят они как хвост ?utm_source=yandex&utm_medium=cpc&utm_campaign=spring. Штука полезная и нужная — без меток вы не поймёте, какая реклама окупается. Но для индексации это головная боль: каждая метка создаёт новый адрес той же самой страницы.
Сценарий, который я вижу постоянно. Запустили рекламу в Яндекс Директе, в рассылке, в соцсетях — для каждого канала своя метка. Люди переходят, делятся ссылками, копируют их в мессенджеры. Эти размеченные адреса попадают на форумы, в чаты, кто-то на них даже ссылается. Робот их находит, заходит — а там полная копия вашей продающей страницы, только с хвостом в URL. И вот уже в индексе пять версий одной посадочной, и непонятно, какую Яндекс посчитает основной.
Контент при этом не меняется ни на байт — UTM-метка вообще не влияет на то, что видит пользователь, она нужна только для статистики. Именно поэтому решение здесь чистое и однозначное. Для Яндекса главный инструмент — директива Clean-param в robots.txt. Она прямо говорит роботу: эти параметры на содержимое не влияют, склей все адреса с ними в один чистый. Записывается так: Clean-param: utm_source&utm_medium&utm_campaign&utm_term&utm_content. После этого Яндекс перестаёт считать размеченные адреса отдельными страницами и передаёт весь их вес на чистый URL.
В дополнение к этому на всех страницах должен стоять корректный canonical на версию без параметров — это работает и для Google, у которого своего аналога Clean-param нет, и подстраховывает Яндекс. Связка «Clean-param плюс canonical» закрывает проблему UTM практически полностью. Важный нюанс: Clean-param — директива капризная к синтаксису, одна лишняя точка или неверный путь, и она просто не сработает, а вы будете думать, что всё закрыто. Проверять её обязательно в Яндекс.Вебмастере после внедрения.
Сессионные параметры и прочий технический мусор в URL
Сессионные параметры — это идентификаторы вроде ?sid=abc123, ?PHPSESSID=... или ?sessionid=..., которые старые или плохо настроенные движки подставляют в адрес, чтобы «помнить» пользователя между страницами. Беда в том, что для каждого посетителя, а иногда и для каждого визита, генерируется свой идентификатор. И если робот заходит на сайт несколько раз, он каждый раз получает один и тот же контент под новым уникальным адресом. Дубли множатся буквально в геометрической прогрессии.
Я сталкивался с проектами, где из-за сессий в URL индекс распухал в десятки раз относительно реального числа страниц. Робот ходил по призрачным адресам, которые при следующем заходе уже не существовали, получал ошибки, тратил бюджет впустую и почти не добирался до настоящего контента. Сайт при этом мог выглядеть абсолютно нормально для живого человека — проблему видно только в логах сервера и в отчётах вебмастера по проиндексированным страницам.
Правильное решение — на уровне сервера: сессия должна храниться в куках, а не в адресе. Это вопрос настройки движка, и его нужно закрывать в первую очередь, потому что бороться с симптомами бессмысленно, если генератор дублей работает. Если же переписать поведение CMS быстро нельзя, временно спасают те же инструменты: Clean-param для сессионного параметра в Яндексе и canonical на чистый адрес. Но это именно подпорка — корень проблемы в том, что движок вообще пишет сессию в URL, и убирать надо его.
Сюда же отнесу всякий прочий параметрический мусор: метки печати ?print=1, параметры партнёрских программ, идентификаторы рефералов, версии для слабовидящих, технические флаги CMS. Логика по всем одна: если параметр не меняет содержимое страницы — он не должен порождать отдельный индексируемый адрес. Разбор такого хвоста параметров — стандартная часть любого моего аудита, и почти на каждом проекте всплывает что-то, о чём владелец даже не подозревал.
Как найти все эти дубли на своём сайте
Теория теорией, но без диагностики вы не поймёте масштаб. Начинать я советую с Яндекс.Вебмастера — это бесплатно и честно показывает, что робот реально видит. Смотрите раздел со страницами в поиске и исключёнными страницами: там Яндекс прямо помечает дубли и причины, по которым он что-то выкинул из индекса. Если в исключённых вы видите кучу адресов с параметрами и пометкой про дубли — диагноз очевиден.
Дальше — сравните два числа: сколько страниц у вас на самом деле и сколько их в индексе. Если реально сто страниц, а в индексе три тысячи — у вас классическая фабрика дублей где-то в фильтрах или сессиях. Удобно загнать сайт в любой краулер-парсер (Screaming Frog, Netpeak Spider и подобные), который пройдёт по сайту как робот и вытащит все адреса с параметрами, дубли заголовков, страницы с одинаковыми title и description. Совпадающие метатеги — почти безошибочный маркер дублей.
Отдельно загляните в логи сервера, если есть доступ. Они показывают, по каким именно адресам ходит робот и сколько бюджета он сжигает на мусор. Это самый честный источник правды, но и самый трудоёмкий в анализе. Если разбираться в логах самостоятельно некогда или непонятно, как — для этого и существует бесплатный экспресс-аудит сайта: он за пару минут покажет основные технические проблемы, включая параметрические дубли, и подскажет, куда копать дальше.
Что делать: canonical, Clean-param, robots — когда какой инструмент
Давайте сведу всё в понятную систему, потому что главная путаница в том, что инструменты похожи, а работают по-разному. Canonical не запрещает индексацию — он говорит, какую из похожих страниц считать главной, и передаёт ей вес. Применяйте его, когда страница нужна пользователю (фильтр, пагинация, UTM-ссылка работает), но в индексе должна быть другая версия.
Мета-тег noindex прямо убирает страницу из индекса, но оставляет её доступной для обхода и переходов по ссылкам, если стоит follow. Это инструмент для страниц, которые вообще не должны быть в поиске, — мусорные фильтры, служебные разделы. Директива Disallow в robots.txt запрещает роботу заходить на адрес вообще — экономит бюджет обхода, но имейте в виду: если страница уже в индексе, Disallow её оттуда не выкинет, для удаления нужен именно noindex, по которому робот должен сначала пройти. А Clean-param — это специфичный для Яндекса и самый элегантный способ разобраться с параметрами, которые не меняют контент: метки, сессии, сортировки.
Грубая ошибка — комбинировать их бездумно. Например, закрыть страницу в robots.txt через Disallow и одновременно повесить на неё noindex: робот не сможет зайти, не увидит noindex и не удалит страницу из индекса. Или поставить canonical на страницу, закрытую от обхода, — робот до canonical просто не доберётся. Каждый инструмент решает свою задачу, и сила в правильной комбинации под конкретный тип дубля, а не в том, чтобы навесить всё сразу. За двадцать лет и 300+ проектов у меня сложилась чёткая схема, какой параметр чем закрывать на каждом популярном движке, и именно поэтому я ни разу не получил фильтр Яндекса — потому что не ломал индексацию «на всякий случай».
Когда стоит передать это специалисту
Если вы дочитали досюда и поняли, что на вашем сайте, скорее всего, живёт целый зоопарк скрытых дублей, — это нормально. Параметрический мусор есть почти у всех, кто не занимался техническим SEO целенаправленно. Плохо другое: пока дубли растаскивают вес и краулинговый бюджет, ваши деньги на рекламу и контент работают вполсилы, а конкуренты с чистой технической базой обходят вас при меньших вложениях.
Я — частный SEO-специалист, работаю напрямую с владельцем бизнеса, без агентств и менеджеров-посредников, и беру только один проект в нише, чтобы не продвигать конкурентов одновременно. За 20 с лишним лет вывел в ТОП-3 Яндекса больше 300 сайтов и ни разу не словил фильтр — как раз потому, что техническую чистоту, включая дубли, навожу до того, как начинаю наращивать трафик. Если вашему сайту не хватает целевых заявок из поиска, я готов разобрать его по косточкам: найти все дубли, закрыть параметрический мусор, склеить вес на нужные страницы и выстроить рост позиций. Начните с бесплатного аудита — я покажу точки роста без воды, а дальше решим, нужно ли профессиональное SEO-продвижение сайта под ключ или достаточно точечной доработки. Первый шаг ни к чему не обязывает, а проблему с трафиком надо закрывать сейчас, а не через полгода стагнации.
И ещё одно направление, которое сегодня нельзя игнорировать. Поиск меняется на глазах: всё больше людей получают ответы не в выдаче, а прямо от нейросетей — Поиск с Алисой, YandexGPT, GigaChat, ChatGPT, Perplexity. И вот что важно понимать про дубли в этом контексте: если ваш сайт замусорен параметрическими копиями и нейросети не могут чисто извлечь из него факты, вас просто не процитируют. GEO-продвижение — оптимизация под генеративный AI-поиск — начинается ровно с той же технической чистоты, что и классическое SEO. Я занимаюсь GEO с момента его появления на российском рынке и помогаю бизнесу попадать в ответы нейросетей, пока конкуренты об этом даже не задумались. Если хотите быть первыми в AI-поиске своей ниши, напишите мне на консультацию — разберём, как подготовить сайт и контент под генеративную выдачу. А разобраться в свежих материалах по теме можно в блоге со статьями по SEO и GEO.
Увеличьте позиции и продажи вашего сайта
Профессиональное SEO-продвижение с гарантией результата. Выберите подходящую услугу:
Остались вопросы по продвижению?
Меня зовут Анатолий Кузнецов, я SEO-оптимизатор с 20-летним стажем. Разберу ваш сайт, отвечу на вопросы и подскажу, что улучшить для роста позиций в Яндексе и Google.
Связаться со мной →
Старт 
Стандарт 
Премиум 
