Как запретить индексацию старых версий страниц в WordPress через 410 или 301

Когда в WordPress меняют структуру материалов, часть старых URL остаётся висеть в индексе: архивы авторов, старые слаги, тестовые страницы, дубли после редизайна, устаревшие посадочные. Если просто удалить страницу и надеяться, что поисковик сам всё поймёт, обычно получаются «мягкие 404», цепочки редиректов и лишние запросы к несуществующим адресам.

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

Когда нужен 301, а когда 410

Сначала стоит разделить сценарии. Если старый URL переехал на новый адрес, нужен постоянный редирект 301. Если страница удалена окончательно и не должна возвращаться, уместнее отдать 410 Gone. Для поисковиков это разные сигналы: в первом случае контент переехал, во втором — адрес можно убрать из обхода и индекса.

Диагностика: что именно мешает убрать старый URL из индекса

Перед правками проверьте, как сейчас ведёт себя адрес. Часто проблема не в самом WordPress, а в том, что старый URL всё ещё где-то ссылается внутри сайта, в карте сайта, в хлебных крошках или в кэше.

• Откройте старый URL в браузере и посмотрите код ответа через DevTools или curl -I https://example.com/staryy-url/.
• Проверьте, не отдает ли страница 200 OK вместо редиректа или ошибки.
• Посмотрите внутренние ссылки: меню, блоки, похожие записи, ручные вставки в контенте.
• Проверьте XML-карту сайта и архивы, если старый адрес туда попадает.
• Убедитесь, что на уровне сервера нет конфликтующего правила в .htaccess или конфигурации nginx.

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

Пошаговое решение через functions.php или мини-плагин

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

Вариант с 410 Gone для списка старых URL

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

    $gone_paths = array(
        '/staryy-razdel/',
        '/testovaya-stranica/',
        '/old-landing/',
    );

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

    if (in_array($request_uri, $gone_paths, true)) {
        status_header(410);
        nocache_headers();
        wp_die('Страница удалена', 'Gone', array('response' => 410));
    }
});

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

Вариант с 301 на новую страницу

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

    $redirects = array(
        '/staryy-url/' => '/novyy-url/',
        '/uslugi-old/'  => '/uslugi/',
    );

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

    if (isset($redirects[$request_uri])) {
        wp_redirect(home_url($redirects[$request_uri]), 301);
        exit;
    }
});

Здесь важно не делать цепочки вида старый URL → промежуточный URL → новый URL. Один редирект лучше двух, и для пользователей, и для обхода поисковыми роботами.

Если удобнее через сервер: .htaccess или nginx

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

Пример для Apache

Redirect gone /staryy-razdel/
Redirect gone /testovaya-stranica/
Redirect 301 /staryy-url/ https://example.com/novyy-url/

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

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

После внедрения нужно проверить не только браузер, но и фактический HTTP-ответ. Иначе можно получить красивую страницу ошибки, которая всё равно отдаёт 200 OK.

• Проверьте заголовки: curl -I https://example.com/staryy-url/.
• Убедитесь, что для удалённого адреса приходит 410 Gone, а для перенесённого — 301 Moved Permanently.
• Откройте страницу в режиме инкогнито и без кэша.
• Посмотрите, не осталось ли ссылки на старый URL в меню, блоках, шаблонах и контенте.
• Проверьте карту сайта: удалённый адрес не должен там оставаться.

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

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

Страница удалена, но отдаёт 200

Обычно это значит, что шаблон подменяет контент на сообщение «ничего не найдено», но HTTP-код не меняется. Для поисковика это всё ещё валидная страница. Исправление простое: отдавать 410 или 404 через status_header() и не выводить полноценный контент.

Редирект ведёт на нерелевантную страницу

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

Старый URL всё ещё в карте сайта

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

Есть цепочка из нескольких редиректов

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

Что делать с внутренними ссылками и кэшем

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

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

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

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

• Определить, есть ли у старого URL новая замена.
• Выбрать 301 или 410 по сценарию.
• Проверить код ответа через curl -I.
• Убрать внутренние ссылки на старый адрес.
• Очистить кэш сайта, плагина и CDN.
• Проверить карту сайта и шаблоны архивов.
• Убедиться, что редирект не создаёт цепочку.

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