Если в индексе уже есть страницы поиска, архивы по датам, вложения медиафайлов и пустые таксономии, проблема обычно не в «плохом SEO», а в том, что WordPress по умолчанию публикует слишком много технических URL. Их не всегда нужно удалять из сайта — чаще достаточно правильно закрыть от индексации и убрать из карты сайта.
Ниже — рабочая схема: что именно закрывать, как это сделать без конфликтов с темой и плагинами, и как проверить, что поисковик действительно перестал тратить краулинговый бюджет на мусорные страницы.
Какие страницы WordPress чаще всего нужно закрывать
Сначала стоит понять, что именно у вас попало в индекс. Обычно это не только очевидные страницы поиска, но и URL, которые создаются автоматически и не дают ценности пользователю.
Типичные кандидаты на закрытие
- страницы внутреннего поиска вида
?s=; - архивы по датам, если сайт не новостной;
- архивы авторов, если на сайте один автор;
- страницы вложений медиафайлов;
- пустые или почти пустые теги;
- служебные страницы пагинации, если они дублируют контент и не несут самостоятельной ценности;
- страницы параметров, которые создаются фильтрами, но не должны индексироваться.
Не нужно закрывать всё подряд. Например, архивы категорий на контентном сайте часто полезны и должны оставаться в индексе. Если закрыть их по привычке, можно потерять нормальные точки входа из поиска.
Диагностика проблемы: где искать дубли и мусорные URL
Перед правками проверьте, какие страницы уже индексируются. Самый быстрый путь — выгрузка из Google Search Console и поиск по шаблонам URL. Если у вас есть доступ к серверным логам, полезно посмотреть, какие URL чаще всего обходят боты, но не дают трафика.
Практически это выглядит так:
- в Search Console откройте отчёт по индексированию страниц;
- отфильтруйте URL с
?s=,/author/,/date/,/attachment/; - проверьте, не дублируются ли записи через архивы тегов и рубрик;
- посмотрите, не попали ли в индекс страницы пагинации с тонким контентом.
Если у вас установлен SEO-плагин, проверьте его настройки раньше, чем писать код. Часто проблема уже решается в интерфейсе, а ручные правки только создают конфликт.
Пошаговое решение: закрываем служебные страницы правильно
Есть три рабочих подхода: через SEO-плагин, через robots.txt и через код. На практике лучше комбинировать первый и третий вариант: плагин управляет мета-тегами и картой сайта, код — точечно отключает лишнее там, где интерфейса не хватает.
| Подход | Когда использовать | Плюс | Минус |
|---|---|---|---|
| SEO-плагин | Для большинства сайтов | Быстро и без кода | Не всегда хватает точности |
| Код в теме или mu-plugin | Когда нужен контроль над конкретными URL | Гибко и прозрачно | Нужно тестировать после обновлений |
robots.txt | Для ограничения обхода | Просто закрыть от ботов | Не убирает уже проиндексированные страницы |
1. Закройте индексацию через мета-теги на уровне WordPress
Если нужен точечный контроль без плагина, можно добавить noindex для поиска, архивов автора и дат. Это не удаляет страницу с сайта, а только просит поисковик не включать её в индекс.
add_action('wp_head', function () {
if (is_search() || is_author() || is_date()) {
echo '<meta name="robots" content="noindex,follow" />' . "\n";
}
});Этот вариант работает, но его лучше использовать аккуратно. Если у вас уже стоит SEO-плагин, проверьте, не выводит ли он собственный noindex. Два разных источника разметки иногда дают путаницу при отладке.
2. Уберите вложения и медиа-страницы из индекса
Страницы вложений часто индексируются отдельно от самих файлов изображения. Для большинства сайтов это лишний слой дублей. Проще всего перенаправить такие страницы на сам файл или на родительскую запись.
add_action('template_redirect', function () {
if (is_attachment()) {
$parent = wp_get_post_parent_id(get_the_ID());
if ($parent) {
wp_safe_redirect(get_permalink($parent), 301);
exit;
}
$file = wp_get_attachment_url(get_the_ID());
if ($file) {
wp_safe_redirect($file, 301);
exit;
}
}
});Если вложение без родителя, редирект на файл обычно безопаснее, чем оставлять пустую страницу. Но если у вас медиа используется как самостоятельный контент, этот шаг нужно пересмотреть.
3. Исключите служебные URL из карты сайта
Даже если страница закрыта через noindex, она может продолжать попадать в sitemap. Для поисковика это лишний сигнал и лишняя работа. В SEO-плагине обычно есть отдельные переключатели для архивов авторов, дат, тегов и медиа.
Если карта сайта формируется кодом или через фильтры WordPress, проверьте, что туда не попадают служебные записи. Для стандартного ядра WordPress это особенно актуально, если вы используете собственную логику генерации sitemap.
4. Ограничьте индексацию поиска и параметров
Страницы поиска почти всегда создают тонкий контент. Их лучше закрывать от индексации и не добавлять в sitemap. Для параметров фильтрации логика зависит от структуры сайта: иногда достаточно noindex, иногда нужен канонический URL на основную категорию.
Если фильтры создают десятки комбинаций URL, не пытайтесь закрыть их только через robots.txt. Бот может перестать обходить страницы, но уже найденные URL останутся в индексе до следующей переобработки.
Что проверить после внедрения
После изменений важно не гадать, а проверить результат по нескольким признакам. Один только мета-тег noindex не гарантирует мгновенного исчезновения страницы из поиска.
- откройте страницу в браузере и проверьте исходный код на наличие
noindex,follow; - убедитесь, что URL исчез из sitemap;
- в Search Console отправьте страницу на повторную проверку;
- проверьте, не остался ли старый canonical на мусорный URL;
- посмотрите, не создаёт ли тема отдельный шаблон для архивов, который переопределяет ваши правила.
Если используется кэш, очистите его после правок. Иначе вы можете проверять уже старую версию страницы и думать, что код не сработал.
Частые ошибки и как их исправить
Закрыли в robots.txt, но страница всё ещё в индексе
Это нормальная ситуация. robots.txt ограничивает обход, но не удаляет уже известный URL из индекса. Для удаления нужен noindex на самой странице или временное удаление через Search Console.
Поставили noindex и одновременно запретили обход
Если бот не может зайти на страницу, он не увидит мета-тег noindex. В результате URL может дольше оставаться в индексе. Для удаления лучше сначала дать боту увидеть noindex, а уже потом при необходимости ограничивать обход.
Сломали архивы, которые приносили трафик
Частая ошибка — закрыть все архивы подряд без анализа. Перед изменениями посмотрите, какие страницы реально получают переходы и показы. Категории и некоторые теги могут быть полезны, особенно если они хорошо заполнены.
Оставили дубль через вложения
Если медиа-страницы не редиректятся, поисковик может продолжать индексировать их как отдельные URL. Это особенно заметно на сайтах с большим количеством изображений и слабой внутренней перелинковкой.
Практические советы по безопасности и производительности
Если вы вносите правки кодом, лучше не редактировать functions.php напрямую на боевом сайте. Безопаснее использовать дочернюю тему или небольшой mu-plugin. Так вы не потеряете изменения после обновления темы и сможете быстро отключить логику, если что-то пойдёт не так.
Ещё один полезный момент: не плодите тяжёлые проверки на каждом запросе. Для простых условий вроде is_search() и is_attachment() это не проблема, но сложные выборки по базе на фронтенде лучше не делать без необходимости.
Если у вас уже есть SEO-плагин, сравните его возможности с ручной реализацией. На большинстве сайтов достаточно штатных настроек, а код нужен только для узких случаев: нестандартные архивы, особые шаблоны, специфические фильтры или медиа-страницы.
Короткий чек-лист перед публикацией изменений
- проверить, какие URL реально мусорные, а какие дают трафик;
- настроить
noindexдля поиска, дат, авторов и вложений, если они не нужны в индексе; - убрать служебные страницы из sitemap;
- очистить кэш сайта и CDN;
- проверить исходный код и canonical;
- отправить важные URL на повторную проверку в Search Console;
- смотреть не только на индексацию, но и на трафик по категориям и архивам.
Если задача сводится к массовой чистке дублей и служебных страниц, иногда удобнее сначала пройтись по настройкам SEO-плагина, а уже потом добивать точечные случаи кодом. Для сайтов на WordPress это обычно самый предсказуемый путь: меньше ручных костылей, проще поддержка, меньше сюрпризов после обновлений.