На небольших и средних WordPress-сайтах дубли часто появляются не только из-за пагинации или архивов. Проблему создают тонкие страницы: результаты поиска по сайту, страницы с пустыми таксономиями, вложения медиафайлов, служебные URL плагинов, иногда — страницы с почти одинаковым контентом, но разными параметрами в адресе. В индексе они выглядят как мусор, а в отчётах по сканированию забирают бюджет и размывают релевантность.
Ниже разберём, как определить такие страницы, что закрывать через noindex, где нужен canonical, а где лучше вообще убрать URL из генерации. Это не универсальная «магия SEO», а рабочая схема для типовых WordPress-проектов.
Какие страницы считать тонкими и почему они вредят
Тонкая страница — это URL, который почти не несёт самостоятельной ценности для поиска. У WordPress это часто:
- страницы внутреннего поиска вида
?s=; - архивы без записей;
- вложения медиафайлов, если они открываются как отдельные страницы;
- страницы тегов и рубрик с 1–2 записями, если они не нужны как посадочные;
- служебные страницы плагинов, которые не должны попадать в поиск;
- URL с параметрами сортировки, фильтров и трекинга.
Проблема не только в «дублях». Поисковик может потратить время на обход таких адресов, а в выдаче показывать не ту страницу, которую вы хотите ранжировать. Если на сайте уже есть статьи про дубли архивов авторов, тегов и пагинации, логично идти дальше и закрывать остальные служебные и слабые URL.
Диагностика: как понять, что именно нужно закрывать
Сначала не трогайте настройки вслепую. Проверьте, какие адреса реально индексируются и как они выглядят для робота.
Что смотреть в первую очередь
- Google Search Console — отчёт по страницам и исключённым URL.
- Сайт:оператор в поиске — например,
site:example.com inurl:?s=илиsite:example.com inurl:/attachment/. - Логи обхода или отчёты краулера, если они есть.
- HTML-код страниц — есть ли
meta robotsи какойcanonicalуказан.
Если страница уже в индексе, просто убрать её из меню недостаточно. Нужно либо дать поисковику явный сигнал noindex, либо настроить редирект, либо удалить URL из генерации, если он не нужен вообще.
Когда нужен noindex, а когда canonical
| Сценарий | Что делать | Комментарий |
|---|---|---|
| Внутренний поиск | noindex, follow | Страница полезна пользователю, но не должна ранжироваться. |
| Вложения медиа | Редирект на файл или родительскую запись | Если attachment pages не нужны, лучше убрать их из индекса и навигации. |
| Параметры фильтров | canonical на основную страницу или запрет генерации | Если контент тот же, но URL отличается параметрами. |
| Пустые рубрики/теги | Скрыть или noindex | Если таксономия не несёт ценности, лучше не плодить пустые архивы. |
Пошаговое решение для WordPress
1. Закройте внутренний поиск от индексации
Страницы поиска почти всегда должны быть noindex. Это не значит, что их нужно ломать для пользователя. Достаточно дать поисковику сигнал не включать их в выдачу.
Если у вас есть доступ к коду темы или мини-плагину, можно добавить мета-тег через wp_head только для страниц поиска:
add_action( 'wp_head', function () {
if ( is_search() ) {
echo '<meta name="robots" content="noindex,follow">' . "\n";
}
} );Проверка простая: откройте страницу поиска и посмотрите исходный код. В <head> должен появиться нужный meta robots. Если используете SEO-плагин, убедитесь, что он не переопределяет этот тег своим шаблоном.
2. Уберите attachment pages, если они не нужны
Страницы вложений — частая причина мусора в индексе. Если пользователь открывает не сам файл, а отдельную страницу вложения, это обычно слабый URL. В большинстве проектов лучше редиректить такие страницы на сам файл или на родительскую запись.
Рабочий вариант через template_redirect:
add_action( 'template_redirect', function () {
if ( is_attachment() ) {
$parent = wp_get_post_parent_id( get_the_ID() );
if ( $parent ) {
wp_redirect( get_permalink( $parent ), 301 );
exit;
}
$file = wp_get_attachment_url( get_the_ID() );
if ( $file ) {
wp_redirect( $file, 301 );
exit;
}
}
} );Если у вас медиа-контент важен сам по себе, не делайте это автоматически. Сначала проверьте, не используются ли attachment pages как посадочные в поиске или в навигации.
3. Приведите canonical в порядок для параметров и дублей
Если у вас есть страницы с параметрами сортировки, фильтров или UTM, canonical должен указывать на чистую основную версию URL. В простом случае это можно сделать на уровне шаблона, но лучше не городить самописную логику там, где уже есть SEO-плагин.
Если нужен точечный контроль, можно задать canonical через фильтр wpseo_canonical в Yoast SEO или аналогичный механизм в вашем плагине. Пример для Yoast:
add_filter( 'wpseo_canonical', function ( $canonical ) {
if ( is_search() ) {
return home_url( '/' );
}
return $canonical;
} );Это не универсальная настройка на все случаи. Для страниц фильтров лучше сначала определить, должен ли такой URL вообще существовать. Если фильтр создаёт тысячи комбинаций, canonical не спасёт от лишнего обхода, и тогда надо ограничивать генерацию URL на уровне шаблона или плагина фильтрации.
4. Сократите генерацию пустых архивов и таксономий
Если рубрика или тег пустые, не стоит оставлять их доступными как полноценные страницы. В WordPress это часто происходит после импорта контента, чистки записей или смены структуры рубрик.
Проверить можно через админку или запросом к базе. Если вы работаете с кодом, полезно быстро посмотреть, есть ли у термина записи:
$term = get_term_by( 'slug', 'example-tag', 'post_tag' );
if ( $term && ! is_wp_error( $term ) ) {
$count = (int) $term->count;
if ( $count === 0 ) {
// Термин пустой, его лучше скрыть или удалить.
}
}Для массовой чистки удобнее сначала пройтись по таксономиям в админке, а потом уже решать, что удалять, а что оставлять как навигационный слой.
Как проверить, что решение сработало
После внедрения не ограничивайтесь визуальной проверкой. Нужно убедиться, что поисковик видит именно тот сигнал, который вы задумали.
- Откройте проблемный URL и проверьте исходный код: есть ли
noindexили корректныйcanonical. - Проверьте HTTP-ответ: если нужен редирект, он должен быть
301, а не302. - В Search Console отправьте проверку URL и посмотрите, как Google видит страницу.
- Через несколько обходов проверьте, исчез ли URL из отчёта по индексированию или перешёл ли в исключённые.
Если страница всё ещё индексируется, обычно причина одна из трёх: тег robots не попал в шаблон, canonical конфликтует с другим плагином, или URL продолжает генерироваться в sitemap и внутренних ссылках.
Частые ошибки и как их исправить
Ставят noindex, но оставляют страницу в sitemap
Это частая ошибка. Sitemap и robots-сигналы должны быть согласованы. Если URL не должен индексироваться, он не должен активно предлагаться поисковику через карту сайта.
Закрывают URL в robots.txt вместо noindex
Disallow не убирает уже проиндексированную страницу из выдачи. Если URL уже в индексе, сначала нужен корректный сигнал на самой странице или редирект.
Делают редирект на главную без логики
Редирект всех слабых страниц на главную выглядит просто, но часто ухудшает поведение сайта. Для вложений лучше вести на родительскую запись или файл, а не на случайную главную страницу.
Путают canonical и редирект
canonical — это подсказка, а не жёсткий запрет. Если URL технически не нужен, надёжнее редирект или удаление генерации. Canonical полезен, когда страницы должны открываться для пользователя, но в индексе нужна только одна версия.
Безопасность и производительность: что учесть до и после правок
Если вы вносите код в тему, лучше не править functions.php напрямую на боевом сайте. Используйте дочернюю тему или небольшой mu-plugin, чтобы не потерять изменения при обновлении.
Перед массовыми редиректами сделайте резервную копию и проверьте, нет ли на этих URL внешних ссылок. Если страница получает трафик, иногда лучше оставить её доступной, но закрыть от индексации, чем резко ломать входящие переходы.
Для сайтов с большим количеством параметров и фильтров полезно дополнительно ограничить генерацию таких URL на уровне плагина или шаблона. Иначе поисковик будет тратить ресурсы на обход страниц, которые вы всё равно не хотите видеть в выдаче.
Если нужен более системный подход к чистке дублей и технических мелочей, можно посмотреть в сторону инструментов вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с плагином важно понимать, какие URL вы закрываете и почему — иначе легко спрятать полезные страницы вместе с мусором.
Практический чек-лист перед публикацией правок
- Проверить, какие URL реально попадают в индекс.
- Определить тип страницы: поиск, attachment, фильтр, пустая таксономия, служебный URL.
- Выбрать действие:
noindex,canonical, редирект или удаление генерации. - Сверить sitemap и внутренние ссылки.
- Проверить исходный код и HTTP-ответ после внедрения.
- Отправить проблемные URL на повторную проверку в Search Console.
Если действовать по этой схеме, вы не просто «закроете что-то от индексации», а приведёте в порядок конкретный слой технических URL. Для WordPress это обычно даёт более чистый индекс и меньше лишнего шума в отчётах по сканированию.