Дубли в WordPress обычно появляются не из-за одной ошибки, а из-за набора мелочей: архивы тегов, пагинация, страницы авторов, параметры в URL, версии для печати, сортировки, UTM-метки и технические страницы плагинов. Если это не контролировать, поисковик тратит обход на мусорные адреса, а в индексе оказываются почти одинаковые страницы.
Ниже разберём рабочую схему: как диагностировать проблему, чем отличается robots.txt от noindex и canonical, что лучше закрывать кодом, а что — настройками плагина или сервера.
Как понять, что у сайта действительно есть проблема с дублями
Сначала не трогайте настройки наугад. Проверьте, какие URL уже попали в индекс и где поисковик видит повторяющийся контент. Для WordPress типичный набор подозрительных страниц выглядит так:
- архивы категорий и тегов с почти одинаковыми анонсами;
- страницы автора на сайте с одним редактором;
- пагинация архивов вида
/page/2/; - страницы с параметрами
?replytocom=,?utm_,?sort=; - версии с
wwwи без, сhttpиhttps; - служебные страницы плагинов, которые не должны индексироваться.
Быстрая диагностика
Откройте в поиске запросы вида site:example.com и посмотрите, не всплывают ли странные URL. В Google Search Console полезно сравнить отчёт по страницам и раздел «Индексирование». Если у вас есть доступ к серверным логам, посмотрите, какие адреса бот запрашивает чаще всего. Иногда проблема не в индексации, а в том, что бот слишком часто ходит по бесполезным страницам.
Ещё один практичный тест — сравнить исходный HTML у канонической страницы и у дубля. Если контент одинаковый, а canonical указывает не туда или отсутствует, это уже повод исправлять шаблон или настройки SEO-плагина.
Что закрывать через robots.txt, а что — через noindex
Это частая ошибка: закрывают всё подряд в robots.txt, а потом удивляются, что страницы всё равно попадают в индекс без сниппета. robots.txt управляет обходом, но не гарантирует удаление из индекса. Если страница уже известна поисковику, надёжнее использовать noindex.
| Подход | Когда использовать | Ограничение |
|---|---|---|
robots.txt | Для служебных разделов, которые не нужно обходить | Не убирает уже проиндексированные URL |
noindex | Для страниц, которые могут быть доступны, но не должны индексироваться | Страница должна быть доступна роботу для чтения мета-тега |
canonical | Для дублей с параметрами, сортировками, пагинацией в некоторых сценариях | Это подсказка, а не жёсткий запрет |
Если нужен именно контроль индексации, обычно разумнее ставить noindex, follow на архивы тегов, авторов, поиска по сайту и служебные страницы. А вот robots.txt оставить для технических каталогов, которые не должны обходиться вообще.
Пошаговое решение для WordPress
1. Проверьте, не дублирует ли сайт сам себя
Сначала убедитесь, что у сайта одна основная версия домена. Должен быть один вариант: либо https://example.com, либо https://www.example.com. Остальные варианты нужно 301-редиректом отправлять на основной адрес. Это делается на уровне веб-сервера или через настройки хостинга, а не через мета-теги.
Если у вас уже стоит SEO-плагин, проверьте, не создаёт ли он отдельные канонические URL для страниц с параметрами. Для архивов и записей canonical должен указывать на чистый адрес без лишних query-параметров.
2. Закройте лишние архивы через настройки SEO-плагина
В большинстве случаев проще и безопаснее управлять индексированием через SEO-плагин, чем править шаблоны вручную. Для архивов тегов, авторов и поиска обычно достаточно включить noindex в настройках соответствующих разделов. Это особенно полезно на небольших сайтах, где архивы не несут самостоятельной ценности.
Если на сайте много дублей из-за технических страниц, можно использовать Clearfy Pro как инструмент для чистки лишних архивов и служебных элементов. Но принцип не меняется: сначала определите, что именно должно индексироваться, а что нет, и только потом включайте ограничения. Ссылка на продукт, если нужен ориентир по функциональности: Clearfy Pro.
3. Добавьте точечные правила в код, если плагина недостаточно
Иногда нужно закрыть не весь тип страниц, а только конкретный сценарий. Например, поисковую выдачу по сайту или страницы с параметром replytocom. В таком случае удобнее добавить фильтр в functions.php дочерней темы или в небольшой mu-plugin.
<?php
add_action('wp_head', function () {
if (is_search() || is_author() || is_tag()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
add_filter('wpseo_canonical', function ($canonical) {
if (is_singular()) {
return get_permalink();
}
return $canonical;
});Первый блок — пример, если вам нужно явно добавить robots-мета для определённых шаблонов. Второй — если используется Yoast SEO и нужно подстраховать canonical на одиночных записях. Если у вас другой SEO-плагин, фильтр будет отличаться, поэтому не копируйте этот код без проверки активного стека.
4. Уберите мусорные параметры из индексации
Параметры ?utm_ сами по себе не страшны, если canonical настроен правильно. Но если на сайте есть страницы, которые реально меняют контент по параметру, нужно решить, какая версия считается основной. Для сортировок, фильтров и внутренних поисков чаще всего правильнее оставить одну каноническую страницу и закрыть остальные от индексации.
Если параметры создаёт плагин, ищите его собственные настройки SEO или отключайте генерацию лишних URL. Если это кастомный код, проверьте, не строятся ли ссылки через add_query_arg() без необходимости.
Как проверить, что решение сработало
После изменений не ограничивайтесь визуальной проверкой. Нужны три уровня контроля:
- в исходном коде страницы должен быть правильный
canonical; - для закрытых разделов должен появиться
noindex; - в Search Console со временем должны уменьшиться дублирующиеся URL в отчётах по индексированию.
Проверьте конкретную страницу через просмотр HTML и убедитесь, что нет конфликтов: например, SEO-плагин добавляет один canonical, а тема — второй. Это частая причина, почему поисковик игнорирует подсказку.
Для быстрой локальной проверки можно посмотреть заголовки ответа и мета-теги через curl:
curl -I https://example.com/tag/news/
curl -s https://example.com/tag/news/ | grep -i robotsЕсли страница должна быть закрыта, но в HTML нет noindex, значит настройка не применена в нужном шаблоне. Если canonical указывает на другой URL без причины, проверьте, не переписывает ли его SEO-плагин или кастомный фильтр.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt и ждёте удаления из индекса
Такой подход работает не всегда. Если URL уже известен поисковику, он может остаться в индексе без контента. Для удаления используйте noindex и дождитесь переобхода.
Ставят noindex на всё подряд
Если закрыть категории, теги, записи автора и саму главную страницу, сайт теряет структуру. Поисковику нужно оставить опорные страницы, которые действительно должны ранжироваться. Не путайте техническую чистку с тотальным запретом на индексацию.
Дублируют canonical в теме и в плагине
Когда canonical выводится из двух мест, поисковик видит конфликт. Оставьте один источник правды: либо SEO-плагин, либо шаблон темы, но не оба сразу.
Удаляют параметры, не проверив аналитику
Иногда параметры нужны для отслеживания кампаний. Их не надо запрещать везде. Лучше исключить из индексации только те URL, которые реально создают дубль контента, а не все query-параметры без разбора.
Практические советы по безопасности и производительности
Чем меньше мусорных страниц обходит бот, тем меньше лишней нагрузки на сайт. Это особенно заметно на больших архивах и сайтах с активной внутренней навигацией. Но не пытайтесь экономить обход ценой скрытия важных страниц от пользователей.
Если правите код, делайте это в дочерней теме или через отдельный mu-plugin. Так обновление темы не затрёт правки. Перед изменениями сохраните резервную копию и проверьте, не конфликтует ли ваш код с SEO-плагином и кэширующим плагином.
Для сайтов, где проблема дублей идёт вместе с лишними архивами, пагинацией и техническим мусором, удобнее сначала навести порядок в структуре, а потом уже оптимизировать шаблоны. В этом сценарии часто помогает связка настроек SEO-плагина и точечных правок в теме, а не один «магический» переключатель.
Если после внедрения изменений часть страниц пропала из поиска слишком резко, не откатывайте всё сразу. Сначала проверьте, какие именно URL выпали: иногда это как раз те страницы, которые и должны были быть закрыты. Если же исчезли важные посадочные, ищите конфликт в noindex, canonical или редиректах.