Как закрыть от индексации дубли страниц в WordPress через robots.txt и noindex

Если в поиске всплывают архивы, страницы вложений, результаты поиска по сайту или параметры URL, проблема обычно не в «плохом SEO», а в том, что WordPress по умолчанию генерирует слишком много технических адресов. Часть из них полезна для пользователей, но почти всегда лишняя для индексации. Ниже — рабочая схема: что именно закрывать, чем закрывать и как проверить, что вы не сломали доступ к нужным страницам.

Что именно считать дублем в WordPress

Не каждый повторяющийся URL — это дубль в строгом смысле. Для практики важнее другое: какие страницы не должны конкурировать с основными посадочными в поиске. В типичном WordPress это:

• страницы вложений медиафайлов;
• архивы автора на небольших сайтах, где один автор и контент дублирует главную ленту;
• архивы по датам, если они не несут самостоятельной ценности;
• внутренний поиск вида ?s=;
• страницы пагинации, если они создают мусор в индексе;
• URL с параметрами сортировки, фильтров и трекинга;
• технические страницы плагинов, которые не должны ранжироваться.

Если у вас уже есть SEO-плагин, часть настроек может быть закрыта там. Но важно понимать логику: robots.txt управляет обходом, а noindex — индексацией. Это не одно и то же.

Диагностика: где искать проблему

Перед правками откройте Google Search Console и посмотрите отчеты по страницам, которые индексируются без пользы. Полезно также проверить сайт вручную через поиск по домену и через site:example.com. Если в выдаче видны:

• /attachment/ или страницы вложений;
• /author/ при одном авторе;
• /page/2/, /page/3/ и дальше для архивов;
• ?s=;
• URL с параметрами ?utm_, ?replytocom=, ?orderby=;

значит, сначала нужно решить, что закрывать от индексации, а что просто запретить к обходу. Если страница должна существовать для пользователя, но не должна ранжироваться, почти всегда нужен noindex, а не жесткий запрет в robots.

Как выбрать подход: robots.txt, noindex или каноникал

Ниже короткое сравнение. Оно помогает не делать типичную ошибку, когда всё подряд запрещают в robots.txt и потом удивляются, что поисковик продолжает держать URL в индексе без контента.

Пошаговое решение

1. Закройте мусорные архивы и вложения через SEO-плагин или код

Если у вас установлен Yoast SEO, Rank Math или похожий плагин, сначала проверьте их настройки архивов и медиа. Для вложений часто достаточно редиректа на файл или на родительскую запись. Если хотите сделать это кодом, можно добавить редирект вложений в functions.php дочерней темы или в небольшой mu-plugin:

<?php
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);
        } else {
            wp_safe_redirect(home_url('/'), 301);
        }
        exit;
    }
});

Это не закрывает страницу от индексации напрямую, но убирает отдельную бесполезную точку входа. Для архивов автора и дат решение зависит от структуры сайта: если авторов несколько и у каждого есть свой контент, архив автора может быть полезен. Если автор один, такой архив часто только дублирует блог.

2. Добавьте noindex для страниц поиска, архивов и пагинации, если они не нужны в выдаче

Самый безопасный путь — отдать поисковику страницу, но попросить не индексировать ее. Для этого можно добавить мета-тег robots на нужные типы страниц:

<?php
add_action('wp_head', function () {
    if (is_search() || is_author() || is_date()) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }

    if (is_paged() && (is_home() || is_archive())) {
        echo '<meta name="robots" content="noindex,follow">' . "\n";
    }
}, 1);

Здесь важна оговорка: не всем сайтам подходит одинаковая политика. На крупном медиа-проекте архивы по датам могут быть полезны. На небольшом корпоративном сайте — почти всегда лишние.

3. Настройте robots.txt только для обхода, а не как единственный способ скрыть URL

