Если в Search Console всплывают дубли с параметрами, архивы тегов, пагинация или служебные страницы начинают конкурировать с основными URL, проблема обычно не в «плохом SEO», а в том, как WordPress отдает канонические адреса и что именно разрешено к индексации. На живом сайте это быстро превращается в лишние обходы, размывание сигналов и мусор в индексе.
Ниже — рабочий сценарий: как найти источник дублей, что можно закрыть через настройки и код, а что лучше не трогать, чтобы не сломать нормальную индексацию.
Как понять, что у вас именно проблема с дублями
Сначала стоит отделить реальные дубли от просто похожих URL. В WordPress они часто появляются из-за:
- параметров в адресе:
?replytocom=,?utm_*, сортировки, фильтры; - архивов тегов и дат, которые дублируют смысл рубрик;
- страниц пагинации, если они попадают в индекс без необходимости;
- служебных страниц автора, поиска и вложений;
- неправильно настроенного
canonicalв теме или плагине; - разных вариантов одного URL со слешем, http/https или www/без www.
Проверка простая: откройте подозрительный URL и посмотрите исходный код. В <head> должен быть один корректный rel="canonical". Если canonical указывает не на ту страницу, которую вы считаете основной, это уже повод искать конфликт темы, SEO-плагина или кастомного кода.
Что смотреть в Search Console и в браузере
В Search Console полезны отчеты по страницам, исключенным из индекса, и по дублированным страницам без выбранной пользователем canonical. В браузере — исходный код и заголовки ответа. Если страница отдает 200 OK, но canonical ведет на другой URL, поисковик может выбрать не тот вариант, который вы ожидали.
Для быстрой диагностики удобно проверить ответ сервера:
curl -I https://example.com/page/И затем открыть HTML:
curl -s https://example.com/page/ | grep -i canonicalЕсли canonical отсутствует, дубли часто начинают размножаться даже на простом сайте.
Что можно закрыть настройками, а что лучше править кодом
Не все дубли нужно решать одинаково. Часть закрывается в SEO-плагине, часть — в robots.txt, а часть вообще не стоит блокировать, потому что поисковику нужен доступ к странице для корректной оценки.
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройки SEO-плагина | Архивы, мета robots, canonical, noindex для служебных страниц | Зависит от конкретного плагина и его конфликтов с темой |
| Код в теме/плагине | Нужна точечная логика для отдельных типов страниц | Требует контроля при обновлениях |
robots.txt | Ограничить обход служебных URL и мусорных параметров | Не убирает URL из индекса, если он уже там |
Если задача — убрать именно индексацию, а не обход, то noindex надежнее, чем запрет в robots.txt. Если нужно сократить нагрузку на обход, тогда уже имеет смысл закрывать служебные разделы от роботов.
Пошаговое решение: canonical, noindex и robots.txt
1. Приведите canonical к одному варианту
В большинстве случаев WordPress и нормальный SEO-плагин уже ставят canonical автоматически. Проблемы начинаются, когда тема добавляет свой тег или плагин дублирует его второй раз. На странице должен быть один canonical, без конфликтов.
Если у вас кастомная тема и canonical отсутствует, можно добавить его через wp_head только если вы точно не используете SEO-плагин, который делает это сам:
add_action( 'wp_head', function () {
if ( is_singular() ) {
echo '<link rel="canonical" href="' . esc_url( get_permalink() ) . '" />' . "\n";
}
}, 1 );Но если на сайте уже стоит Yoast SEO, Rank Math или другой SEO-плагин, не добавляйте свой canonical поверх него. Иначе получите два тега и непредсказуемый выбор поисковика.
2. Закройте служебные страницы от индексации
Для архивов автора, дат, поиска и вложений обычно уместен noindex. В WordPress это лучше делать через SEO-плагин или точечно через фильтры, а не через хаотичную правку шаблонов.
Пример для вложений: перенаправлять attachment pages на сам файл или родительскую запись, если вложения не нужны как отдельные страницы.
add_action( 'template_redirect', function () {
if ( is_attachment() ) {
$parent = wp_get_post_parent_id( get_queried_object_id() );
if ( $parent ) {
wp_safe_redirect( get_permalink( $parent ), 301 );
exit;
}
wp_safe_redirect( home_url( '/' ), 301 );
exit;
}
} );Это не «лечит» все дубли, но убирает один из самых частых источников мусора в индексе.
3. Ограничьте мусорные параметры в robots.txt
Если сайт генерирует много URL с параметрами, можно закрыть от обхода хотя бы очевидный мусор. Но не пытайтесь через robots.txt решить индексацию всего подряд — это не тот инструмент.
User-agent: *
Disallow: /*?replytocom=
Disallow: /*?utm_
Disallow: /search/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpС параметрами нужно быть аккуратнее: если вы закрываете слишком широко, можно случайно заблокировать полезные страницы, которые используют query string для нормальной работы.
4. Уберите дубли архивов, если они не нужны
Если рубрики уже хорошо структурируют контент, а теги только размножают одинаковые подборки, теги можно закрыть от индексации или отключить их вывод в sitemap. Это особенно полезно на контентных сайтах, где теги создавались «на всякий случай» и давно не несут смысла.
Если используете Clearfy Pro, часть таких задач можно закрыть настройками без ручного кода: убрать дубли, отключить лишние архивы, почистить технические страницы. Это не отменяет проверки canonical, но сокращает количество ручной работы.
Как проверить, что решение сработало
После изменений не ограничивайтесь визуальной проверкой. Нужны три шага:
- Откройте несколько типов страниц: запись, рубрику, тег, архив автора, вложение.
- Проверьте, что canonical указывает на правильный URL и не дублируется.
- Посмотрите HTTP-ответ и мета robots, если вы меняли правила индексации.
Полезно сравнить исходный код до и после:
curl -s https://example.com/category/news/ | grep -i -E 'canonical|robots'Если вы закрывали вложения через редирект, проверьте код ответа:
curl -I https://example.com/sample-attachment/Ожидаемое поведение — 301 на родительскую запись или на главную, если родителя нет. Если страница продолжает отдавать 200, значит правило не сработало или конфликтует с другим хуком.
Частые ошибки и как их исправить
- Два canonical на странице. Обычно это конфликт темы и SEO-плагина. Оставьте только один источник генерации canonical.
- Закрыли URL в robots.txt, но он остался в индексе. Это нормально: запрет на обход не равен удалению из индекса. Нужен
noindexили 301. - Скрыли теги, но не убрали ссылки на них из сайта. Робот все равно будет находить эти URL через внутренние ссылки. Либо удаляйте ссылки, либо меняйте структуру контента.
- Поставили 404 на вложения без проверки родителя. На сайтах с медиа это ломает старые ссылки из контента и может ухудшить UX.
- Закрыли слишком много страниц от индексации. Если noindex получил полезный архив, вы сами отрезали поисковику путь к тематической навигации.
Практические советы по безопасности и производительности
Если правите canonical, редиректы и robots через код, держите изменения в дочерней теме или в небольшом mu-plugin. Так они не пропадут после обновления темы. Перед выкладкой проверьте, что код не выполняется на каждом запросе без необходимости и не добавляет лишних запросов к базе.
Для больших сайтов полезно сначала собрать список проблемных URL из логов и Search Console, а уже потом точечно править правила. Массовые запреты «на всякий случай» часто создают больше проблем, чем решают.
Если нужен более системный набор инструментов для чистки дублей и технического мусора, имеет смысл смотреть в сторону плагинов, которые умеют управлять архивами, мета-тегами и служебными страницами без ручного вмешательства. Но даже в этом случае проверка canonical и индексации остается обязательной.
После внедрения изменений дайте поисковику время переобойти страницы и снова проверьте отчеты в Search Console. Если дубли были вызваны внутренней структурой сайта, эффект обычно видно не сразу, а после повторного обхода.