Явные и неявные дубли страниц: поиск и техническая ликвидация
1. Архитектура и принцип работы
Краулер обходит сайт и складывает URL в очередь. Каждый ответ он хеширует и сравнивает с уже известными документами: совпал хеш тела — явный дубль, близкий шингл-хеш — неявный. Дальше робот смотрит на сигналы: rel=canonical, 301, robots.txt, sitemap, внутренние ссылки. Если сигналы противоречат друг другу, включается эвристика — выбирается URL с большим весом и «чистым» видом. Проблема в том, что неявные дубли (например, ?sort=price_asc и ?sort=price_desc) робот видит как разные документы и тратит на них бюджет обхода. На крупных каталогах это выливается в миллионы лишних запросов, медленную индексацию новых товаров и каннибализацию выдачи. Техническая ликвидация — это не «удалить страницу», а выстроить однозначную цепочку: оставить один URL, остальные закрыть 301 или canonical, убрать из sitemap, поправить внутренние ссылки.
2. Математическая механика и триггеры ранжирования
Механика поиска дублей опирается на сравнение контента. На практике используют SimHash и шинглы: документ режут на n-граммы (обычно n=5 слов), считают хеши, и коэффициент Жаккара J(A,B)=|A∩B|/|A∪B|. Порог для «неявного дубля» — J>0,8–0,9. Для явных достаточно SHA-256 от нормализованного HTML. Нормализация включает: удаление пробелов, регистр, вырезание счётчиков и CSRF-токенов. Дальше работает краулинговый бюджет: Google тратит его по Crawl Budget = Crawl Rate Limit × время, Yandex — через обход по «хосту» с лимитом запросов в секунду (обычно 1–5 rps для среднего сайта). Каждый дубль съедает квоту. Канонизация: rel=canonical — это хинт, а не директива; 301 — директива. При конфликте canonical и 301 побеждает 301. Пагинация: rel=next/prev Google игнорирует с 2019, Yandex частично учитывает. Параметры сортировки и фильтров лучше закрывать в robots.txt с Disallow, но только если они не нужны в индексе — иначе теряете длинный хвост.
3. Специфика в Яндекс (YATI) vs Google
Google жёстче относится к дублям: при явном дубле он выбирает один URL и склеивает сигналы, но может игнорировать canonical, если тот противоречит внутренним ссылкам и sitemap. Yandex исторически агрессивнее склеивает страницы по «похожести» и быстрее понижает в выдаче дублирующие URL, но хуже прощает конфликты сигналов. Для Google критично, чтобы canonical был самоссылающимся на уникальных страницах и указывал на один и тот же URL во всех вариантах. Yandex любит чистый robots.txt и явные 301. Оба поисковика не любят, когда canonical ведёт на 404 или на страницу, закрытую в robots.txt. По пагинации: Google рекомендует не закрывать страницы пагинации, а давать self-canonical, Yandex допускает canonical на первую страницу, но только если контент реально дублируется.
4. Нормативы SLA и диагностическая матрица
| Параметр / Метрика | Эталон по SLA | Критическая ошибка |
|---|---|---|
| Доля дублей в индексе | < 5% | > 15% |
| Краулинговый бюджет на дубли | < 10% запросов | > 30% запросов |
| Конфликты canonical/301 | 0 страниц | > 50 страниц |
5. Пошаговый инженерный протокол внедрения
- Соберите карту URL: выгрузите все адреса из sitemap, логов и внутренних ссылок, сгруппируйте по шаблону (параметры, слеши, регистр, http/https, www).
- Прогоните группы через краулер (Screaming Frog, Sitebulb) с включённым сравнением контента по SimHash/шинглам, отметьте явные и неявные дубли.
- Для каждой группы выберите один канонический URL и примените 301 с остальных; там, где 301 невозможен (параметры сортировки), поставьте rel=canonical и закройте в robots.txt только те, что не нужны в индексе.
- Обновите sitemap и внутренние ссылки на канонические URL, затем мониторьте логи и отчёты «Страницы» в Search Console и «Индексирование» в Вебмастере 2–4 недели.
# Пример правила для nginx: склейка http→https, без www→с www, слеш
server {
listen 80;
server_name example.com www.example.com;
return 301 https://www.example.com$request_uri;
}
server {
listen 443 ssl;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
# Формула похожести: J(A,B)=|A∩B|/|A∪B|, порог дубля J>0.85
6. Типичные ошибки при оптимизации
- Ставят rel=canonical на URL, закрытый в robots.txt или отдающий 404 — поисковик игнорирует такой сигнал, дубль остаётся.
- Закрывают в robots.txt страницы пагинации и фильтров, которые приносят трафик по длинному хвосту, — теряют запросы.
- Оставляют конфликт сигналов: 301 ведёт на один URL, canonical — на другой, sitemap — на третий; робот выбирает сам и часто не то.
