Ситуация типичная: в поиске всплывают страницы тегов без контента, архивы автора, страницы пагинации, служебные URL плагинов или дубли с параметрами. Вручную удалить их из индекса нельзя — нужно правильно настроить сигналы для поисковиков: noindex, canonical и, где уместно, robots.txt.
Ниже — рабочий сценарий именно для WordPress: как понять, что закрывать, чем отличается запрет индексации от запрета обхода и как проверить, что поисковый робот увидит нужную версию страницы.
Когда проблема действительно в индексации, а не в контенте
Перед правками стоит убедиться, что у вас не «плохой контент», а именно технический дубль или служебная страница. Если в выдаче есть:
- архивы автора на сайте с одним редактором;
- страницы тегов, которые не несут самостоятельной ценности;
- пагинация архивов с тонким контентом;
- страницы поиска по сайту;
- URL с параметрами сортировки, фильтрации или UTM;
- страницы вложений медиафайлов без смысла для поиска;
— это хороший кандидат на noindex или каноникализацию. Но если страница полезна пользователю и должна ранжироваться, закрывать её не нужно.
Что смотреть в первую очередь
Откройте проблемный URL и проверьте три вещи:
- есть ли в
<head>тегmeta name="robots"; - какой
rel="canonical"указан; - не блокируется ли URL в
robots.txt.
Если страница уже в индексе, а на ней стоит только запрет в robots.txt, этого часто недостаточно. Поисковик может не увидеть мета-тег noindex, если обход страницы закрыт. Для удаления из индекса обычно нужен именно доступ робота к странице, чтобы он увидел сигнал noindex или корректный canonical.
Диагностика: где WordPress чаще всего ошибается
В WordPress проблемы обычно возникают не в ядре, а на стыке темы, SEO-плагина и дополнительных фильтров. Самые частые сценарии:
- SEO-плагин отключает индексацию архивов, но тема выводит свой canonical;
- в
robots.txtзакрыт путь, а страница уже должна выпасть черезnoindex; - плагин кэширования отдаёт старую версию HTML с прежними мета-тегами;
- в шаблоне темы вручную добавлен неверный canonical;
- страницы вложений редиректятся не туда, куда ожидается.
Быстрая проверка через консоль помогает понять, что реально отдает сервер:
curl -I https://example.com/tag/news/Затем посмотрите HTML-ответ:
curl -s https://example.com/tag/news/ | grep -iE 'robots|canonical'Если в ответе нет нужных тегов, проблема не в поисковике, а в генерации страницы WordPress.
Пошаговое решение: закрываем только то, что не должно индексироваться
1. Настройте noindex для архивов и служебных страниц
Если у вас есть SEO-плагин, сначала проверьте его настройки. Для архивов автора, тегов, дат и страниц поиска обычно достаточно штатных опций. Это безопаснее, чем править шаблоны вручную: плагин сам добавит нужный meta robots и canonical.
Если нужно сделать это кодом, можно добавить условный noindex в functions.php темы или в небольшой mu-plugin. Пример ниже закрывает архивы тегов, архивы автора и страницы поиска, но не трогает обычные записи и страницы:
add_filter('wp_robots', function ($robots) {
if (is_tag() || is_author() || is_search()) {
$robots['noindex'] = true;
$robots['nofollow'] = false;
}
return $robots;
});Этот способ работает на современных версиях WordPress, где используется фильтр wp_robots. Если у вас уже подключен SEO-плагин, проверьте, не конфликтует ли он с этим фильтром.
2. Исправьте canonical для дублей и страниц с параметрами
Canonical нужен там, где страница полезна для пользователя, но не должна конкурировать сама с собой. Например, у вас есть URL с параметрами сортировки или пагинацией, и поисковику нужно показать основную версию.
Если canonical генерируется вручную, проверьте, что он указывает на чистый URL без лишних параметров:
<link rel="canonical" href="https://example.com/category/news/" />В коде темы canonical лучше не собирать через $_SERVER['REQUEST_URI'] без фильтрации. Для WordPress безопаснее опираться на функции ядра и объект текущего запроса.
3. Не закрывайте в robots.txt то, что нужно удалить из индекса
robots.txt полезен для экономии crawl budget, но не как основной инструмент удаления URL из индекса. Если страница уже проиндексирована, а вы просто добавили Disallow, она может остаться в выдаче без сниппета.
Пример аккуратного robots.txt для WordPress — без лишней агрессии:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-login.php
Sitemap: https://example.com/sitemap_index.xmlНе стоит закрывать весь /wp-content/ или /wp-includes/, если вы не понимаете последствия. Это часто ломает индексацию ресурсов и мешает поисковику корректно рендерить страницу.
4. Уберите дубли на уровне шаблонов и плагинов
Если сайт генерирует несколько версий одного и того же материала, проверьте:
- архивы категорий и тегов с одинаковыми списками;
- страницы автора на сайте с одним автором;
- вложения медиафайлов, которые дублируют запись;
- страницы с параметрами фильтров, которые создают бесконечные комбинации URL.
Иногда проще отключить лишний тип архива, чем лечить его мета-тегами. Например, если архив автора не нужен, его можно закрыть через фильтр wp_robots и одновременно убрать ссылки на него из темы.
Проверка результата после внедрения
После правок не ограничивайтесь просмотром исходника в браузере. Проверяйте именно то, что увидит робот и что отдаёт сервер.
- Откройте страницу в режиме инкогнито и посмотрите исходный HTML.
- Проверьте
meta name="robots"иrel="canonical". - Сравните ответ
curlдо и после кэширования. - Если используете SEO-плагин, проверьте его настройки на уровне конкретной таксономии или типа записи.
- В Search Console отправьте URL на повторную проверку после того, как страница начнёт отдавать корректный сигнал.
Минимальный чек-лист для ручной проверки:
- страница служебного типа отдаёт
noindex; - основная версия страницы имеет правильный canonical;
- в
robots.txtнет случайного запрета на нужный раздел; - кэш не отдаёт старую версию HTML;
- в sitemap не попали URL, которые вы хотите скрыть от индекса.
Сравнение подходов: плагин, код или robots.txt
| Подход | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| SEO-плагин | Нужно быстро закрыть архивы, теги, автора, поиск | Меньше ручной работы, понятный интерфейс | Может конфликтовать с темой или другим SEO-плагином |
| Код в теме / mu-plugin | Нужна точечная логика под конкретный сайт | Полный контроль, нет лишних настроек | Требует тестирования после обновлений |
robots.txt | Нужно ограничить обход, а не удалить URL из индекса | Просто и быстро | Не решает задачу удаления уже проиндексированных страниц |
Частые ошибки и как их исправить
Закрыли URL в robots.txt и ждёте удаления из выдачи
Это самая частая ошибка. Если поисковик не может зайти на страницу, он не увидит noindex. Для уже проиндексированных URL сначала дайте роботу доступ, затем отдайте корректный сигнал на странице.
Поставили noindex, но страница всё равно в индексе
Причина может быть в кэше, в конфликте плагинов или в том, что поисковику ещё не пришёл новый ответ. Проверьте HTML через curl, очистите серверный и плагинный кэш, затем переобойдите URL в инструментах для вебмастеров.
Canonical указывает на несуществующую или редиректящую страницу
Такой canonical хуже, чем его отсутствие. Он должен вести на живую, конечную, каноническую версию без цепочек редиректов.
Закрыли слишком много
Иногда под раздачу попадают полезные категории, страницы пагинации или медиа, которые реально дают трафик. Перед массовым закрытием проверьте, есть ли у раздела поисковый спрос и входящий трафик.
Безопасность и производительность: что учесть до публикации изменений
Если вы правите тему или подключаете mu-plugin, делайте это через staging-копию. Ошибка в фильтре wp_robots не ломает сайт визуально, но может незаметно убрать из индекса важные страницы.
Ещё несколько практических моментов:
- не редактируйте родительскую тему напрямую, если используете обновления;
- проверяйте, не генерирует ли кэш старый canonical после деплоя;
- не добавляйте несколько SEO-плагинов одновременно;
- если используете кастомные типы записей, отдельно проверьте их архивы и таксономии;
- после изменений пересоберите sitemap, если он генерируется плагином.
Если нужен более системный контроль над дублями, архивами и технической чисткой сайта, иногда проще вынести это в один SEO-инструмент, чем держать набор разрозненных правок. Но даже в этом случае проверка через исходный HTML и ответ сервера остаётся обязательной.
В итоге рабочая схема простая: определить, что именно должно быть скрыто от индекса, выбрать правильный механизм для каждого типа URL и проверить фактический HTML-ответ, а не только настройки в админке.