В robots.txt имеет смысл закрыть технические разделы, которые не должны расходовать обход:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /*?replytocom=
Disallow: /*?utm_
Disallow: /*?orderby=
Sitemap: https://example.com/sitemap_index.xml

Но не стоит рассчитывать, что одного Disallow достаточно для удаления уже известных поисковику страниц. Если URL уже в индексе, нужен noindex или редирект на каноническую версию.

4. Уберите лишние архивы у автора и медиа

Если сайт ведется одним автором, архив автора обычно не нужен. Его можно либо отключить в SEO-плагине, либо сделать редирект на главную или на страницу «О проекте». Для страниц вложений лучше не оставлять их как отдельные документы. Они почти никогда не дают полезного трафика и часто создают тонкий контент.

Если у вас много изображений, проверьте, не генерируются ли отдельные страницы вложений массово. Это частая причина роста количества URL в индексе без роста качества сайта.

Проверка результата после внедрения

После правок не спешите считать задачу закрытой. Нужно проверить три вещи: доступность страницы, наличие noindex и реакцию поисковика.

1. Откройте проблемный URL в браузере и убедитесь, что он отвечает корректно: редирект, 200 или 404 — в зависимости от сценария.
2. Посмотрите исходный код страницы и найдите <meta name="robots" content="noindex,follow">.
3. Проверьте заголовки ответа, если используете HTTP-мета-robots или редиректы.
4. В Search Console отправьте URL на проверку и посмотрите, как он отображается в отчете по индексации.

Если страница закрыта в robots.txt, но уже сидит в индексе, она может не исчезнуть быстро. Это нормальная ситуация. Для ускорения нужен доступ поисковика к странице, чтобы он увидел noindex или канонический URL.

Частые ошибки и как их исправить

Закрыли в robots.txt, но не поставили noindex

Это самая частая ошибка. Поисковик знает URL, но не может его переобойти, поэтому страница может оставаться в индексе как «URL без описания». Исправление: временно уберите запрет на обход, дайте боту увидеть noindex, затем снова ограничьте обход, если это действительно нужно.

Поставили noindex на важные страницы пагинации

Иногда пагинацию закрывают без разбора, а потом поисковик хуже находит старые записи. Если у вас блог с большим архивом, пагинация может быть полезна для обхода и внутренней связности. Не закрывайте ее автоматически, пока не проверите структуру сайта.

Сделали редирект всех вложений на главную

Это выглядит просто, но часто ломает смысл вложений и ухудшает пользовательский сценарий. Лучше редиректить вложение на родительскую запись, а если родителя нет — на главную как запасной вариант.

Запретили параметры URL, которые нужны фильтрам или сортировке

Если на сайте есть рабочие фильтры, не рубите все параметры подряд. Сначала посмотрите, какие URL реально создают мусор. Параметры аналитики и сортировки можно закрыть, а параметры, влияющие на контент страницы, иногда лучше оставить и обработать canonical.

Практические советы по безопасности и производительности

Чем меньше лишних страниц генерирует WordPress, тем меньше нагрузка на обход и тем проще поддерживать чистую структуру. Но не стоит превращать оптимизацию в набор жестких запретов. Безопаснее двигаться так:

• сначала определить тип страницы;
• затем решить: редирект, noindex или canonical;
• после этого уже трогать robots.txt;
• не закрывать системные файлы и рабочие AJAX-эндпоинты без проверки;
• не вносить правки прямо в родительскую тему, если есть риск обновления.

Если нужен более системный контроль дублей и технической чистки, удобно смотреть в сторону плагинов, которые умеют управлять архивами, мета-тегами и служебными страницами без ручного кода. Например, Clearfy Pro закрывает типовые SEO-дубли и помогает убрать лишние элементы, которые часто разрастаются на живом сайте. Подробности можно посмотреть здесь: Clearfy Pro.

Мини-чек-лист перед публикацией изменений

• Проверить, какие URL реально попадают в индекс.
• Определить, что закрываем: обход, индексацию или оба уровня.
• Не путать robots.txt и noindex.
• Сделать редирект для вложений и мусорных архивов.
• Проверить исходный код и ответ сервера.
• Отправить проблемные URL на повторную проверку в Search Console.

Если после внедрения в индексе все еще остаются старые адреса, это не всегда ошибка настройки. Иногда поисковику просто нужно время, чтобы переобойти страницы и обновить статус. Важнее, чтобы новая логика была последовательной: одна каноническая версия, понятные редиректы и отсутствие лишних технических дублей.