В WordPress технические страницы часто попадают в индекс не потому, что сайт «плохо сделан», а потому что движок по умолчанию создаёт много URL, которые не несут ценности для поиска: страницы поиска, архивы по датам, вложения, служебные страницы пагинации, результаты фильтров и т. п. Если их не контролировать, в индексе появляется мусор, а краулинговый бюджет уходит не туда.
Задача здесь не в том, чтобы закрыть всё подряд. Нужен точечный подход: что-то лучше отдать с noindex,follow, что-то убрать из sitemap, а что-то оставить доступным только для пользователей и ботов не пускать вовсе. Ниже — рабочая схема для типового WordPress-сайта без выдуманных плагинов и магии.
Какие страницы обычно нужно проверить в первую очередь
Перед правками полезно понять, что именно у вас индексируется. На практике чаще всего всплывают такие URL:
- страницы внутреннего поиска вида
?s=; - архивы по датам и авторам, если они не нужны для поиска;
- страницы вложений медиафайлов;
- служебные страницы пагинации с пустым или слабым содержимым;
- страницы тегов и рубрик, если они дублируют основной контент;
- параметры сортировки и фильтров, если они создают десятки дублей.
Если сайт уже в индексе, сначала посмотрите отчёты в Google Search Console и список URL, которые реально попали в поиск. Не стоит закрывать всё наугад: иногда архив рубрик даёт стабильный трафик, а страница автора — нормальную точку входа.
Диагностика: где именно возникает проблема
Начните с простых проверок. Они быстро показывают, что нужно исправлять в первую очередь.
Проверка индексации через поиск и GSC
В поиске можно посмотреть, какие служебные URL уже видны. Для этого используйте запросы вида site:example.com inurl:?s= или site:example.com inurl:/attachment/. В Search Console откройте отчёт по страницам и обратите внимание на:
- URL с низким или нулевым трафиком;
- страницы с дублирующимся title и description;
- страницы, которые не должны были попасть в индекс, но уже там есть.
Проверка исходного кода
Откройте проблемную страницу и посмотрите, есть ли в <head> мета-тег robots и корректный canonical. Если canonical указывает на саму служебную страницу, а не на основную, поисковик может продолжать её учитывать.
Также проверьте sitemap.xml: если туда попадают страницы поиска, вложения или пустые архивы, это лишний сигнал для роботов.
Что лучше закрывать через noindex, а что — через robots.txt
Это ключевой момент. robots.txt не убирает URL из индекса, если он уже известен поисковику. Он только ограничивает обход. Для удаления из поиска чаще нужен noindex на самой странице.
| Подход | Когда использовать | Плюс | Минус |
|---|---|---|---|
noindex,follow | Страницы, которые не должны ранжироваться, но по ним можно ходить | Убирает страницу из индекса | Нужно, чтобы бот мог увидеть мета-тег |
robots.txt | Служебные разделы, которые не нужно сканировать | Снижает лишний обход | Не гарантирует удаление из индекса |
| canonical | Похожие страницы и дубли | Помогает склеить сигналы | Не подходит для явного запрета индексации |
Если страница уже в индексе, одной записи в robots.txt обычно недостаточно. В таких случаях сначала ставят noindex, а потом при необходимости ограничивают обход через robots.txt.
Пошаговое решение через код темы или мини-плагин
Ниже пример, который можно добавить в functions.php дочерней темы или в свой небольшой плагин. Он закрывает от индексации поиск, архивы авторов, архивы по датам и вложения. Перед внедрением проверьте, нужны ли вам эти типы страниц для SEO.
<?php
add_action('wp_head', function () {
if (is_search() || is_author() || is_date() || is_attachment()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
}, 1);
add_filter('wp_robots', function (array $robots) {
if (is_search() || is_author() || is_date() || is_attachment()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});
add_filter('wp_sitemaps_posts_query_args', function (array $args, string $post_type) {
if ($post_type === 'attachment') {
$args['post__not_in'] = isset($args['post__not_in']) ? (array) $args['post__not_in'] : [];
}
return $args;
}, 10, 2);
Здесь важна не только метка noindex, но и логика sitemap. Если вложения или служебные записи продолжают попадать в карту сайта, вы сами подсказываете поисковику, что они важны.
Если нужно закрыть только часть архивов
Иногда архивы авторов полезны, а архивы по датам — нет. Тогда не используйте грубую схему «закрыть всё». Лучше разделить правила:
<?php
add_filter('wp_robots', function (array $robots) {
if (is_date()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
if (is_search()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});
Такой вариант безопаснее для сайтов, где авторские архивы реально нужны как посадочные страницы.
Как ограничить индексацию через robots.txt
Для служебных разделов, которые не должны тратить краулинг, можно добавить правила в robots.txt. Это не замена noindex, а дополнительный слой.
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /search/
Disallow: /attachment/
Но здесь есть нюанс: если у вас поиск работает по другому URL-формату, правило нужно подстроить под реальный путь. И не закрывайте в robots.txt то, что хотите удалить из индекса, пока не убедились, что там уже стоит noindex.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковик видит именно то, что вы задумали.
- Откройте проблемный URL и проверьте исходный код: должен быть
noindex. - В Search Console используйте проверку URL и посмотрите, доступна ли страница для сканирования.
- Проверьте sitemap: служебных URL там быть не должно.
- Сравните количество страниц в индексе по типам URL через поиск
site:до и после.
Если страница уже была в индексе, удаление может занять время. В Search Console можно отправить запрос на переобход, но это не мгновенная операция. Главное — не менять правила туда-сюда каждые пару дней, иначе вы не поймёте, что именно сработало.
Частые ошибки и как их исправить
Закрыли страницу в robots.txt, но она осталась в индексе
Это нормальная ситуация. Если бот не может зайти на страницу, он может не увидеть запрет на индексацию. Решение: сначала вернуть доступ, поставить noindex, дождаться переобхода, и только потом при необходимости ограничивать сканирование.
Поставили canonical на главную без логики
Canonical должен указывать на наиболее релевантную версию, а не просто на домашнюю страницу. Если у страницы поиска canonical ведёт на главную, это выглядит как попытка «спрятать» URL, а не решить проблему.
Сломали полезные архивы
Иногда теги и рубрики дают трафик, а после массового noindex они перестают работать как посадочные страницы. Перед закрытием проверьте, есть ли у архива входящий трафик, уникальный текст, нормальная структура и внутренние ссылки.
Оставили служебные страницы в sitemap
Если URL есть в карте сайта, это сигнал для поисковика, что страница важна. Уберите из sitemap всё, что не должно ранжироваться: вложения, поиск, пустые архивы, тестовые страницы.
Практические советы по безопасности и производительности
Если на сайте много дублей, проблема не только в SEO. Лишние страницы создают нагрузку на обход, усложняют аналитику и мешают поддержке. Полезно:
- не плодить архивы без необходимости;
- отключать индексацию вложений, если они не используются как отдельные посадочные страницы;
- не генерировать десятки фильтров и параметров без каноникализации;
- проверять, не создаёт ли тема отдельные шаблоны для служебных URL;
- следить, чтобы плагины SEO не конфликтовали с ручными правилами в коде.
Если нужен более системный контроль дублей и служебных страниц, иногда проще вынести это в SEO-плагин с понятными настройками, чем поддерживать разрозненные правки в теме. Но даже в этом случае полезно понимать, что именно делает плагин: noindex, canonical или только скрытие из карты сайта — это разные вещи.
Для проверки после внедрения удобно пройтись по списку:
- служебный URL отдаёт
noindexв<head>; - страница не попадает в sitemap;
- canonical указывает на правильную версию;
- в Search Console нет роста мусорных URL;
- полезные архивы не потеряли трафик.
Если всё это сходится, значит, индексация технических страниц в WordPress у вас под контролем, а не «как-нибудь сама решится».