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

Ситуация типичная: запись уже обновили, URL оставили тот же, а в поиске продолжают всплывать старые сниппеты, служебные версии или страницы, которые вообще не должны конкурировать с основной публикацией. Если просто поставить noindex на всё подряд, можно случайно убрать из индекса и нужную страницу. Поэтому здесь важен не «запретить всё», а аккуратно отделить старые версии от канонической записи.

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

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

Сначала стоит понять, что именно попало в индекс. В WordPress под «старыми версиями» обычно скрываются разные сущности:

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

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

Что проверить в первую очередь

• Откройте проблемный URL и посмотрите HTTP-статус: должен быть 200 только у основной страницы.
• Проверьте, нет ли у старого адреса редиректа на актуальный URL.
• Посмотрите исходный код страницы: есть ли rel="canonical" и куда он указывает.
• Сравните заголовки ответа для основной страницы и служебных URL.
• Проверьте, не генерирует ли тема или SEO-плагин отдельные индексируемые страницы для параметров.

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

Не все старые версии нужно решать одинаково. Для WordPress безопаснее разделить сценарии по типу URL.

Если речь именно о ревизиях, их не нужно редиректить. Это внутренние записи WordPress, и задача здесь — не дать им попасть в индекс, а не ломать механизм восстановления.

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

Самый надёжный вариант — оставить основную запись индексируемой, а для ревизий и служебных URL добавить явный noindex. Для этого можно использовать фильтр wp_robots, который WordPress применяет к robots-мета.

add_filter('wp_robots', function (array $robots) {
    if (is_singular() && get_post_type() === 'post') {
        $post_id = get_queried_object_id();

        // Если это не основная запись, а служебная версия или предпросмотр,
        // можно добавить noindex точечно по условиям.
        if (is_preview() || get_query_var('preview_id')) {
            $robots['noindex'] = true;
            $robots['nofollow'] = true;
        }
    }

    return $robots;
});

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

Если задача — убрать из индекса именно ревизии как тип записей, можно исключить их из sitemap и не давать им публичный доступ. В WordPress ревизии не должны быть самостоятельным контентом для поиска.

add_filter('wp_sitemaps_post_types', function (array $post_types) {
    unset($post_types['revision']);
    return $post_types;
});

Этот фильтр полезен, если у вас кастомная логика или плагин всё же пытается добавить лишнее в карту сайта. Но если ревизии уже не попадают в sitemap, это не отменяет необходимость проверить каноникал и редиректы у основной записи.

Если старый адрес уже в поиске: что делать с каноникалом и редиректом

Когда в индексе сидит не ревизия, а старая версия статьи по прежнему URL, noindex часто недостаточно. Поисковику нужно явно показать, какой адрес основной. Для этого:

1. старый URL должен отдавать 301 на новый;
2. на новой странице должен быть корректный canonical;
3. внутренние ссылки должны вести только на актуальный адрес;
4. в sitemap должен быть только новый URL.

Если редирект уже есть, но старый адрес всё равно индексируется, проверьте цепочки редиректов и конечный статус. Иногда старый URL сначала ведёт на промежуточный адрес, а потом уже на новый. Для поисковика это хуже, чем прямой 301.

Пример точечного редиректа в functions.php

add_action('template_redirect', function () {
    if (!is_singular('post')) {
        return;
    }

    $old_slugs = array('staryj-slug-1', 'staryj-slug-2');
    $current_slug = get_post_field('post_name', get_queried_object_id());

    if (in_array($current_slug, $old_slugs, true)) {
        wp_redirect(get_permalink(get_queried_object_id()), 301);
        exit;
    }
});

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

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

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

• Основная запись открывается с кодом 200.
• Старый URL отдаёт 301 на актуальный адрес.
• Ревизии и предпросмотр не доступны как публичные страницы.
• В исходном коде основной страницы нет лишнего noindex.
• В robots-мета у служебных URL есть noindex, если они всё же доступны.
• В sitemap присутствует только канонический URL записи.

Проверить это можно через:

• инструмент проверки URL в Google Search Console;
• curl -I https://example.com/staryj-url/ для статуса и редиректа;
• просмотр исходного кода страницы на наличие canonical и robots;
• логи сервера, если нужно понять, как часто старый адрес ещё запрашивают.

Быстрая проверка через curl

curl -I https://example.com/staryj-url/
curl -I https://example.com/aktualnyj-url/

В ответе старого адреса вы должны увидеть 301 Moved Permanently и заголовок Location с новым URL. Если вместо этого приходит 200, поисковик может продолжать считать старую страницу самостоятельной.

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

Ставят noindex на основную запись

Это самая неприятная ошибка. Обычно она возникает, когда правило написано слишком широко: например, для всех одиночных записей или для всего типа post. В итоге из индекса исчезает не старая версия, а нужная статья. Исправление простое: ограничить условие только служебными URL, предпросмотром или конкретными шаблонами.

Оставляют старый URL с кодом 200

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

Не обновляют внутренние ссылки

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

Путают ревизии с дублями контента

Ревизии нужны редактору, но не поиску. Если они вообще доступны по отдельным адресам, это уже проблема маршрутизации или плагина. В нормальной конфигурации ревизии не должны конкурировать с основной страницей.

Что можно сделать для профилактики

Чтобы не разбирать такие случаи вручную после каждой правки, полезно сразу держать под контролем несколько вещей:

• не плодить старые URL без необходимости;
• после переноса всегда ставить 301 на новый адрес;
• не публиковать служебные страницы с открытым доступом;
• проверять canonical после обновления шаблонов темы;
• не смешивать SEO-логику темы и плагинов без теста на staging;
• регулярно смотреть отчёты Search Console по исключённым страницам и дублям.

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

Главная идея простая: старую версию нужно либо убрать с публичного URL через редирект, либо явно пометить как неиндексируемую, если она нужна только внутри WordPress. Всё остальное — компромисс, который обычно приводит к затяжным дублям в поиске.