Как исключить старые страницы из индексации в WordPress без потери нужного трафика

Старые страницы в WordPress обычно не мешают до тех пор, пока не начинают конкурировать с актуальными материалами, тянуть на себя краулинговый бюджет и плодить мусор в поиске. Типичный сценарий: статья обновилась, URL сменился, а в индексе остались и старая версия, и архив, и страница с параметрами. Если просто закрыть всё подряд в robots.txt, можно потерять и нужные страницы, и нормальную переиндексацию. Рабочий подход здесь другой: сначала понять, что именно должно исчезнуть из индекса, потом выбрать способ — noindex, редирект, canonical или удаление с кодом ответа 410.

Когда старую страницу нужно не закрывать, а удалять

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

Диагностика проблемы

Перед правками проверьте, что именно индексируется. В Google Search Console и Яндекс.Вебмастере смотрите:

• какие URL попали в индекс;
• есть ли дубли с параметрами, тегами, архивами автора и дат;
• какой статус ответа у старых страниц;
• не ведут ли внутренние ссылки на устаревшие адреса;
• не конфликтуют ли canonical и редиректы.

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

Что выбрать: noindex, 301, canonical или 410

У каждого способа своя задача. Ошибка многих сайтов в том, что все проблемы пытаются решить одним инструментом. Это почти всегда приводит к путанице: URL остаётся доступным, но не индексируется; редирект ведёт на нерелевантную страницу; canonical указывает на несуществующий адрес.

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

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

Шаг 1. Уберите внутренние ссылки на старые URL

Если старая страница продолжает встречаться в меню, блоках, хлебных крошках или в тексте, поисковик будет возвращаться к ней снова и снова. Сначала замените ссылки в контенте и шаблонах. Для массовой замены удобно использовать поиск по базе через WP-CLI или безопасный SQL-миграционный инструмент, но только после бэкапа.

wp search-replace 'https://example.com/old-page/' 'https://example.com/new-page/' --skip-columns=guid

Команда выше не удаляет URL из индекса сама по себе, но помогает убрать источник повторного обхода. Параметр --skip-columns=guid нужен, чтобы не трогать GUID записей.

Шаг 2. Настройте 301 для реально переехавших страниц

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

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^old-page/?$ /new-page/ [R=301,L]
RewriteRule ^old-category/(.*)$ /category/$1 [R=301,L]
</IfModule>

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

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

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

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

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

Шаг 4. Для окончательно удалённых URL отдайте 410

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

add_action('template_redirect', function () {
    if (is_page('old-landing')) {
        status_header(410);
        nocache_headers();
        echo 'Страница удалена';
        exit;
    }
});

Используйте такой подход аккуратно: если URL уже имеет внешние ссылки или трафик, сначала проверьте, нет ли подходящей замены для 301.

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

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

• Откройте старый URL через curl -I и убедитесь, что код ответа соответствует задаче: 301, 410 или 200.
• Проверьте исходный код страницы на наличие noindex и корректного canonical.
• В Search Console отправьте URL на повторную проверку после редиректа или удаления.
• Посмотрите, не осталось ли старых адресов в sitemap.xml.
• Проверьте логи сервера: бот должен приходить на старый URL и получать нужный ответ.

curl -I https://example.com/old-page/

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

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

Самые неприятные проблемы обычно возникают не из-за самого noindex или редиректа, а из-за их неправильного сочетания.

1. Закрыли URL в robots.txt и ждут удаления из индекса

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

2. Ставят canonical на несуществующую страницу

Canonical должен указывать на доступный и индексируемый URL. Если целевая страница удалена или закрыта, сигнал теряет смысл. В такой ситуации лучше сделать 301 на реальную страницу или оставить URL удалённым с 410.

3. Делают 301 на главную

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

4. Дублируют управление индексом в плагине и в коде

Если SEO-плагин уже добавляет noindex, не добавляйте второй мета-тег вручную. Аналогично с canonical и sitemap: сначала проверьте, что именно генерирует текущая конфигурация, потом вносите точечные изменения.

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

Любые массовые изменения URL лучше делать после резервной копии базы и файлов. Особенно если вы используете поиск и замену в базе или правите правила сервера. Ошибка в регулярном выражении или в .htaccess может положить весь сайт или создать бесконечный редирект.

• Сначала тестируйте на staging-копии.
• Не закрывайте от индексации страницы, которые должны приносить трафик.
• Не используйте плагины редиректов для тысяч правил, если это можно решить на уровне сервера.
• Проверяйте sitemap после удаления URL: старые адреса не должны оставаться в карте сайта.
• Если у вас много дублей и служебных страниц, имеет смысл посмотреть в сторону Clearfy Pro как инструмента для чистки и управления техническими настройками, но только если он реально закрывает вашу задачу и не дублирует уже установленный SEO-стек: https://wpshop.ru/plugins/clearfy?utm_source=wpunit.ru&utm_medium=article&utm_campaign=isklyuchit-starye-stranitsy-iz-indeksatsii-v-wordpress

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

• Проверен список старых URL, которые нужно убрать или перенаправить.
• Для переехавших страниц настроен 301 на релевантный адрес.
• Для служебных страниц добавлен noindex, если они должны быть доступны.
• Для окончательно удалённых URL возвращается 410.
• Внутренние ссылки и sitemap обновлены.
• Нет конфликтов между плагином, темой и ручным кодом.
• Коды ответа проверены через curl -I или DevTools.

Если после правок старые страницы всё ещё появляются в поиске, не спешите менять всё подряд. Обычно проблема в одном из трёх мест: остались внутренние ссылки, редирект ведёт не туда или поисковик ещё не переобходил URL. В таком случае помогает повторная проверка в Search Console и контроль серверных логов, а не новые хаотичные настройки.