Служебные архивы в WordPress часто попадают в индекс сами по себе: страницы автора, архивы по датам, теги, вложения, страницы поиска. На небольшом сайте это обычно просто шум. На контентном проекте — ещё и дубли, которые размывают релевантность и мешают поисковику понять, какие URL действительно важны.
Ниже — рабочая схема, как закрывать такие страницы без лишней магии: где достаточно noindex, где нужен canonical, а где лучше вообще убрать URL из генерации или отдачи.
Какие страницы обычно нужно проверить в первую очередь
Не стоит закрывать всё подряд. Сначала посмотрите, какие типы архивов реально существуют на сайте и индексируются ли они. В WordPress чаще всего проблема возникает с такими URL:
- архивы автора:
/author/username/; - архивы по датам:
/2026/09/и похожие; - страницы тегов, если теги создаются автоматически и не ведутся;
- страницы вложений: отдельные URL медиафайлов;
- внутренний поиск:
/?s=...; - служебные страницы пагинации архивов, если они не несут ценности.
Если сайт небольшой и автор один, архив автора почти всегда дублирует главную или страницу блога. Если авторов несколько и у каждого есть нормальная биография, список материалов и своя роль в структуре сайта, закрывать архивы автора бездумно уже не стоит.
Диагностика: как понять, что именно мешает индексации
Перед правками проверьте три вещи: что уже в индексе, какие мета-теги отдаются в HTML и не конфликтуют ли настройки плагинов SEO с темой или кастомным кодом.
1. Проверьте индекс через поиск и Search Console
В Google Search Console откройте отчёт по страницам и посмотрите, какие служебные URL уже попали в индекс. Дополнительно можно сделать ручную проверку через поиск по сайту:
site:example.com authorЕсли в выдаче есть архивы, которые вам не нужны, значит, проблема не только в robots.txt. Поисковик уже увидел URL и может держать его в индексе даже после закрытия в robots.txt.
2. Посмотрите исходный код страницы
Откройте архив автора или тегов и проверьте, есть ли в <head> мета-роботы и canonical. Ищите строки вида:
<meta name="robots" content="noindex,follow">
<link rel="canonical" href="https://example.com/author/username/">Если canonical указывает на саму страницу, а вам нужно исключить её из индекса, это не ошибка само по себе. Но если canonical ведёт на нерелевантный URL или вообще отсутствует, поисковик может дольше переоценивать страницу.
3. Проверьте, не дублирует ли решение SEO-плагин
Если у вас уже стоит SEO-плагин, он может добавлять свои правила. В этом случае не нужно дублировать логику в теме и в плагине одновременно. Иначе получится конфликт: один код ставит noindex, другой снимает его, третий меняет canonical.
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если нужно управлять архивами без кода | Меньше контроля над логикой |
| Код в теме или mu-plugin | Если нужна точечная настройка | Нужно следить за обновлениями и тестами |
| robots.txt | Для технической отсечки краулера | Не убирает URL из индекса мгновенно |
Пошаговое решение: закрываем архивы автора и даты без лишних побочных эффектов
Самый практичный вариант — не блокировать URL в robots.txt, а отдавать noindex,follow для тех страниц, которые не должны ранжироваться. Так поисковик увидит страницу, поймёт правило и со временем исключит её из индекса, не ломая проход по внутренним ссылкам.
Вариант 1. Через фильтр WordPress и SEO-плагин
Если вы используете SEO-плагин, сначала проверьте его настройки. Но когда нужен свой контроль, можно добавить фильтр в functions.php дочерней темы или в небольшой mu-plugin.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_author() || is_date() || is_search() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Этот вариант работает на уровне WordPress и не требует править шаблоны head вручную. Но он не решает всё: если тема или плагин уже выводят собственный meta robots, проверьте, не дублируется ли тег в HTML.
Вариант 2. Для страниц вложений и пустых архивов
Страницы вложений часто создают лишние URL без ценности. Если они не нужны как отдельные посадочные, их лучше редиректить на сам файл или на родительскую запись. Для этого обычно используют код в теме или плагин, который умеет перенаправлять attachment pages.
Если редирект не подходит, как минимум закройте их от индексации:
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_attachment() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );Вариант 3. Управление canonical для архивов
Canonical полезен там, где архив существует, но не должен конкурировать с основными страницами. Например, архив тега может быть полезен для навигации, но не должен отбирать трафик у основной рубрики. В таком случае canonical обычно оставляют на саму страницу архива, а noindex используют только для слабых или пустых архивов.
Если вы хотите убрать из индекса конкретный тип архивов, но сохранить обход ссылок, не пытайтесь заменять noindex на canonical в одиночку. Canonical — это подсказка, а не запрет.
Когда robots.txt помогает, а когда мешает
robots.txt полезен для ограничения обхода, но не для удаления уже известных URL из индекса. Это частая ошибка: страницу закрыли в robots.txt, но она продолжает показываться в поиске как URL без описания.
Используйте robots.txt только для действительно технических разделов, где не нужен обход:
/wp-admin/;- служебные параметры, если они создают мусорный crawl;
- временные каталоги и тестовые пути, если они вообще доступны извне.
Если задача именно убрать архив из индекса, безопаснее отдавать noindex в HTML и не блокировать страницу в robots.txt, пока поисковик не переобойдёт её и не увидит мета-робот.
Проверка результата после внедрения
После правок не ограничивайтесь визуальной проверкой. Нужно убедиться, что сервер отдаёт нужные сигналы, а не только что «в админке всё включено».
- Откройте проблемный URL в браузере и посмотрите исходный код.
- Проверьте наличие
<meta name="robots" content="noindex,follow">или эквивалентного значения. - Убедитесь, что canonical не указывает на случайную страницу.
- В Search Console отправьте URL на повторную проверку после переобхода.
- Проверьте, не остались ли дубли в sitemap.xml, если он генерируется автоматически.
Если страница уже была в индексе, исчезновение может занять время. Это нормально. Важно, чтобы после переобхода поисковик увидел корректные сигналы, а не конфликтующие правила.
Частые ошибки и как их исправить
Ошибка 1. Закрыли в robots.txt и ждёте удаления из индекса
Такой подход не работает как полноценное удаление. Поисковик может перестать обходить страницу, но URL останется в индексе дольше, чем вы ожидаете. Исправление: сначала noindex, потом при необходимости ограничение обхода.
Ошибка 2. Ставят noindex на все архивы подряд
Если у сайта есть полезные рубрики, теги или архивы авторов с реальной ценностью, массовое закрытие ухудшает структуру. Исправление: разделите архивы на полезные и служебные. Закрывайте только те, которые не несут самостоятельной ценности.
Ошибка 3. Дублируют правила в плагине и в теме
Когда одно и то же правило прописано в нескольких местах, потом сложно понять, кто именно его ломает. Исправление: оставьте один источник правды — либо SEO-плагин, либо код в теме/mu-plugin.
Ошибка 4. Ломают canonical на страницах пагинации
Иногда canonical у страниц пагинации принудительно ставят на первую страницу архива. Это не всегда ошибка, но если пагинация нужна для обхода и навигации, проверьте, не ухудшает ли это обход контента. Исправление: тестируйте на реальном сайте, а не по шаблону.
Практика безопасности и производительности
Если вы добавляете код вручную, лучше не править основной файл темы. Используйте дочернюю тему или mu-plugin, чтобы обновление не затёрло изменения. Для точечных SEO-правил mu-plugin часто удобнее: он загружается стабильно и не зависит от активной темы.
Ещё один полезный момент: не плодите тяжёлые проверки в каждом запросе. Условия вроде is_author() и is_date() дешёвые, но если вы добавляете сложную логику с запросами к базе внутри фильтра, это уже лишняя нагрузка на фронтенд.
Если нужен более управляемый набор SEO-правил без ручного кода, можно посмотреть в сторону плагинов, которые умеют закрывать архивы и чистить дубли. Например, у Clearfy Pro есть инструменты для технической оптимизации и удаления лишних дублей: https://wpshop.ru/plugins/clearfy.
Мини-чек-лист перед публикацией изменений
- Проверили, какие архивы реально индексируются.
- Убедились, что нужные страницы получают
noindex,follow. - Не закрыли полезные разделы случайно.
- Проверили исходный код страницы, а не только настройки в админке.
- Убрали конфликтующие правила из темы, плагина и robots.txt.
- Отправили проблемные URL на повторную проверку в Search Console.
Если после правок в индексе всё ещё остаются старые URL, это обычно вопрос времени и переобхода. Но если в HTML по-прежнему нет нужных мета-тегов, значит, проблема не в поиске, а в том, что правило не доходит до шаблона. Тогда проще всего начать с исходного кода и проверить, кто именно его перезаписывает.