Как закрыть от индексации старые версии страниц и записей в WordPress

Старые версии контента в WordPress часто остаются в индексе не потому, что сайт «плохо настроен», а потому что у страницы менялся URL, редактор создавал черновики и ревизии, а потом кто-то добавил новый шаблон или дублирующий архив. В результате поисковик видит несколько адресов с почти одинаковым содержимым и не всегда выбирает нужный.

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

Когда проблема действительно есть

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

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

Что должно насторожить

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

Что закрывать, а что редиректить

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

Пошаговое решение через код

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

<?php
add_action('template_redirect', function () {
    if (is_admin() || wp_doing_ajax()) {
        return;
    }

    $old_paths = array(
        '/2019/05/old-article/',
        '/blog/old-version-of-post/',
    );

    $request_uri = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);
    $request_uri = trailingslashit($request_uri);

    foreach ($old_paths as $old_path) {
        if ($request_uri === trailingslashit($old_path)) {
            wp_redirect(home_url('/new-article/'), 301);
            exit;
        }
    }
});

add_filter('wp_robots', function ($robots) {
    if (is_singular('post') && get_post_meta(get_queried_object_id(), '_noindex_old_version', true)) {
        $robots['noindex'] = true;
        $robots['follow'] = true;
    }

    return $robots;
});

add_action('wp_head', function () {
    if (is_singular('post')) {
        $canonical = get_post_meta(get_queried_object_id(), '_canonical_override', true);
        if ($canonical) {
            echo '<link rel="canonical" href="' . esc_url($canonical) . '" />' . "\n";
        }
    }
}, 1);

Здесь логика такая: старый URL уводим 301-редиректом, а для отдельных записей, где редирект нежелателен, можно включить noindex через метаполе. Это удобнее, чем пытаться закрыть всё через robots.txt, потому что robots не убирает уже проиндексированные страницы из выдачи.

Если старые версии создаёт редактор или плагин

Иногда проблема не в URL, а в том, что плагин генерирует отдельные страницы для вложений, слайдов, PDF или AMP-версий. Тогда лучше отключить сам источник дублей. Например, для вложений можно делать редирект на родительскую запись, если отдельные attachment pages не нужны.

<?php
add_action('template_redirect', function () {
    if (is_attachment()) {
        $parent = get_post_field('post_parent', get_queried_object_id());
        if ($parent) {
            wp_redirect(get_permalink($parent), 301);
            exit;
        }

        wp_redirect(home_url('/'), 301);
        exit;
    }
});

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

Как проверить, что решение сработало

После внедрения не ограничивайтесь визуальной проверкой в браузере. Нужно убедиться, что старый адрес отдаёт нужный код ответа, а новый URL стал основным.

• проверьте старый URL через curl -I https://example.com/old-url/ и убедитесь, что есть 301 и корректный Location;
• откройте исходный код страницы и посмотрите, что canonical указывает на нужный адрес;
• проверьте мета-роботов: на страницах, которые нужно скрыть, должен быть noindex;
• в Search Console отправьте проверку URL и посмотрите, как Google видит страницу после переобхода;
• убедитесь, что нет цепочки из нескольких редиректов подряд.

Если страница уже была в индексе, удаление может занять время. Это нормально: поисковик должен переобойти URL и увидеть новый сигнал. Важно не создавать конфликтов, когда один механизм говорит noindex, а другой одновременно отдаёт 200 без canonical и ещё третий ведёт на старую копию.

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

Закрывают старый URL только в robots.txt

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

Ставят noindex на нужную страницу вместо дубля

Иногда в шаблоне ошибочно закрывают основную запись, а не техническую копию. В итоге из индекса пропадает правильный адрес, а дубль остаётся. Перед правкой всегда проверяйте, по какому условию срабатывает код: is_singular(), is_attachment(), конкретный ID записи или метаполе.

Делают редирект на главную без логики

Редирект на главную — плохая замена удалённой странице. Пользователь и поисковик должны получать максимально близкий по смыслу адрес. Если старый материал переехал, ведите на новый материал. Если аналогов нет, лучше вернуть 410 или 404, а не маскировать проблему.

Оставляют цепочки редиректов

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

Безопасность и производительность

Код для редиректов и мета-тегов лучше держать не в functions.php активной темы, а в небольшом mu-plugin или в отдельном плагине сайта. Так он не пропадёт при смене темы и не потеряется при обновлении.

Если на сайте много правил, не делайте десятки тяжёлых проверок на каждом запросе. Список старых путей лучше хранить компактно, а для крупных проектов — вынести в таблицу или использовать настройки плагина, где это удобно редактировать без правки кода. Если нужен более широкий набор инструментов для чистки дублей и технической оптимизации, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy.

Практический чек-лист перед публикацией

• определён список старых URL, которые нужно убрать из индекса;
• для удалённых страниц настроен 301-редирект на релевантный адрес;
• для технических дублей добавлен noindex или canonical;
• вложенные страницы и attachment pages проверены отдельно;
• нет конфликтов между плагином SEO, темой и кастомным кодом;
• старые URL отвечают ожидаемым кодом, без цепочек и петлей;
• новый адрес указан в sitemap и доступен для обхода.

Если после правок старые страницы всё ещё появляются в выдаче, не спешите менять несколько настроек сразу. Сначала проверьте ответ сервера и исходный код страницы, потом уже смотрите Search Console. В таких задачах почти всегда выигрывает не «ещё один плагин», а аккуратная схема: редирект там, где нужен новый адрес, noindex там, где страница остаётся технически полезной, и canonical там, где есть допустимые копии.