Короткий ответ
Дубли страниц — это несколько URL, отдающих одинаковое или почти одинаковое содержимое. Санкций за них нет: Google заявляет, что внутренние дубли не нарушение, а техническая ситуация. Проблема в другом: поисковая система вынуждена сама выбирать, какой из адресов показывать в выдаче, и выбирает она не всегда тот, который вы продвигали.
На обычном сайте подавляющее большинство дублей возникает не из-за скопированных текстов, а из-за того, как CMS формирует адреса: слеш на конце, www, http, UTM-метки, параметры сортировки, товар в двух категориях. Лечится это тремя инструментами: 301-редиректом, атрибутом canonical и noindex. Выбор между ними зависит от того, нужен ли второй URL людям.
Откуда берутся дубли на самом деле
Когда клиент говорит «у нас дубли», он обычно имеет в виду скопированный текст. За десять с лишним лет работы с эстонскими сайтами скопированные описания я встречал заметно реже, чем технические дубли. Вот 7 источников в порядке того, как часто я их вижу.
| Источник дублей | Пример | Обычная причина |
|---|---|---|
| Варианты одного адреса | /uslugi и /uslugi/, www и без www, http и https | Не настроен единый формат URL на уровне сервера |
| GET-параметры | ?utm_source=, ?sort=price, ?sessionid= | Метки рекламы и внутренние функции каталога |
| Товар в нескольких категориях | /lampy/nastolnaya и /dlya-ofisa/nastolnaya | Настройка CMS «формировать URL по пути категории» |
| Фильтры и фасетная навигация | ?color=black&size=xl в любых комбинациях | Каталог отдаёт 200 на любую комбинацию параметров |
| Технические копии страниц | версия для печати, AMP-остатки, /index.php | Наследие старых шаблонов и миграций |
| Автогенерация CMS | архивы по датам, тегам, авторам, страницы вложений WordPress | Включено по умолчанию, никто не отключал |
| Одинаковые тексты на разных страницах | шаблонные описания филиалов или городов | Массовая генерация посадочных страниц по одному шаблону |
Важное следствие: дубли почти всегда приходят классами, а не поштучно. Если вы нашли один товар, доступный по двум адресам, то по двум адресам доступен весь каталог. Поэтому, найдя дубль, я первым делом ищу породившее его правило в CMS или на сервере, а не правлю конкретную страницу.
Отдельно стоит развести дубли и каннибализацию запросов. Дубль — это одинаковое содержимое по разным адресам. При каннибализации разные страницы с разным текстом конкурируют за один и тот же запрос. Первое чинится склейкой (301 или canonical), второе — переработкой структуры и содержания, и подмена одного другим стоит времени.
Чем дубли реально вредят
Google показывает не тот URL. Это главное. Поисковая система выбирает канонический адрес сама, ориентируясь на ссылки, sitemap, canonical и внутреннюю связность. Если сигналы противоречивы, в выдачу может попасть адрес с UTM-меткой или версия товара из второстепенной категории. Внешне трафик как будто есть, но накопленные сигналы распределены между адресами.
Тратится краулинговый бюджет. На сайте до нескольких тысяч страниц это обычно не проблема: Googlebot обойдёт всё. На каталоге, где фильтры порождают десятки тысяч комбинаций, ситуация меняется: краулер тратит обходы на мусорные адреса, а новые карточки товара ждут индексации неделями. Симптомы совпадают с теми, что я разбирал в статье про то, почему страницы не индексируются в Google.
Размывается внутренний вес. Если часть внутренних ссылок ведёт на /uslugi, а часть на /uslugi/, вес делится между двумя адресами вместо одного. В отчёте по внутренним ссылкам Screaming Frog это видно сразу: один документ приходит с двумя разными адресами. Эффект скромнее двух предыдущих, но устраняется бесплатно, наведением порядка в перелинковке.
Чего дубли не делают — так это не понижают сайт целиком. Если вам говорят, что сайт «под фильтром за дубли», просите показать отчёт «Меры, принятые вручную» в Search Console. В подавляющем большинстве случаев за этой формулировкой стоит обычная потеря позиций по другой причине.
Как найти дубли: три источника
Ни один источник не даёт полной картины, поэтому я всегда смотрю все три: Search Console, краул и саму выдачу.
1. Search Console, отчёт «Индексирование страниц». Самый честный источник: он показывает не то, что вы считаете дублями, а то, что дублями считает Google. Ключевые статусы:
- «Страница является копией, канонический вариант не выбран пользователем» — Google нашёл одинаковое содержимое и склеил адреса сам, потому что вы не поставили canonical.
- «Google выбрал другой канонический URL, чем пользователь» — вы поставили canonical, а Google с ним не согласился. Это сигнал, что страницы либо действительно разные, либо внутренние ссылки и sitemap противоречат вашему canonical.
- «Страница с переадресацией» в большом количестве — часто след того, что редиректы работают, но внутренние ссылки до сих пор ведут на старые адреса.
2. Краул сайта. Пройдитесь Screaming Frog, Sitebulb или любым другим краулером и отсортируйте результат по трём полям: title, H1 и хеш содержимого. Совпадающие title дают самый быстрый срез класса дублей. Отдельно проверьте, отвечает ли сайт кодом 200 на адрес с произвольным добавленным параметром: если /uslugi?foo=bar открывается как обычная страница, у вас потенциально бесконечное число дублей.
3. Сама выдача. Запрос вида site:вашдомен.ee "фрагмент текста в кавычках" показывает, сколько адресов Google держит в индексе с этим текстом. Грубый инструмент, но он ловит то, что не попало в отчёты: старые поддомены, тестовые копии сайта, страницы после незавершённой миграции.
Про четвёртый источник забывают: это sitemap.xml. Если в карте сайта лежат адреса с параметрами или адреса, которые редиректят, вы своими руками говорите Google, что эти URL канонические. Как это должно быть устроено, я разбирал в статье про настройку sitemap.xml и robots.txt.
Чем склеивать: 301, canonical или noindex
Выбор инструмента определяется одним вопросом: нужен ли второй URL живому пользователю? Отдельный случай: второй страницы вообще не должно остаться, и тогда речь идёт уже не о склейке, а о том, что отдавать на удалённых страницах — 404, 410 или редирект.
| Ситуация | Инструмент | Почему |
|---|---|---|
| Старый адрес после смены структуры | 301-редирект | URL больше не нужен, вес передаётся, адрес уходит из выдачи |
| Слеш, www, http | 301-редирект на уровне сервера | Один канонический формат для всего сайта |
| UTM-метки и параметры сортировки | canonical на чистый URL | Ссылка должна работать, но индексироваться не должна |
| Товар в двух категориях | canonical на основной путь | Обе страницы нужны в навигации |
| Пагинация | canonical на саму себя | Страницы 2+ содержат другие товары и дублями не являются |
| Версия для печати, PDF-копия | canonical на HTML-версию | Пользователю нужна, поиску не нужна |
| Корзина, личный кабинет, внутренний поиск | noindex | Страница нужна людям, но бесполезна в выдаче |
| Полностью мусорные автогенерируемые архивы | noindex, затем удаление | Ценности нет ни для кого |
Три вещи, на которых я регулярно вижу ошибки:
- Canonical остаётся рекомендацией, а не приказом. Google учитывает её вместе с другими сигналами и может проигнорировать. Если вы ставите canonical на страницу A, а все внутренние ссылки и sitemap ведут на B, победит B. Сигналы должны быть согласованы.
- Не закрывайте дубли через robots.txt. Запрещённую в robots.txt страницу краулер не скачивает, а значит, не видит ни canonical, ни noindex на ней. Адрес остаётся в индексе как «проиндексировано, несмотря на блокировку в robots.txt», и склейки не происходит. Robots.txt экономит обход, но из индекса не удаляет.
- Не комбинируйте noindex и canonical на одной странице. Это противоречивая инструкция: canonical говорит «передай сигналы туда», noindex — «выкинь меня». Выберите одно.
Языковые версии — не дубли
На эстонском рынке это самая дорогая ошибка из всех перечисленных: почти каждый сайт здесь многоязычный, и Google обязан различать версии, а не склеивать их.
Русская, эстонская и английская версии одной страницы содержат разный текст и адресованы разным аудиториям, то есть не дубли по определению. Даже если совпадают картинки, цены и структура. Хуже того: canonical с эстонской версии на русскую заставляет Google считать эстонскую страницу копией русской и выбрасывает её из эстоноязычной выдачи целиком, то есть отдаёт весь местный трафик конкуренту.
Правильная схема простая: у каждой языковой версии canonical на саму себя, а связаны они между собой через hreflang, включая ссылку на себя: без самоссылки Google игнорирует всю группу. Типовые ошибки этой разметки и способ их проверки я разбирал в отдельной статье про настройку hreflang.
Отдельный случай: один язык на нескольких доменах или поддоменах, например .ee и .com с одинаковым английским текстом. Вот это уже настоящие дубли между сайтами, и Google выберет главный домен сам: либо ставьте кросс-доменный canonical, либо честно разделяйте содержимое.
Что я вижу на практике
Самый частый дубль — не в каталоге, а на главной. Сайт одновременно открывается по четырём адресам: с www и без, с https и http. Настраивается это один раз на уровне сервера или CDN и закрывает целый класс проблем ещё до того, как кто-то посмотрит на страницы товаров.
Второй по частоте — параметры от внутренних функций. Сортировка, выбор количества товаров на странице, идентификатор сессии, следы старого фильтра. Каждый такой параметр удваивает или утраивает число URL каталога.
После миграции дубли появляются даже при правильных редиректах. Редиректы делают, а внутренние ссылки в меню, в текстах статей и в sitemap оставляют старые. Формально всё работает, фактически Googlebot ходит по цепочкам и получает противоречивые сигналы. Проверка простая: после переезда краул не должен находить ни одной внутренней ссылки на адрес, отдающий 301.
Дубли часто соседствуют со страницами-сиротами. И те и другие — следствие расхождения между реальной структурой сайта и тем, что о ней думает CMS. Разбирая один класс проблем, имеет смысл сразу проверить и второй: как искать сирот, я писал в статье про страницы без входящих ссылок.
Честная граница применимости: всё вышеописанное относится к сайтам до нескольких десятков тысяч URL, с которыми я работаю чаще всего. На крупных маркетплейсах управление параметрами становится отдельной инженерной задачей, и там решения принимаются на уровне архитектуры каталога, а не настройками CMS.
Порядок действий
- Проверьте, открывается ли сайт по нескольким вариантам главного адреса, и настройте 301 на один канонический формат.
- Откройте отчёт «Индексирование страниц» в Search Console и выпишите страницы со статусами про копии и чужой канонический URL.
- Пройдитесь краулером и сгруппируйте страницы по совпадающим title и H1: так видны классы дублей, а не отдельные случаи.
- Для каждого класса определите, нужен ли второй URL пользователю, и выберите инструмент по таблице выше.
- Приведите внутренние ссылки и sitemap.xml в соответствие с выбранными каноническими адресами — это половина эффекта.
- Проверьте, что языковые версии связаны hreflang, а не склеены canonical'ом.
- Через 3–4 недели вернитесь в отчёт «Индексирование страниц» и сверьте, согласился ли Google с вашим выбором.
Последний шаг пропускают чаще всего, а он и есть проверка результата: если Google по-прежнему выбирает другой канонический URL, значит, где-то остался противоречащий сигнал. Если правильные адреса нужно ещё и заложить в архитектуру нового сайта, это уже задача уровня веб-разработки, а не точечных правок.
