Дубли в WordPress часто появляются не из-за «плохого контента», а из-за технических деталей: URL с параметрами, страницы архивов, пагинация, сортировки, UTM-метки, версии с и без слеша. В результате поисковик видит несколько адресов с одинаковым содержимым и начинает выбирать канонический URL не так, как вы ожидали.
Ниже разберём, как быстро найти такие дубли, что именно закрывать от индексации, а что лучше оставить и склеить через canonical или редирект.
Когда проблема действительно в дублях, а не в контенте
Сначала стоит убедиться, что речь именно о технических дублях. Если страница плохо ранжируется из-за слабого текста, переписывание robots.txt не поможет. Но если в индексе есть несколько версий одной и той же страницы, это уже задача на уровне URL и шаблонов.
Типичные источники дублей
- параметры в адресе:
?utm_source=,?sort=,?filter=; - страницы пагинации архивов и рубрик;
- версии с
wwwи безwww; - URL со слешем на конце и без него;
- страницы поиска по сайту;
- архивы тегов, дат и авторов, если они не несут ценности;
- дубли из-за неправильного
rel=canonicalв теме или плагине.
Если у вас включены фильтры в каталоге, сортировки в блоге или UTM-метки в ссылках из рассылок, дубли почти неизбежны. Вопрос только в том, как именно вы их ограничите.
Диагностика: где искать дубли в WordPress
Начинать лучше не с кода, а с проверки реальных URL. Откройте Search Console, отчёты по страницам и вручную сравните несколько адресов, которые ведут на один и тот же контент. Если есть доступ к серверным логам, полезно посмотреть, какие варианты URL чаще всего запрашивают боты и пользователи.
Ещё один быстрый способ — проверить исходный код страницы и найти canonical:
<link rel="canonical" href="https://example.com/page/" />Если canonical указывает не на ту версию, которую вы хотите видеть в индексе, это уже конкретная ошибка шаблона или плагина SEO.
Мини-чек-лист диагностики
- Есть ли у одной страницы несколько URL с одинаковым контентом?
- Совпадает ли canonical с основным адресом?
- Не индексируются ли страницы поиска и фильтров?
- Не создаёт ли тема отдельные архивы без смысла для SEO?
- Не раздувают ли индекс параметры сортировки и UTM?
Что делать: сравнение подходов
| Подход | Когда использовать | Минус |
|---|---|---|
| 301 редирект | Если старый URL больше не нужен и есть один правильный адрес | Нельзя применять ко всем параметрам подряд без анализа |
| canonical | Если страницы похожи, но должны существовать для пользователя | Поисковик может проигнорировать подсказку |
| noindex | Для служебных страниц, поиска, фильтров, архивов без ценности | Страница остаётся доступной, но не должна попадать в индекс |
На практике чаще всего нужен не один инструмент, а комбинация: canonical для похожих страниц, noindex для служебных, редирект для устаревших адресов.
Пошаговое решение без лишних рисков
1. Закройте от индексации служебные страницы
Если у вас есть страницы поиска, результаты фильтров или архивы, которые не должны ранжироваться, проще всего добавить noindex на уровне шаблона или через SEO-плагин. Если вы работаете кодом, можно управлять robots meta через фильтр wp_robots.
add_filter('wp_robots', function ($robots) {
if (is_search() || is_author() || is_date()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Этот вариант подходит для стандартных архивов WordPress. Для страниц фильтров с параметрами нужно отдельно проверять логику шаблона, потому что is_search() их не поймает.
2. Склейте параметры URL с основной страницей
Если дубли создаются только из-за UTM-меток или сортировки, основной адрес должен оставаться каноническим. Для этого canonical должен указывать на чистый URL без параметров. В большинстве случаев WordPress и SEO-плагины делают это сами, но лучше проверить на конкретных шаблонах.
Если нужно принудительно убрать параметры из canonical на страницах записей и страниц, можно использовать фильтр SEO-плагина, если он есть, либо не ломать стандартный canonical WordPress. Самый безопасный путь — не переписывать canonical без необходимости, а убрать генерацию лишних URL на уровне ссылок и форм.
3. Уберите лишние архивы и таксономии
Теги, авторские архивы, архивы дат и пустые рубрики часто создают шум в индексе. Если они не несут ценности, их лучше закрыть от индексации или отключить вывод в шаблоне. Важно: не удаляйте всё подряд. Если архив рубрики реально нужен как посадочная страница, его лучше оставить и доработать.
Для отключения архивов авторов и дат в шаблоне можно использовать редирект на главную или на релевантную страницу, но только если это не ломает навигацию и внутренние ссылки.
add_action('template_redirect', function () {
if (is_author() || is_date()) {
wp_safe_redirect(home_url('/'), 301);
exit;
}
});Это жёсткий вариант. Он подходит не всем сайтам, поэтому сначала проверьте, нет ли у вас трафика на такие архивы.
4. Нормализуйте URL с www, слешем и протоколом
Если сайт доступен по нескольким вариантам домена, нужен один основной формат. Обычно это решается настройками сервера и WordPress Address/Site Address. На уровне WordPress не стоит пытаться чинить это кодом, если проблема в конфигурации веб-сервера.
Проверьте, что все варианты ведут на один URL:
http://example.com;https://example.com;https://www.example.com;https://example.com/.
Если где-то открывается отдельная версия без редиректа, это уже источник дублей.
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой. Откройте несколько проблемных URL и посмотрите:
- какой код ответа отдаёт сервер;
- есть ли 301 там, где он нужен;
- какой canonical указан в исходнике;
- не остались ли страницы в sitemap, если их надо скрыть;
- не появились ли циклы редиректов.
Минимальная ручная проверка через curl может выглядеть так:
curl -I https://example.com/page/?utm_source=test
curl -I https://example.com/author/admin/
Если всё настроено правильно, первый URL должен либо отдавать 200 с canonical на чистую страницу, либо редиректить на чистый адрес, а второй — вести себя так, как вы задумали в своей политике индексации.
Частые ошибки и как их исправить
Ставят noindex на нужные страницы
Это частая ошибка при массовой чистке индекса. Если закрыть от индексации полезные рубрики или посадочные страницы, трафик просядет не из-за дублей, а из-за потери нормальных страниц входа. Сначала разделите служебные и коммерчески важные URL.
Делают 301 на всё подряд
Редиректить все параметры без разбора опасно. Иногда параметр нужен для логики страницы, и его удаление ломает фильтр или сортировку. Для UTM-меток редирект обычно не нужен: они не должны менять контент страницы.
Ломают canonical в теме
Если в шаблоне вручную собирают canonical через $_SERVER['REQUEST_URI'], легко получить дубли с параметрами или неправильным доменом. Лучше опираться на штатные функции WordPress или SEO-плагина, чем собирать URL вручную.
Оставляют архивы без содержания
Пустые рубрики, теги без записей и архивы дат создают страницы, которые не помогают пользователю. Если они не нужны как часть структуры сайта, их лучше закрыть или удалить из навигации.
Что проверить в безопасности и производительности
Чистка дублей полезна не только для SEO. Чем меньше лишних URL, тем проще обход сайта ботами и тем меньше мусора в отчётах. Но не стоит превращать это в бесконечную генерацию редиректов и правил в .htaccess.
Практически полезные правила:
- не плодить редирект-цепочки;
- не закрывать в robots.txt то, что должно быть доступно пользователю;
- не использовать одинаковые шаблоны для всех архивов без проверки;
- не удалять параметры, которые нужны для работы фильтров или авторизации;
- после правок очищать кэш страницы и кэш CDN, если он есть.
Если нужен более широкий аудит дублей, мета-тегов и технической чистки, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином логику индексации всё равно нужно проверять вручную на своих шаблонах.
Если после правок дубли всё ещё появляются, обычно проблема не в одном параметре, а в связке: тема генерирует лишние архивы, SEO-плагин ставит не тот canonical, а сервер не приводит домен к единому виду. В таких случаях помогает не очередной плагин, а последовательная проверка URL-структуры и исходного кода страниц.