Служебные URL с пагинацией часто попадают в индекс не потому, что сайт «плохой», а потому что поисковик видит их как отдельные страницы. На небольших и средних проектах это быстро раздувает индекс мусорными дублями: архивы, теги, рубрики, страницы автора и их страницы /page/2/, /page/3/ и дальше. Если задача именно в том, чтобы убрать из индекса только пагинацию page, а не ломать навигацию по сайту, подход нужен точечный.
Когда проблема действительно в пагинации /page/
Сначала проверьте, что вы боретесь именно с индексируемыми дублями, а не с нормальной страницей архива. Типичный сценарий выглядит так: в поиске есть URL вида /category/news/page/2/, /tag/seo/page/3/ или /author/admin/page/2/, а в отчётах по индексации растёт число страниц без уникальной ценности. При этом сами первые страницы архивов нужны, потому что они ведут пользователя к материалам.
Что смотреть в первую очередь
- отчёт Google Search Console по страницам в индексе;
- список URL с
/page/в логах или через поиск по сайту; - мета-тег robots на страницах пагинации;
- наличие canonical и его корректность;
- нет ли у вас уже плагина, который меняет robots или canonical.
Если на странице /page/2/ стоит index,follow, а canonical указывает на саму себя, поисковик вполне может держать её в индексе. Если же вы просто поставите noindex на все архивы подряд, можно случайно закрыть то, что должно оставаться доступным для обхода.
Какой вариант решения выбрать
Есть три рабочих подхода: через SEO-плагин, через код в теме или через комбинацию из robots/canonical. Для точечной задачи чаще всего достаточно кода или настроек плагина, если он уже стоит на сайте. Ниже — короткое сравнение.
| Подход | Когда подходит | Минус |
|---|---|---|
| SEO-плагин | Если уже используете плагин для meta robots и canonical | Не всегда удобно закрывать только пагинацию, а не весь архив |
| Код в functions.php | Нужна точная логика по типам архивов и страницам /page/ | Нужно аккуратно тестировать после обновлений темы |
| robots.txt | Когда нужно ограничить обход, а не индексацию | Не решает вопрос полностью: URL может оставаться в индексе без обхода |
Пошаговое решение через код
Если вам нужно убрать из индекса только пагинированные страницы архивов, самый предсказуемый способ — добавить noindex,follow на страницы с номером страницы больше первой. Для WordPress это можно сделать через фильтр wp_robots. Он работает с массивом директив robots и не требует правки шаблонов.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_paged() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Этот вариант закрывает все пагинированные страницы: рубрики, теги, архивы записей, архивы автора и другие архивные типы, где WordPress считает страницу «paged». Если вам нужно ограничить только теги, а остальные архивы оставить как есть, логика должна быть уже точнее.
<?php
add_filter( 'wp_robots', function( array $robots ) {
if ( is_tag() && is_paged() ) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
} );
Если нужно закрыть только /tag/.../page/...
Такой сценарий встречается часто: рубрики нужны для SEO и навигации, а теги — нет. Тогда лучше не использовать глобальный is_paged(), а ограничить правило только теговыми архивами. Это снижает риск случайно закрыть полезные страницы.
Если у вас уже есть SEO-плагин, проверьте, не дублируете ли вы его настройки кодом. Два источника директив robots могут дать непредсказуемый результат: один добавляет noindex, другой пытается его убрать, а в HTML остаётся мусорная смесь.
Что делать, если нужен не noindex, а запрет обхода
Иногда цель не в индексации, а в экономии краулингового бюджета. Тогда можно добавить правило в robots.txt, но только как дополнительную меру. Для поисковика это сигнал «не ходить», а не полноценное удаление из индекса. Если URL уже известен поиску, он может ещё долго висеть в выдаче без обновления.
User-agent: *
Disallow: /tag/*/page/
Disallow: /category/*/page/
Такое правило стоит использовать осторожно. Если у вас есть важные страницы пагинации, через которые робот должен добираться до старых материалов, закрывать их в robots.txt не лучшая идея. В большинстве случаев для WordPress безопаснее noindex,follow, а не полный запрет обхода.
Как проверить, что решение сработало
После внедрения не ограничивайтесь просмотром исходника одной страницы. Нужно проверить и HTML, и ответ сервера, и то, как поисковик видит URL.
- Откройте страницу
/page/2/и проверьте наличие<meta name="robots" content="noindex,follow">или эквивалентной директивы в HTML. - Убедитесь, что первая страница архива не получила
noindexслучайно. - Проверьте canonical: он должен быть логичным и не указывать на чужой раздел без причины.
- В Search Console отправьте URL на проверку и посмотрите, как Google читает страницу.
- Через несколько обходов проверьте, уменьшается ли число страниц с
/page/в индексе.
Если используете кэш, очистите его после правки. Иначе вы можете смотреть старую версию HTML и решить, что код не работает.
Частые ошибки и как их исправить
1. Закрыли все архивы вместо только пагинации
Это происходит, когда в коде ставят noindex на все архивные страницы без проверки is_paged(). Исправление простое: добавьте условие на номер страницы и отдельно проверьте, какие типы архивов вам действительно нужны.
2. Поставили noindex в robots.txt
В robots.txt нет директивы noindex для Google в том виде, как её часто ожидают. Для управления индексацией используйте meta robots или HTTP-заголовок X-Robots-Tag. Robots.txt подходит только для ограничения обхода.
3. Конфликт плагина и кода
Если SEO-плагин уже управляет robots, ваш фильтр может не дать ожидаемого результата. Проверьте, не создаёт ли плагин собственный canonical или meta robots. Иногда проще отключить настройку в интерфейсе плагина и оставить один источник правды.
4. Не учли кэш и CDN
После правки HTML может продолжать отдаваться старая версия из кэша страницы, сервера или CDN. Очистите все уровни кэширования и перепроверьте исходный код страницы в браузере без расширений.
Безопасность и производительность
Сам по себе фильтр wp_robots почти не влияет на производительность, но любая логика в functions.php должна быть предсказуемой. Не добавляйте тяжёлые запросы к базе внутри условий robots. Для такой задачи это не нужно.
Если вы редактируете тему напрямую, лучше вынести код в дочернюю тему или небольшой mu-plugin. Так правка не потеряется после обновления. Для сайтов, где часто приходится чистить дубли, служебные архивы и лишние страницы, удобнее держать такие настройки централизованно, а не размазывать их по шаблонам.
Если нужен более широкий набор инструментов для чистки дублей и технических SEO-настроек, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином важно понимать, какие именно URL вы закрываете и почему.
Короткий чек-лист перед публикацией
- определили, какие именно URL с
/page/нужно закрыть; - выбрали один источник управления robots: код или плагин;
- проверили, что первая страница архива осталась индексируемой;
- очистили кэш сайта и CDN;
- проверили HTML страницы и статус в Search Console;
- не закрыли важные страницы пагинации в robots.txt без необходимости.
Если задача решена правильно, в индексе постепенно останутся только те страницы архивов, которые действительно нужны, а служебная пагинация перестанет раздувать отчёты и мешать технической чистоте сайта.