На WordPress часто индексируются страницы, которые не должны попадать в поиск: архивы авторов на однопользовательском сайте, страницы вложений, результаты внутреннего поиска, служебные таксономии, пагинация с дублями и отдельные технические URL. Проблема обычно не в одном теге noindex, а в том, что разные типы страниц требуют разного подхода. Если закрыть всё подряд, можно случайно убрать из индекса полезные разделы. Если не закрыть ничего, поисковик начнёт тратить краулинговый бюджет на мусор.
Какие страницы WordPress обычно нужно закрывать
Сначала стоит не править код, а понять, что именно у вас создаёт лишние URL. На типовом сайте это:
- страницы результатов поиска вида
/?s=...; - страницы вложений медиафайлов, если они пустые или почти пустые;
- архивы автора на сайте с одним автором;
- служебные таксономии, которые дублируют основной контент;
- страницы пагинации, если они не несут самостоятельной ценности и создают дубли мета-данных;
- служебные страницы плагинов, которые не должны индексироваться.
Диагностика проблемы до правок
Проверьте, что именно уже попало в индекс. Для этого достаточно трёх источников: Google Search Console, поиск по сайту через оператор site: и просмотр исходного кода проблемной страницы. В исходнике ищите <meta name="robots" content="noindex,follow"> или его отсутствие. Если страница уже в индексе, а вы только добавили noindex, удаление может занять время — это нормально.
Полезно также посмотреть, не закрыта ли страница в robots.txt. Это важный момент: если URL заблокирован в robots, поисковик может не увидеть мета-тег noindex на самой странице. Для удаления из индекса обычно лучше использовать именно noindex, а не запрет в robots.txt.
Что выбрать: robots.txt, meta robots или каноникал
У каждого инструмента своя задача. Ошибка многих сайтов — использовать только один способ для всех случаев. Ниже короткое сравнение.
| Способ | Когда подходит | Ограничение |
|---|---|---|
noindex в meta robots |
Страница доступна, но не должна быть в индексе | Нужно, чтобы поисковик мог её обойти и увидеть тег |
robots.txt |
Нужно ограничить обход служебных URL | Не гарантирует удаление уже проиндексированных страниц |
rel="canonical" |
Есть дубль, который должен указывать на основную версию | Не заменяет noindex для мусорных страниц |
На практике для WordPress чаще всего нужен комбинированный подход: noindex,follow для страниц, которые не должны ранжироваться, и canonical для дублей, если у них есть явный основной URL.
Пошаговое решение через код темы или мини-плагин
Если задача точечная и вы не хотите ставить тяжёлый SEO-плагин, можно добавить логику в functions.php дочерней темы или в отдельный mu-plugin. Второй вариант надёжнее: обновление темы не затрёт правки.
1. Закрываем результаты поиска и страницы вложений
Для большинства сайтов этого уже достаточно, чтобы убрать самые шумные URL из индекса.
<?php
add_action('wp_head', function () {
if (is_search() || is_attachment()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
Этот вариант работает только для фронтенда. Если у вас кэш на уровне сервера или CDN, после правки нужно очистить кэш, иначе поисковик и вы можете видеть старую версию страницы.
2. Убираем архив автора на сайте с одним автором
Если на сайте один автор, архив автора обычно дублирует главную ленту или страницу блога. В таком случае его лучше закрыть от индексации и, при необходимости, отключить вывод ссылки на автора в шаблоне.
<?php
add_action('wp_head', function () {
if (is_author() && count_users()['total_users'] === 1) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
Здесь есть нюанс: count_users() может быть лишним вызовом на каждом хите. Если сайт большой, лучше один раз определить условие и закешировать его в опции или использовать более простой признак, если вы точно знаете, что автор один.
3. Настраиваем robots.txt для служебных путей
Если у вас есть очевидно служебные разделы, которые не должны обходиться часто, их можно ограничить в robots.txt. Но не используйте этот способ для уже проиндексированных страниц, если цель — именно удалить их из выдачи.
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /?s=
Disallow: /search/
Для WordPress важно не закрыть случайно CSS, JS и изображения, которые нужны для рендеринга. Не добавляйте туда лишние каталоги без проверки.
Если используете SEO-плагин
Когда на сайте уже стоит SEO-плагин, часть задач проще решить в его настройках, чем кодом. Но и тут нужно понимать, что именно он делает: иногда плагин ставит noindex, иногда только меняет canonical, а иногда вообще скрывает опцию за шаблонами.
Если нужен более широкий набор инструментов для чистки дублей и технической оптимизации, уместно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, какие URL вы закрываете и почему.
Проверка результата после внедрения
После настройки не ограничивайтесь визуальной проверкой страницы в браузере. Нужно убедиться, что поисковик видит именно то, что вы задумали.
- Откройте исходный код страницы и проверьте наличие
noindex,follow. - Проверьте HTTP-заголовки, если вы используете серверные правила или плагин, который добавляет их на уровне ответа.
- В Search Console отправьте URL на повторную проверку, если страница уже была в индексе.
- Сделайте поиск
site:example.comпо типу URL и посмотрите, исчезают ли служебные страницы постепенно. - Убедитесь, что закрытые страницы не получают внутренние ссылки из меню, хлебных крошек и блоков похожих записей без необходимости.
Если страница всё ещё в индексе, это не всегда ошибка настройки. Поисковик может держать старую версию до следующего обхода. Важно, чтобы новый код был доступен без блокировки в robots.txt и без кэшированной старой версии.
Частые ошибки и как их исправить
Закрыли URL в robots.txt и ждёте удаления из индекса
Это самая частая ошибка. Если страница уже известна поисковику, одного запрета в robots может быть недостаточно. Исправление: уберите блокировку, дайте странице отдать noindex, затем дождитесь переобхода.
Ставите noindex на все архивы подряд
Так можно случайно убрать полезные страницы рубрик или тегов, которые реально приводят трафик. Исправление: сначала посмотрите, какие архивы уже ранжируются и дают переходы, и только потом закрывайте лишнее.
Добавили код в родительскую тему
После обновления тема перезапишется, и правило исчезнет. Исправление: используйте дочернюю тему или mu-plugin.
Не очистили кэш
Если стоит page cache, объектный кэш или CDN, поисковик может ещё долго получать старую версию страницы. Исправление: очистите все уровни кэша и проверьте HTML не только в админке, но и в публичном ответе сервера.
Закрыли страницу, но оставили на неё внутренние ссылки
Это не критично, если страница нужна пользователю, но не нужна в индексе. Однако если URL служебный и бесполезный, лучше убрать ссылки на него из шаблонов и виджетов, чтобы не тратить обход.
Безопасность и производительность
Любая логика, которая выводит мета-теги на каждом запросе, должна быть простой. Не делайте тяжёлые запросы к базе внутри wp_head. Если условие можно вычислить один раз, лучше сохранить его в опции или использовать уже готовые условные теги WordPress.
Для безопасности не редактируйте код напрямую в продакшене через встроенный редактор темы. Один лишний символ в functions.php может положить сайт. Надёжнее работать через Git, SFTP или хотя бы staging-копию.
Если на сайте много технических дублей, иногда выгоднее не точечно править каждую страницу, а сначала провести чистку: убрать лишние архивы, отключить ненужные таксономии, настроить canonical и только потом закрывать остатки. В таких сценариях технический плагин или аккуратный mu-plugin обычно надёжнее разрозненных правок в шаблонах.
Когда код лучше, чем плагин, а когда наоборот
Если задача узкая и понятная, код даёт больше контроля. Если на сайте много типовых дублей и вы не хотите поддерживать собственные условия, плагин экономит время. Но плагин не отменяет проверки: он может закрыть не те страницы или конфликтовать с темой.
Практическое правило простое: если вы можете описать условие в двух строках на is_search(), is_attachment() или is_author(), код обычно оправдан. Если нужно управлять десятками шаблонов, лучше брать инструмент с интерфейсом и понятной логикой, а не плодить хрупкие костыли.
Главное — не путать индексацию с обходом. Для WordPress это разные задачи, и корректное решение почти всегда начинается с диагностики конкретных URL, а не с универсального запрета на весь сайт.