Если в Search Console растут «Просканировано, но не проиндексировано», а в индексе всплывают одинаковые страницы с разными URL, проблема часто не в контенте, а в технических дублях. В WordPress это обычно пагинация, параметры в адресе, архивы тегов, страницы автора, сортировки и служебные версии одного и того же материала.
Ниже — рабочая схема: как диагностировать источник дублей, что закрывать через noindex, где ставить canonical, а где лучше вообще убрать генерацию лишних URL на уровне темы или плагина.
Что именно считается дублем в WordPress
Дубль — это не только две одинаковые записи. На практике это разные URL, которые ведут на один и тот же или почти одинаковый контент. Поисковик тратит краулинговый бюджет на лишние адреса, а основной URL может ранжироваться хуже, чем мог бы.
Типовые источники дублей
- страницы пагинации архивов:
/page/2/,/page/3/; - URL с параметрами:
?utm_source=,?replytocom=,?orderby=; - архивы тегов и рубрик с тем же текстом, что и у записей;
- страницы автора и даты, если они не несут самостоятельной ценности;
- версии одной страницы с и без слеша, http и https, www и без www;
- страницы поиска по сайту, если они индексируются;
- служебные страницы плагинов, которые случайно попали в карту сайта.
Диагностика: где искать проблему
Начинать лучше не с правок, а с проверки фактических URL в индексе и на сайте. Иначе легко закрыть от индексации то, что и так не мешает, и пропустить реальный источник мусора.
Проверка через Search Console и сайт
- Откройте отчет по страницам в Google Search Console и отфильтруйте URL с параметрами, пагинацией и архивами.
- Сравните количество страниц в карте сайта и количество реально полезных URL на сайте.
- Проверьте исходный код проблемных страниц: есть ли
rel="canonical", не стоит ли случайноnoindexна нужных страницах. - Посмотрите, не генерирует ли тема или плагин дубли через фильтры, сортировки или внутренний поиск.
Быстрая проверка через серверные логи и краулер
Если есть доступ к логам, полезно посмотреть, какие URL чаще всего запрашивают боты. Для локальной проверки удобно использовать любой краулер, но даже без него можно быстро найти мусорные адреса через поиск по сайту и шаблонам URL.
grep -R "replytocom\|/page/[0-9]\+/\|?orderby=\|?utm_" /var/log/nginx/access.logЕсли в логах много запросов к параметрам и пагинации, это сигнал не только для SEO, но и для производительности: бот тратит ресурсы на обход лишнего.
Что закрывать, а что оставлять
Не все дубли надо одинаково обрабатывать. Иногда достаточно canonical, иногда нужен noindex,follow, а иногда лучше убрать сам источник URL.
| Сценарий | Что делать | Компромисс |
|---|---|---|
| Параметры сортировки и UTM | Ставить canonical на чистый URL, не индексировать служебные версии | Параметры остаются для аналитики, но не плодят индекс |
| Архивы тегов без ценности | noindex,follow или отключение архива | Теги не помогают SEO, но могут быть полезны для навигации |
| Пагинация архивов | Оставить доступной для обхода, не ломать ссылки | Не закрывать всё подряд, иначе бот хуже добирается до материалов |
| Страницы автора/даты | Закрыть от индексации, если они не нужны в поиске | Нужно проверить, не теряется ли полезный трафик с брендовых запросов |
Пошаговое решение: убираем дубли без потери обхода
Шаг 1. Нормализуйте canonical
На каждой индексируемой странице должен быть один канонический адрес. Если тема или SEO-плагин ставит canonical неправильно, поисковик может выбрать не ту версию страницы.
Для записи canonical обычно генерируется автоматически. Но если у вас кастомный шаблон или нестандартная логика, проверьте, что в <head> нет нескольких canonical и что он указывает на чистый URL без параметров.
<?php
add_action('wp_head', function () {
if (is_singular()) {
$canonical = get_permalink();
echo '<link rel="canonical" href="' . esc_url($canonical) . '" />' . "\n";
}
}, 1);Этот пример нужен только как ориентир. Если у вас уже стоит SEO-плагин, не дублируйте его вывод вручную, иначе получите два canonical и новую проблему вместо старой.
Шаг 2. Закройте служебные архивы от индексации
Если страницы автора, даты или теги не несут самостоятельной ценности, их лучше не показывать в поиске. Делать это можно через SEO-плагин или кодом. Код нужен, когда нужен точечный контроль.
<?php
add_filter('wp_robots', function ($robots) {
if (is_author() || is_date() || is_tag()) {
$robots['noindex'] = true;
$robots['follow'] = true;
}
return $robots;
});Такой подход не удаляет страницы из сайта, а только сигнализирует поисковику не добавлять их в индекс. Ссылки при этом продолжают обходиться.
Шаг 3. Уберите мусорные параметры из индекса
Параметры вроде ?replytocom= или ?orderby= часто создают дубли. Если они не нужны для SEO, лучше не давать им отдельный canonical. Для комментариев и сортировок обычно достаточно, чтобы поисковик видел основную страницу без параметров.
Если параметр генерируется вашим кодом, проверьте, нельзя ли заменить его на AJAX или на серверную сортировку без отдельного URL. Это особенно полезно для каталогов, фильтров и списков записей.
Шаг 4. Проверьте карту сайта
В sitemap должны попадать только те URL, которые вы действительно хотите индексировать. Если туда попали архивы, служебные страницы или дубли с параметрами, поисковик будет тратить время на мусор.
- уберите из sitemap страницы поиска;
- исключите архивы, которые закрыты
noindex; - проверьте, что в карту не попали черновики, вложения и служебные шаблоны;
- после правок пересоздайте sitemap и отправьте его в Search Console.
Когда лучше исправлять на уровне темы или плагина
Если дубли появляются из-за шаблона, править только мета-теги недостаточно. Например, тема может выводить одинаковые блоки на главной, в архиве и на странице записи, а SEO-плагин это не решит.
Полезный ориентир: если лишний URL создается без необходимости, лучше убрать сам источник. Если URL нужен пользователю, но не нужен в поиске, тогда используйте canonical и noindex. Если URL нужен и пользователю, и поиску, оставляйте его, но следите за уникальностью контента.
Проверка результата после внедрения
После правок не стоит ждать мгновенного эффекта. Сначала проверьте, что сервер и HTML отдают именно то, что вы задумали.
Что проверить руками
- в исходном коде есть один canonical на чистый URL;
- на закрытых страницах присутствует
noindex; - в sitemap нет лишних архивов и служебных адресов;
- страницы с параметрами не создают отдельные канонические версии;
- основные записи доступны без редиректов по цепочке.
Что проверить в Search Console
Смотрите не только на индекс, но и на причины исключения. Если после правок количество дублей с параметрами и архивами снижается, значит схема работает. Если нет — значит источник URL остался в теме, плагине или карте сайта.
Для точечной проверки можно взять проблемный URL и сравнить его ответ с основным адресом через curl:
curl -I https://example.com/post-name/?utm_source=test
curl -I https://example.com/post-name/В идеале служебный URL не должен становиться отдельной индексируемой сущностью. Если он отдает 200 и полноценную страницу, а canonical указывает на себя, это и есть причина дубля.
Частые ошибки и как их исправить
Закрыли от индексации всё подряд
Частая ошибка — поставить noindex на архивы, пагинацию и рубрики без разбора. В итоге поисковик хуже добирается до контента, а внутренние ссылки теряют часть смысла. Исправление простое: закрывайте только те типы страниц, которые не несут самостоятельной ценности.
Canonical указывает на страницу с параметрами
Если canonical содержит UTM или сортировку, поисковик может считать именно эту версию основной. Нужно нормализовать адрес до чистого URL и проверить шаблон вывода.
В sitemap остались закрытые страницы
Это частая рассинхронизация между SEO-плагином и картой сайта. Страница уже закрыта, но продолжает отправляться в sitemap. Уберите ее из генерации карты и пересоздайте файл.
Дубли создаёт не WordPress, а серверный редирект
Иногда проблема не в CMS, а в конфигурации nginx или Apache: одна и та же страница доступна по нескольким схемам адресации. Проверьте редиректы с http на https, www на без www и со слеша на слеш. Должна остаться одна версия.
Практические советы по безопасности и производительности
Чем меньше лишних URL, тем меньше нагрузка на сервер и тем проще аудит. Это не заменяет кэш, но помогает ему работать чище. Если у вас много технических архивов и параметров, стоит дополнительно:
- ограничить генерацию служебных страниц в теме;
- не выводить бесконечные фильтры без необходимости;
- проверить, не создают ли плагины собственные архивы и endpoints;
- следить за тем, чтобы закрытые страницы не попадали во внутренний поиск;
- не использовать сомнительные плагины, которые обещают «полную SEO-автоматизацию», но ломают canonical и robots.
Если нужен более быстрый способ навести порядок в дублях и служебных URL, иногда проще собрать это в одном SEO-инструменте, чем править разрозненные куски темы. Например, у Clearfy Pro есть функции для удаления дублей и технической чистки сайта: https://wpshop.ru/plugins/clearfy. Но даже с плагином все равно нужно проверять итоговый HTML и карту сайта вручную.
Если после правок дубли продолжают появляться, ищите не в мета-тегах, а в генерации URL: шаблоны архива, фильтры, внутренний поиск, параметры сортировки и настройки SEO-плагина. Именно там обычно и прячется причина.