Если на сайте появились десятки или сотни почти одинаковых URL, поисковик обычно не «понимает», какой из них считать основным. Чаще всего это происходит из-за фильтров, сортировок, параметров в адресе, страниц архива с пагинацией и технических дублей, которые создаёт тема или плагин. В результате в индексе оказываются лишние страницы, а вес распыляется по копиям.
Ниже разберём, как диагностировать источник дублей в WordPress, какие URL закрывать от индексации, а какие лучше оставить доступными для обхода, и как проверить, что после правок ничего не сломалось.
Как понять, что проблема именно в дублях
Сначала не трогайте настройки вслепую. Смотрите на конкретные признаки:
- в поиске появляются страницы с параметрами вроде
?sort=,?filter=,?orderby=; - одна и та же запись доступна по нескольким адресам;
- в Google Search Console растёт число «Просканировано, но не проиндексировано»;
- в отчёте по страницам видны дубли с разными URL, но одинаковым title и содержимым;
- на сайте есть архивы, теги, рубрики и страницы пагинации, которые почти не отличаются друг от друга.
Что проверить в первую очередь
Откройте несколько проблемных URL и сравните:
<link rel="canonical">в исходном коде;- мета-тег
robots; - HTTP-ответ страницы;
- есть ли редирект на «чистый» URL без параметров.
Если canonical указывает на саму страницу с параметрами, а не на основную версию, поисковик может продолжить считать её отдельной страницей. Если же страница с фильтром полезна только для пользователя, но не должна индексироваться, canonical сам по себе не всегда решает задачу — нужен ещё запрет на индексацию или закрытие параметров на уровне логики генерации URL.
Диагностика: откуда именно берутся дубли
В WordPress дубли обычно появляются из четырёх источников. У каждого свой способ исправления.
| Источник | Пример URL | Что делать |
|---|---|---|
| Параметры фильтра | /catalog/?color=red&size=m | Закрыть от индексации, при необходимости оставить для обхода |
| Сортировка | ?orderby=price | Обычно noindex и canonical на базовую страницу |
| Пагинация | /blog/page/2/ | Не закрывать бездумно; зависит от структуры сайта |
| Технические архивы | /tag/, /author/, /date/ | Оставить только если они реально нужны для поиска |
Если сайт небольшой, проще всего начать с отчёта Search Console и выгрузки URL из логов сервера. На более живом проекте полезно ещё пройтись краулером вроде Screaming Frog и посмотреть, какие адреса плодятся массово.
Пошаговое решение: что закрывать, а что оставить
1. Уберите из индекса служебные архивы, если они не нужны
Теги, архивы автора и даты часто создают тонкие страницы без ценности. Если они не используются как отдельные посадочные, их можно закрыть от индексации через SEO-плагин или кодом. Важно не путать запрет индексации с удалением страницы: пользователи и боты могут продолжать её открывать, но поисковик не должен включать её в выдачу.
Если вы используете SEO-плагин, проверьте настройки для архивов. Если работаете кодом, можно добавить noindex для конкретных типов архивов:
add_filter('wp_robots', function ($robots) {
if (is_tag() || is_author() || is_date()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Этот вариант не ломает доступ к страницам, но просит поисковик не индексировать их. Для большинства сайтов этого достаточно.
2. Закройте URL с параметрами фильтра и сортировки
Если фильтры создают отдельные URL, а их содержимое не должно попадать в поиск, лучше отдать им noindex и привести canonical к базовой странице. Для этого удобно использовать wp_robots и фильтр canonical, если тема или плагин его не выставляют корректно.
add_filter('wp_robots', function ($robots) {
if (!empty($_GET['sort']) || !empty($_GET['orderby']) || !empty($_GET['filter'])) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});
add_filter('get_canonical_url', function ($canonical) {
if (!empty($_GET['sort']) || !empty($_GET['orderby']) || !empty($_GET['filter'])) {
return remove_query_arg(array('sort', 'orderby', 'filter'));
}
return $canonical;
});Здесь есть важный нюанс: не все темы и плагины используют get_canonical_url одинаково. Если canonical уже выводится SEO-плагином, проверьте, не конфликтует ли ваш код с его логикой. Иногда проще настроить исключения в самом плагине, чем перехватывать вывод фильтром.
3. Не закрывайте пагинацию без проверки
Страницы /page/2/, /page/3/ и дальше не всегда являются дублями. Если у вас блог, каталог или архив с большим количеством материалов, пагинация помогает поисковику добраться до старых записей. Закрывать её от индексации стоит только после проверки, что:
- страницы пагинации не получают трафик;
- они не нужны для внутренней перелинковки;
- на них нет уникального контента, который должен индексироваться.
Если сомневаетесь, не ставьте noindex на пагинацию автоматически. Это одна из самых частых ошибок: сайт теряет глубину обхода, а старые материалы становятся хуже доступны.
Когда лучше решать через плагин, а когда через код
Если задача типовая и у вас уже стоит SEO-плагин, проще использовать его настройки. Если же дубли создаёт кастомная тема, нестандартный фильтр или собственный каталог, код даёт больше контроля.
| Подход | Плюсы | Минусы |
|---|---|---|
| Плагин | Быстрее внедрить, меньше риска сломать шаблон | Не всегда умеет тонко работать с параметрами URL |
| Код в теме/плагине | Можно закрыть только нужные сценарии | Нужна проверка после обновлений |
| Серверные правила | Подходит для массовых технических URL | Легко переборщить и закрыть полезные страницы |
Если нужен более широкий набор технических правок — от чистки дублей до управления индексируемыми архивами и служебными страницами — иногда удобнее собрать это в одном SEO-инструменте. Например, в Clearfy Pro есть набор функций для удаления дублей и технической чистки сайта: https://wpshop.ru/plugins/clearfy.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой в браузере. Нужны три уровня контроля.
Проверка в исходном коде
Откройте проблемный URL и убедитесь, что:
- canonical ведёт на основную страницу без лишних параметров;
- в
meta robotsестьnoindexтам, где это нужно; - страница не отдаёт неожиданный редирект на другую версию.
Проверка HTTP-ответа
Для технических URL полезно проверить заголовки через curl:
curl -I "https://example.com/catalog/?sort=price"Смотрите, нет ли цепочки редиректов, а также не отдаёт ли страница ошибку 200 там, где вы ожидали 301 или 404. Если URL должен существовать для пользователя, но не индексироваться, код ответа обычно остаётся 200 — это нормально.
Проверка в Search Console
После переобхода страницы проверьте:
- исчезли ли лишние URL из отчёта по страницам;
- не выросло ли число исключённых страниц из-за случайного
noindex; - не появились ли новые дубли с другими параметрами.
Изменения в индексе не происходят мгновенно, поэтому оценивайте результат по динамике, а не по одному дню.
Частые ошибки и как их исправить
Ставят noindex на всё подряд
Иногда после первой чистки закрывают и теги, и рубрики, и пагинацию, и архивы автора. В итоге поисковик теряет структуру сайта. Исправление простое: оставляйте noindex только там, где страница действительно не несёт самостоятельной ценности.
Путают canonical и запрет индексации
Canonical помогает выбрать основную версию, но не всегда убирает дубли из обхода. Если URL с параметрами должен быть исключён из поиска, одного canonical может быть мало. Нужна связка: canonical + noindex или редирект, если страница вообще не должна существовать.
Закрывают URL в robots.txt и ждут, что они исчезнут из индекса
Это частая ошибка. Запрет в robots.txt мешает обходу, но не гарантирует удаление уже проиндексированных страниц. Если URL уже в индексе, сначала дайте поисковику увидеть noindex или настройте редирект/404, а потом при необходимости ограничивайте обход.
Ломают фильтры для пользователей
Если фильтр нужен для навигации по каталогу или архиву, не убирайте его полностью. Иногда достаточно оставить URL доступным, но закрыть его от индексации и убрать из sitemap. Пользовательский сценарий при этом сохраняется.
Что ещё проверить на сайте после чистки дублей
Когда проблема с дублями решена, имеет смысл пройтись по соседним техническим зонам:
- не генерируются ли лишние версии с
wwwи безwww; - нет ли дублей из-за http/https;
- не создаёт ли тема отдельные архивы для одного и того же контента;
- не попадают ли в sitemap URL с параметрами;
- не дублируются ли мета-теги title и description на разных типах страниц.
Если сайт активно растёт, такие проверки лучше делать после обновления темы, SEO-плагина или кастомных фильтров. Именно в этот момент чаще всего появляются новые технические дубли, которые потом долго мешают индексации.