Короткий ответ
Дубли страниц — это несколько URL, отдающих одинаковое или почти одинаковое содержимое. Санкций за них нет: Google заявляет, что внутренние дубли — техническая ситуация, а не нарушение. Проблема в другом — поисковая система вынуждена сама выбирать, какой из адресов показывать в выдаче, и выбирает она не всегда тот, который вы продвигали.
На обычном сайте подавляющее большинство дублей возникает не из-за скопированных текстов, а из-за того, как CMS формирует адреса: слеш на конце, www, http, UTM-метки, параметры сортировки, товар в двух категориях. Лечится это тремя инструментами — 301-редиректом, атрибутом canonical и noindex, — и выбор между ними зависит от того, нужен ли второй URL людям.
Откуда берутся дубли на самом деле
Когда клиент говорит «у нас дубли», он обычно имеет в виду скопированный текст. За десять с лишним лет работы с эстонскими сайтами скопированные описания я встречал заметно реже, чем технические дубли. Вот источники в порядке того, как часто я их вижу.
| Источник дублей | Пример | Обычная причина |
|---|---|---|
| Варианты одного адреса | /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 | Включено по умолчанию, никто не отключал |
| Одинаковые тексты на разных страницах | шаблонные описания филиалов или городов | Массовая генерация посадочных страниц без уникального содержимого |
Важное следствие: дубли почти всегда приходят классами, а не поштучно. Если вы нашли один товар, доступный по двум адресам, то по двум адресам доступен весь каталог. Поэтому первое, что я делаю, найдя дубль, — ищу правило, которое его породило, а не правлю конкретную страницу.
Отдельно стоит развести дубли и каннибализацию запросов. Дубль — это одинаковое содержимое по разным адресам. Каннибализация — разные страницы с разным текстом, которые конкурируют за один и тот же запрос. Первое чинится склейкой, второе — переработкой структуры и содержания, и подмена одного другим стоит времени.
Чем дубли реально вредят
Три эффекта, и они очень разного размера.
Google показывает не тот URL. Это главное. Поисковая система выбирает канонический адрес сама, ориентируясь на ссылки, sitemap, canonical и внутреннюю связность. Если сигналы противоречивы, в выдачу может попасть адрес с UTM-меткой или версия товара из второстепенной категории. Внешне трафик как будто есть, но накопленные сигналы распределены между адресами.
Тратится краулинговый бюджет. На сайте до нескольких тысяч страниц это обычно не проблема — Googlebot обойдёт всё. На каталоге, где фильтры порождают десятки тысяч комбинаций, ситуация меняется: краулер тратит обходы на мусорные адреса, а новые карточки товара ждут индексации неделями. Симптомы совпадают с теми, что я разбирал в статье про то, почему страницы не индексируются в Google.
Размывается внутренний вес. Если часть внутренних ссылок ведёт на /uslugi, а часть на /uslugi/, вес делится между двумя адресами вместо одного. Эффект скромнее двух предыдущих, но он бесплатно устраняется наведением порядка в перелинковке.
Чего дубли не делают — так это не понижают сайт целиком. Если вам говорят, что сайт «под фильтром за дубли», просите показать конкретный отчёт. В подавляющем большинстве случаев за этой формулировкой стоит обычная потеря позиций по другой причине.
Как найти дубли: три источника
Ни один источник не даёт полной картины, поэтому я всегда смотрю все три.
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 живому пользователю?
| Ситуация | Инструмент | Почему |
|---|---|---|
| Старый адрес после смены структуры | 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 — «выкинь меня». Выберите одно.
Языковые версии — не дубли
На эстонском рынке это самая дорогая ошибка из всех перечисленных, потому что почти каждый сайт здесь многоязычный.
Русская, эстонская и английская версии одной страницы содержат разный текст и адресованы разным аудиториям — они не дубли по определению. Даже если совпадают картинки, цены и структура. Хуже того: canonical с эстонской версии на русскую выбрасывает эстонскую страницу из эстоноязычной выдачи целиком, то есть отдаёт весь местный трафик конкуренту.
Правильная схема простая: у каждой языковой версии canonical на саму себя, а связаны они между собой через hreflang, включая ссылку на себя. Типовые ошибки этой разметки и способ их проверки я разбирал в отдельной статье про настройку hreflang.
Отдельный случай — один язык на нескольких доменах или поддоменах, например .ee и .com с одинаковым английским текстом. Вот это уже настоящие дубли между сайтами, и здесь либо кросс-доменный canonical, либо честное разделение содержимого.
Что я вижу на практике
Несколько наблюдений с эстонских проектов, которые повторяются из раза в раз.
Самый частый дубль — не в каталоге, а на главной. Сайт одновременно открывается по четырём адресам: с www и без, с https и http. Настраивается это один раз на уровне сервера или CDN и закрывает целый класс проблем ещё до того, как кто-то посмотрит на страницы товаров.
Второй по частоте — параметры от внутренних функций. Сортировка, выбор количества товаров на странице, идентификатор сессии, следы старого фильтра. Каждый из них удваивает или утраивает число адресов каталога.
После миграции дубли появляются даже при правильных редиректах. Редиректы делают, а внутренние ссылки в меню, в текстах статей и в sitemap оставляют старые. Формально всё работает, фактически Googlebot ходит по цепочкам и получает противоречивые сигналы. Проверка простая: после переезда краул не должен находить ни одной внутренней ссылки на адрес, отдающий 301.
Дубли часто соседствуют со страницами-сиротами. И те и другие — следствие расхождения между реальной структурой сайта и тем, что о ней думает CMS. Разбирая один класс проблем, имеет смысл сразу проверить и второй — как искать сирот, я писал в статье про страницы без входящих ссылок.
Честная граница применимости: всё вышеописанное — про сайты до нескольких десятков тысяч URL, с которыми я работаю чаще всего. На крупных маркетплейсах управление параметрами становится отдельной инженерной задачей, и там решения принимаются на уровне архитектуры каталога, а не настройками CMS.
Порядок действий
- Проверьте, открывается ли сайт по нескольким вариантам главного адреса, и настройте 301 на один канонический формат.
- Откройте отчёт «Индексирование страниц» в Search Console и выпишите страницы со статусами про копии и чужой канонический URL.
- Пройдитесь краулером и сгруппируйте страницы по совпадающим title и H1 — так видны классы дублей, а не отдельные случаи.
- Для каждого класса определите, нужен ли второй URL пользователю, и выберите инструмент по таблице выше.
- Приведите внутренние ссылки и sitemap.xml в соответствие с выбранными каноническими адресами — это половина эффекта.
- Проверьте, что языковые версии связаны hreflang, а не склеены canonical'ом.
- Через 3–4 недели вернитесь в отчёт «Индексирование страниц» и сверьте, согласился ли Google с вашим выбором.
Последний шаг пропускают чаще всего, а он и есть проверка результата: если Google по-прежнему выбирает другой канонический URL, значит, где-то остался противоречащий сигнал. Если правильные адреса нужно ещё и заложить в архитектуру нового сайта, это уже задача уровня веб-разработки, а не точечных правок.
