Если сайт на WordPress начал раздувать индекс за счет архивов, страниц авторов, тегов и служебных URL, проблема обычно не в «плохом SEO», а в настройках, которые никто не проверял после запуска. На небольшом сайте это незаметно, но на контентном проекте дубли быстро забивают обход и мешают поисковику сосредоточиться на нужных страницах.
Ниже — рабочая схема: что именно закрывать, чем отличается noindex от robots.txt, как не отрезать полезные страницы и как проверить, что изменения реально сработали.
Когда дубли действительно мешают
Не все архивы нужно закрывать автоматически. Сначала смотрим на структуру сайта и на то, какие URL уже попали в индекс. Типичный набор проблем выглядит так:
- страницы авторов дублируют ленту записей одного автора;
- архивы по датам не несут пользы, но создают десятки пустых URL;
- теги размножают один и тот же контент по разным страницам;
- страницы пагинации индексируются без смысла;
- служебные страницы поиска и внутренних фильтров попадают в индекс;
- в sitemap остаются URL, которые вы уже хотели скрыть.
Что проверить в первую очередь
Откройте отчет по индексированию в Google Search Console и посмотрите, какие типы страниц уже есть в индексе. Если там много архивов, тегов или страниц автора, это не теоретическая проблема, а уже накопленный мусор. Дополнительно проверьте исходный код страниц: есть ли на них meta robots с noindex, и не противоречит ли он правилам в robots.txt.
Чем отличается noindex от robots.txt
Это ключевой момент, и здесь часто ошибаются. robots.txt говорит поисковому роботу, куда не ходить. noindex говорит: страницу можно обойти, но в индекс ее не добавлять. Для дублей обычно безопаснее именно noindex,follow, а не запрет в robots.txt.
| Подход | Что делает | Когда применять | Риск |
|---|---|---|---|
noindex | Страница может быть просканирована, но не должна индексироваться | Архивы, теги, авторы, поиск | Если закрыть слишком много, можно потерять полезные посадочные |
robots.txt | Запрещает обход | Служебные разделы, которые не должны сканироваться | URL может остаться в индексе без контента, если уже был известен поисковику |
| Удаление из sitemap | Не подсказывает поисковику URL для обхода | Когда страница точно не нужна в поиске | Не заменяет noindex, если URL уже в индексе |
Пошаговое решение: закрываем лишние архивы
Самый практичный вариант — отключить индексацию там, где архив не несет самостоятельной ценности. Для этого можно использовать SEO-плагин или добавить код в тему/мини-плагин. Если у вас уже стоит плагин, который умеет управлять мета-тегами и дублями, это обычно проще и безопаснее, чем править шаблоны вручную.
Вариант 1: через код в functions.php или мини-плагине
Ниже пример, который ставит noindex,follow для архивов авторов, дат, тегов и страниц поиска. Код лучше держать в мини-плагине, а не в активной теме, чтобы не потерять настройки при обновлении темы.
<?php
add_filter('wp_robots', function ($robots) {
if (is_author() || is_date() || is_tag() || is_search()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Если у вас есть отдельные таксономии, которые нужны для SEO, не вешайте правило на все подряд. Например, рубрики могут быть полезны, а теги — нет. Тогда лучше разделить логику:
<?php
add_filter('wp_robots', function ($robots) {
if (is_tag() || is_search() || is_author() || is_date()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Вариант 2: через SEO-плагин
Если вы не хотите поддерживать код, используйте настройки индексации в SEO-плагине. Там обычно можно отдельно закрыть архивы авторов, теги, даты и страницы поиска. Это удобнее для редакторов, потому что правило видно в интерфейсе и его сложнее случайно сломать при обновлении темы.
Но у плагина есть минус: иногда он закрывает больше, чем нужно, особенно если на сайте нестандартная структура таксономий. Поэтому после изменения всегда проверяйте исходный код и sitemap.
Что делать с robots.txt
robots.txt нужен не для борьбы с дублями как таковыми, а для ограничения обхода служебных разделов. Например, можно закрыть внутренний поиск, если он генерирует мусорные URL, или технические каталоги, которые не должны сканироваться.
User-agent: *
Disallow: /search/
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.phpНе стоит закрывать в robots.txt страницы, которые уже в индексе и которые вы хотите убрать именно из выдачи. В этом случае поисковик может не увидеть noindex, если вы одновременно запретили обход. Для таких URL сначала ставят noindex, а уже потом, если нужно, ограничивают обход.
Проверка результата после внедрения
После правок не надо гадать, «вроде должно работать». Проверка занимает несколько минут и сразу показывает, где ошибка.
- Откройте страницу архива и посмотрите исходный код: должен быть
meta name="robots"сnoindexили соответствующий HTTP-эквивалент. - Проверьте
/robots.txtв браузере: правила должны быть доступны и без лишних запретов. - Посмотрите sitemap: закрытые страницы не должны туда попадать.
- В Google Search Console используйте проверку URL для конкретной страницы и посмотрите, как робот ее видит.
- Через несколько дней проверьте отчет по страницам в индексе: изменения не всегда видны мгновенно.
Что считать нормальным результатом
Нормально, если закрытые страницы еще какое-то время остаются в индексе. Поисковику нужно переобойти сайт и обновить сигнал. Ненормально, если в исходном коде нет noindex, но вы уверены, что он должен быть; или если sitemap продолжает отдавать URL, которые вы уже закрыли.
Частые ошибки и как их исправить
Здесь обычно ломают не SEO, а логику.
- Закрыли в robots.txt, но не поставили noindex. Если URL уже известен поисковику, он может остаться в индексе без контента. Исправление: сначала
noindex, потом ограничения обхода. - Закрыли все архивы подряд. Иногда рубрики реально собирают трафик и помогают навигации. Исправление: оставляйте индексируемыми только те архивы, которые дают уникальную ценность.
- Не убрали URL из sitemap. Это создает конфликт сигналов. Исправление: проверьте генератор sitemap и исключите закрытые типы страниц.
- Поставили правило в теме, а потом сменили тему. Настройка исчезла. Исправление: переносите логику в мини-плагин или mu-plugin.
- Закрыли страницы поиска, хотя они используются как посадочные. Такое бывает на крупных медиасайтах. Исправление: сначала оцените, есть ли у поиска трафик и смысл для индекса.
Безопасность и производительность
С точки зрения производительности закрытие дублей не ускоряет сайт напрямую, но снижает лишний обход и упрощает структуру. Это полезно для больших проектов, где поисковик тратит краулинговый бюджет на мусорные URL.
С точки зрения безопасности не стоит открывать в индексацию служебные страницы, которые показывают внутреннюю структуру сайта, параметры поиска или технические маршруты. Это не критичная уязвимость, но лишняя поверхность для сканирования вам обычно не нужна.
Если на сайте много дублей из-за плагинов, сначала посмотрите, не создают ли они лишние архивы, параметры или отдельные страницы для одного и того же контента. Иногда проще отключить генерацию дубля на уровне плагина, чем потом закрывать его от индексации.
Когда лучше не писать код вручную
Если на сайте несколько типов архивов, кастомные таксономии и разные правила для разделов, ручной код быстро становится хрупким. В такой ситуации удобнее использовать плагин, который управляет мета-тегами и дублями из админки. Например, в Clearfy Pro есть инструменты для чистки сайта и управления SEO-лишним, что полезно именно в сценарии с дублями и служебными страницами. Но даже с плагином принцип тот же: сначала определяете, какие URL реально не нужны, потом проверяете исходный код и sitemap.
Если хотите, чтобы правило не зависело от темы и не терялось при обновлениях, держите его в отдельном мини-плагине. Это самый практичный вариант для сайта, который живет дольше одной верстки.