В WordPress дубли чаще всего появляются не из-за «плохого SEO», а из-за штатной логики: архивы тегов и дат, страницы вложений, пагинация, параметры сортировки, версии с ?replytocom, служебные страницы автора и поиск по сайту. Если закрывать всё подряд в robots.txt, можно случайно спрятать от обхода нужные URL и усложнить переиндексацию. Если ставить noindex без разбора, поисковик продолжит тратить краулинговый бюджет на мусорные страницы. Рабочая схема обычно комбинированная: что-то запрещаем к обходу, что-то оставляем доступным, но просим не индексировать.
Ниже — практический разбор, как разделить эти случаи, где в WordPress лучше использовать noindex, а где — Disallow, и как проверить, что после правок дубли действительно исчезли из индекса, а не просто стали недоступны вам в браузере.
Какие дубли в WordPress встречаются чаще всего
Сначала полезно понять, что именно вы хотите убрать. В WordPress одна и та же запись может быть доступна по нескольким адресам: основной URL записи, архив автора, архив рубрики, архив тега, страницы пагинации, RSS, страницы вложений, а иногда ещё и через параметры в URL. Не все такие адреса нужно закрывать одинаково.
Типовые источники дублей
- Архивы тегов и дат — часто дублируют смысл рубрик или просто собирают слишком тонкие подборки.
- Страницы вложений — отдельная страница под изображение почти всегда бесполезна для индексации.
- Пагинация архивов — сама по себе не дубль, но может создавать много слабых страниц.
- Параметры URL — сортировка, фильтры, UTM, внутренний поиск,
?replytocom. - Служебные страницы — результаты поиска по сайту, страницы автора на маленьких проектах, архивы дат без контента.
Ошибка здесь в том, что владельцы сайта видят «много страниц в индексе» и начинают закрывать всё через robots.txt. Это не всегда помогает: если страница уже известна поисковику, запрет на обход не гарантирует удаление из индекса. Для удаления из выдачи часто нужен именно noindex или корректный редирект на канонический URL.
Диагностика: что закрывать, а что оставить
Перед правками откройте несколько примеров URL и проверьте, как они отдаются. Важно понять три вещи: есть ли у страницы реальный контент, нужна ли она пользователю и должна ли она вообще попадать в поиск.
Быстрая проверка вручную
- Откройте URL дубля в браузере и посмотрите, это отдельная полезная страница или технический вариант основного контента.
- Проверьте исходный код на наличие
<meta name="robots" content="noindex">. - Посмотрите заголовок
X-Robots-Tag, если он используется на уровне сервера. - Сравните canonical: у дубля он должен указывать на основную страницу, если страница вообще должна существовать.
Если у вас есть доступ к консоли, удобно быстро проверить заголовки так:
curl -I https://example.com/attachment-page/Или посмотреть, не отдает ли страница noindex в HTML:
curl -s https://example.com/attachment-page/ | grep -i robotsЕсли вы видите, что страница техническая и не нужна в поиске, дальше выбирайте между noindex и запретом обхода. Если страница уже должна исчезнуть из индекса, но при этом поисковик должен иметь возможность увидеть сигнал noindex, не закрывайте её сразу в robots.txt.
Пошаговое решение: robots.txt, noindex и canonical
Ниже — рабочая схема, которая обычно даёт предсказуемый результат. Она не универсальна для всех сайтов, но хорошо подходит для типичных WordPress-проектов.
Шаг 1. Закройте от обхода только то, что не нужно сканировать
robots.txt имеет смысл использовать для URL, которые не должны тратить краулинговый бюджет: внутренний поиск, служебные параметры, некоторые системные каталоги. Но не стоит туда складывать всё подряд.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /*?replytocom=
Disallow: /*?orderby=
Disallow: /*?filter=
Это пример, а не готовый шаблон для любого сайта. Если у вас нет параметра orderby или filter, не добавляйте его просто «на всякий случай». Чем больше лишних правил, тем выше риск закрыть полезные адреса.
Шаг 2. Поставьте noindex на страницы, которые должны быть доступны, но не индексироваться
Для архивов тегов, дат, автора, поиска по сайту и страниц вложений часто лучше использовать noindex, follow. Тогда поисковик может пройти по ссылкам, но не будет держать саму страницу в индексе.
Если вы управляете этим через код темы или плагина, можно добавить фильтр для robots-мета. В WordPress есть фильтр wp_robots, который позволяет менять директивы без правки шаблонов вручную.
add_filter( 'wp_robots', function( array $robots ) {
if ( is_search() || is_attachment() || is_date() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Если вы используете SEO-плагин, проверьте, не конфликтует ли он с вашим кодом. Два источника noindex одновременно обычно не ломают сайт, но потом сложно понять, кто именно выставил директиву и почему она не меняется.
Шаг 3. Для дублей с параметрами используйте canonical или редирект
Если параметр не меняет смысл страницы, лучше не плодить отдельные URL. В идеале такие варианты должны либо редиректить на чистый адрес, либо иметь canonical на основную страницу. Это особенно важно для UTM и сортировок, которые появляются в ссылках из рекламы или внутренних блоков.
Пример: если у вас есть URL с параметром ?replytocom, его обычно не нужно индексировать как отдельную страницу. Для таких случаев лучше не пытаться «лечить» только robots.txt — поисковик может продолжать видеть URL в ссылках и держать его в обходе.
Когда лучше использовать плагин, а когда код
Если задача типовая и вы не хотите поддерживать код в теме, проще использовать SEO-плагин или инструмент для чистки дублей. Но если у вас кастомная логика архивов, код даёт больше контроля. Ниже — короткое сравнение.
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин | Стандартные архивы, noindex, canonical, sitemap | Меньше гибкости, возможны конфликты настроек |
| Код в теме/плагине | Нестандартные типы записей, точечные правила | Нужно следить за обновлениями и тестировать |
| Только robots.txt | Служебные URL, которые не должны обходиться | Не решает удаление уже известных дублей |
Если нужен именно набор для чистки дублей и технической SEO-настройки, уместно посмотреть в сторону инструментов вроде Clearfy Pro: там есть функции для отключения лишних архивов, страниц вложений и части служебной нагрузки. Но даже с плагином важно понимать, что именно он меняет, иначе легко закрыть не тот тип страниц.
Проверка результата после внедрения
После правок не ориентируйтесь только на то, что страница «открывается» или «не открывается». Проверять нужно именно сигналы для поисковика.
Что проверить в первую очередь
- robots.txt — правила не должны блокировать важные разделы сайта.
- meta robots — на нужных страницах должен быть
noindex. - canonical — у дублей он должен указывать на основную страницу, если дубль не закрыт полностью.
- HTTP-статус — если страница удалена навсегда, лучше отдавать корректный редирект или 404/410, а не маскировать проблему.
- Search Console — в отчётах по индексированию должны постепенно исчезать лишние URL.
Для быстрой проверки можно открыть исходный код и поискать robots-мета вручную. Если работаете через терминал, удобно проверить заголовки и canonical:
curl -s https://example.com/page/ | grep -i canonical
curl -I https://example.com/page/Если вы закрывали страницы вложений, убедитесь, что они действительно перестали индексироваться, а не просто стали недоступны из-за случайного запрета в robots.txt. В последнем случае поисковик может ещё долго держать старые URL в базе без возможности переобхода и обновления сигнала.
Частые ошибки и как их исправить
Закрыли в robots.txt то, что нужно удалить из индекса
Это самая частая ошибка. Если страница уже в индексе, одного Disallow мало. Сначала дайте поисковику увидеть noindex или сделайте редирект на канонический URL, а уже потом при необходимости ограничивайте обход.
Поставили noindex на все архивы подряд
Иногда это ломает полезную структуру сайта: рубрики перестают ранжироваться, а внутренние ссылки теряют смысл. Архивы нужно оценивать по отдельности. Если рубрика — полноценная посадочная страница с текстом и подборкой материалов, её не стоит бездумно закрывать.
Оставили страницы вложений без canonical
Если медиа-страницы открыты, но не нужны, они могут создавать мусорные URL. В таком случае лучше либо редиректить вложение на файл/родительскую запись, либо закрыть страницу вложения от индексации и проверить, что она не участвует в выдаче.
Смешали несколько SEO-плагинов
Когда один плагин ставит noindex, другой переписывает canonical, а третий генерирует sitemap, диагностика становится почти невозможной. На практике лучше оставить один источник SEO-логики и отключить дублирующие функции в остальных инструментах.
Практические советы по безопасности и производительности
Чистка дублей полезна не только для SEO. Меньше лишних URL — меньше обхода, меньше нагрузки на сервер и меньше шансов, что поисковик будет тратить время на бесполезные страницы. Но не стоит превращать это в массовую зачистку без проверки.
- Не редактируйте
robots.txt«на глаз» в продакшене без бэкапа. - После изменения правил проверьте кэш: иногда старый
robots.txtили HTML остаётся в кеше CDN. - Если используете кэш-плагин, очистите его после правок canonical и robots-мета.
- Не закрывайте CSS, JS и изображения, если они нужны для рендеринга страниц.
- Для крупных сайтов сначала тестируйте на нескольких типах URL, а не на всём сайте сразу.
Если у вас есть доступ к серверу или CDN, полезно отдельно проверить, не переписывает ли он заголовки X-Robots-Tag или canonical. Иногда проблема вообще не в WordPress, а в прокси, который добавляет старые правила поверх новых.
Когда схема настроена правильно, вы увидите три признака: в индексе остаются только нужные страницы, технические URL перестают появляться в отчётах, а поисковик не тратит время на бесполезные варианты одного и того же контента. Это и есть нормальный результат — без лишнего шума и без попытки закрыть полсайта одним правилом.