В WordPress дубли чаще всего появляются не из-за «плохого SEO», а из-за штатного поведения CMS: архивы по датам, страницы вложений, пагинация, теги, авторы, параметры в URL, версии с ?replytocom и технические страницы плагинов. Если оставить это как есть, поисковик тратит краулинговый бюджет на мусорные URL, а в индексе начинают жить страницы, которые не должны конкурировать с основными материалами.
Ниже — рабочая схема: сначала находим источник дублей, потом выбираем способ закрытия, затем проверяем, что страница действительно выпала из индекса и не сломала навигацию.
Где именно появляются дубли в WordPress
Перед правками важно понять, какой тип дубля у вас вообще есть. Одно дело — архивы тегов, другое — страницы вложений или параметры сортировки. Для каждого случая решение отличается.
Типовые источники дублей
- архивы тегов и категорий, которые дублируют смысл записей;
- страницы вложений с тонким или пустым контентом;
- авторские и датированные архивы на небольшом сайте;
- страницы пагинации, если они индексируются без необходимости;
- URL с параметрами, например
?replytocom=,?utm_*, фильтры и сортировки; - служебные страницы плагинов, которые не несут ценности для поиска.
Диагностика проблемы: что проверить до изменений
Сначала смотрим не в настройки, а в фактические URL, которые уже попали в индекс или доступны для обхода. Это можно сделать вручную и через инструменты поисковой системы.
Что искать в отчётах и в выдаче
- в поиске по сайту:
site:example.comи дополнительные операторы по типу URL; - в Google Search Console или Яндекс Вебмастере: страницы с дублирующимся заголовком, канонические URL, исключённые страницы;
- в логике сайта: есть ли архивы, которые повторяют контент записей почти без добавленной ценности;
- в коде темы и плагинов: не генерируются ли отдельные шаблоны для вложений, авторов, меток и дат без необходимости.
Если сайт небольшой, полезно просто пройтись по структуре URL и выписать всё, что выглядит как вторичный адрес одной и той же сущности. Это быстрее, чем сразу лезть в robots.txt или массово ставить noindex.
Пошаговое решение: как закрыть дубли без лишнего риска
Лучший порядок действий такой: сначала убираем из индекса явно бесполезные страницы, потом настраиваем каноникал, и только после этого при необходимости ограничиваем обход через robots.txt. Если сделать наоборот, можно случайно скрыть нужные URL от поисковика, но оставить их в индексе как «пустые» страницы.
Шаг 1. Закройте вложения и тонкие архивы
Если у вас есть страницы вложений, чаще всего их нужно либо редиректить на родительскую запись, либо закрывать от индексации. Для этого удобнее использовать SEO-плагин или код в теме/мини-плагине. Если нужен быстрый и безопасный вариант без ручной доработки шаблонов, в Clearfy Pro есть инструменты для чистки дублей и технических страниц: Clearfy Pro.
Если делаете через код, не пытайтесь «ломать» архивы целиком. Лучше точечно отключить индексацию там, где контент не нужен.
<?php
add_action('wp', function () {
if (is_attachment()) {
wp_redirect(get_permalink(get_post_field('post_parent', get_the_ID())), 301);
exit;
}
});
Этот пример подходит только если у вложения есть родительская запись. Если родителя нет, редиректить нужно на релевантную страницу сайта, а не на главную без разбора.
Шаг 2. Добавьте noindex для архивов, которые не должны ранжироваться
Для тегов, авторов и датированных архивов решение зависит от структуры сайта. На контентных проектах теги часто полезны, но на маленьких сайтах они создают почти пустые страницы. Авторские архивы на сайте с одним автором обычно тоже не нужны в поиске.
Если используете Yoast SEO, Rank Math или аналогичный плагин, настройка делается в интерфейсе. Если нужен кодовый вариант, можно добавить мета-тег robots для конкретных шаблонов:
<?php
add_action('wp_head', function () {
if (is_tag() || is_date() || is_author()) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
});
Такой подход не запрещает обход ссылок внутри страницы, но просит поисковик не держать сам архив в индексе. Это лучше, чем закрывать всё через robots.txt, если страница уже известна поиску.
Шаг 3. Проверьте canonical
Если на сайте есть параметры в URL, пагинация или альтернативные адреса одной и той же страницы, canonical должен указывать на основную версию. Во многих SEO-плагинах это работает автоматически, но после кастомных шаблонов и фильтров лучше проверить руками.
Минимальная проверка простая: откройте страницу, посмотрите исходный код и найдите rel="canonical". Он должен вести на чистый URL без лишних параметров, если параметры не меняют смысл страницы.
Что выбрать: плагин, код или robots.txt
Универсального ответа нет. Для большинства сайтов лучше комбинировать методы, а не пытаться решить всё одним robots.txt.
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| SEO-плагин | Нужно быстро закрыть архивы, теги, авторов, вложения | Меньше риска сломать шаблон | Зависимость от настроек плагина |
| Код в теме/мини-плагине | Нужна точечная логика под конкретный сайт | Полный контроль | Нужно тестировать после обновлений |
| robots.txt | Нужно ограничить обход технических URL | Просто и быстро | Не убирает уже известные URL из индекса мгновенно |
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковик видит именно то, что вы задумали.
- откройте проблемный URL и проверьте HTTP-статус;
- посмотрите исходный код на наличие
noindexи canonical; - проверьте, не осталось ли внутренних ссылок на закрытые страницы;
- в Search Console запросите проверку URL и посмотрите, как робот интерпретирует страницу;
- через несколько дней сравните количество исключённых и проиндексированных страниц в отчётах.
Если закрывали вложения редиректом, убедитесь, что они отдают именно 301, а не 302. Если ставили noindex, проверьте, что страница не блокируется в robots.txt раньше, чем поисковик увидит мета-тег. Иначе робот может не дойти до инструкции на странице.
Частые ошибки и как их исправить
Закрыли в robots.txt, но URL остался в индексе
Это частая ситуация. Robots.txt запрещает обход, но не гарантирует мгновенное удаление из индекса. Если URL уже известен поисковику, сначала дайте ему увидеть noindex или редирект, а потом при необходимости ограничьте обход.
Поставили noindex на все архивы подряд
Так можно случайно убрать полезные страницы категорий, которые приводят трафик. Сначала оцените, какие архивы реально дают ценность. На новостном или тематическом сайте категории часто нужны, а на сайте-визитке — нет.
Редирект вложений на главную
Это плохой шаблон по умолчанию. Если у вложения есть родитель, редирект должен быть на родительский материал. Если родителя нет, лучше отправить на близкую по смыслу страницу или закрыть от индексации без агрессивного редиректа.
Сломали пагинацию
Иногда после правок noindex или canonical поисковик перестаёт нормально обходить страницы 2, 3, 4 архивов. Проверяйте, что ссылки на пагинацию остаются рабочими, а каноникал не указывает на первую страницу там, где это мешает индексации нужного контента.
Практические советы по безопасности и производительности
Если вы вносите изменения кодом, лучше не править functions.php активной темы напрямую. Для точечных SEO-правок безопаснее использовать мини-плагин или дочернюю тему, чтобы не потерять изменения после обновления.
Не ставьте несколько SEO-плагинов одновременно ради одной настройки. Дубли мета-тегов robots и canonical часто появляются именно из-за конфликта плагинов. После установки нового решения проверьте исходный код страницы и отключите дублирующую логику в старом плагине.
Если сайт большой, сначала тестируйте изменения на staging-копии. Особенно это важно для редиректов и массового noindex: одна ошибка в шаблоне может затронуть тысячи URL.
Когда нужно быстро навести порядок в дублях, технических страницах и SEO-настройках без ручной сборки всего с нуля, имеет смысл посмотреть на Clearfy Pro, но только как на инструмент для конкретной задачи, а не замену проверке структуры сайта.
Если после внедрения вы видите, что в индексе остаются старые URL, не спешите менять всё подряд. Сначала проверьте, доступна ли страница для обхода, есть ли на ней canonical, не ведёт ли она на себя через цепочку редиректов и не блокирует ли её robots.txt раньше времени. В WordPress именно последовательность этих проверок обычно и решает проблему.