Как закрыть от индексации страницы с параметрами в WordPress без потери нужных URL

Проблема обычно выглядит одинаково: в поиске начинают появляться десятки почти одинаковых URL с параметрами, а в отчётах по сканированию растёт мусор вроде ?utm_source=, ?replytocom=, ?sort= или служебных параметров фильтра. Для WordPress это особенно заметно на контентных сайтах, где ссылки раздаются из рассылок, рекламных кампаний, кнопок шаринга и фильтров в шаблоне.

Если просто закрыть всё подряд в robots.txt, можно случайно скрыть нужные страницы от обхода, но не убрать уже известные дубли из индекса. Если, наоборот, полагаться только на canonical, поисковик может продолжать тратить краулинговый бюджет на бесполезные варианты URL. Ниже — рабочая схема, где сначала отделяем безопасные параметры, потом закрываем служебные страницы от индексации, а затем проверяем, что важные адреса остались доступны.

Когда это действительно проблема

Сценарий стоит разбирать, если у вас есть хотя бы один из признаков:

• в Google Search Console появляются URL с параметрами, которые не должны ранжироваться;
• одна и та же статья открывается с разными параметрами, а в индексе видны копии;
• страницы фильтрации или сортировки создают много почти одинаковых адресов;
• в логах или аналитике видно, что боты регулярно ходят по бесполезным вариантам URL;
• после рекламных кампаний в индекс попадают страницы с utm_*.

Что не стоит делать сразу

Не начинайте с массового удаления параметров на уровне сервера, если не уверены, какие из них используются шаблоном, плагином или сторонним сервисом. В WordPress один и тот же параметр может быть служебным для формы, AJAX-запроса или страницы поиска. Сначала нужно понять, какие URL реально индексируются и какие из них должны остаться доступными.

Диагностика: какие параметры попали в индекс

Начните с простого списка. Откройте Search Console, отчёт по страницам и посмотрите, какие варианты URL система считает отдельными страницами. Параллельно проверьте серверные логи или хотя бы аналитику переходов: если бот регулярно запрашивает одинаковый контент с разными параметрами, это уже кандидат на закрытие.

Полезно отдельно выписать параметры по типам:

• маркетинговые — utm_source, utm_medium, utm_campaign;
• служебные — replytocom, fbclid, gclid;
• контентные — sort, filter, page, view;
• опасные для индекса — параметры, которые меняют только представление, но не смысл страницы.

Если параметр меняет содержимое страницы по сути, например показывает другой набор материалов, его нельзя закрывать автоматически без проверки. Для таких случаев лучше решать задачу canonical, пагинацией или отдельной логикой индексации.

Пошаговое решение

1. Закрываем служебные параметры от индексации через noindex

Для страниц с параметрами, которые не должны попадать в индекс, самый предсказуемый вариант — отдавать noindex,follow. В WordPress это можно сделать точечно через wp_robots, не ломая остальные страницы сайта.

<?php
add_filter('wp_robots', function (array $robots) {
    $blocked_params = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'replytocom', 'fbclid', 'gclid'];

    foreach ($blocked_params as $param) {
        if (isset($_GET[$param])) {
            $robots['noindex'] = true;
            $robots['follow'] = true;
            break;
        }
    }

    return $robots;
});

Этот вариант удобен тем, что не требует правок шаблона для каждой темы. Но он работает только если страница действительно отдается через WordPress и вы не перехватываете robots на уровне CDN или сервера.

2. Убираем мусорные параметры из canonical

Если canonical на странице уже содержит текущий URL с параметрами, поисковик может воспринимать их как отдельные варианты. Нужно нормализовать адрес и оставлять только базовый URL без маркетинговых хвостов.

<?php
add_filter('get_canonical_url', function ($canonical, $post) {
    if (!is_string($canonical) || empty($_GET)) {
        return $canonical;
    }

    $remove = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'replytocom'];
    $clean_url = remove_query_arg($remove, $canonical);

    return $clean_url;
}, 10, 2);

Важно: не вырезайте все параметры подряд. Если у вас есть рабочие фильтры или сортировка, canonical должен отражать вашу логику, а не просто обнулять всё до главной страницы.

3. Для служебных URL используем редирект, если параметр не нужен

Если параметр вообще не должен существовать в публичном URL, лучше не закрывать его от индексации, а убрать через 301-редирект. Это особенно полезно для старых рекламных ссылок или устаревших форматов адресов.

<?php
add_action('template_redirect', function () {
    if (isset($_GET['replytocom']) && is_singular()) {
        wp_safe_redirect(remove_query_arg('replytocom'), 301);
        exit;
    }
});

Такой редирект стоит применять только там, где параметр не влияет на содержимое страницы. Для UTM-меток редирект обычно не нужен: они нужны аналитике, а не пользователю.

4. Если фильтры нужны пользователю, решаем отдельно

На каталогах, архивах и страницах подбора контента параметры сортировки и фильтрации могут быть полезны. В этом случае не закрывайте их автоматически, пока не определите, какие комбинации реально должны индексироваться. Часто достаточно:

• оставить в индексе только базовую страницу;
• для фильтров поставить noindex,follow;
• canonical вести на чистую категорию;
• закрыть от индекса только служебные комбинации.

Если фильтр создаёт отдельную ценную посадочную страницу, лучше делать её отдельным URL, а не параметром. Тогда управление индексацией будет проще и предсказуемее.

Сравнение подходов

Подход	Когда подходит	Минус
noindex через wp_robots	Маркетинговые и служебные параметры	Не убирает URL из обхода сразу
Canonical без параметров	Дубли одной и той же страницы	Не всегда достаточно для мусорных URL
301-редирект	Устаревшие или лишние параметры	Нельзя применять к полезным меткам и фильтрам

Проверка результата после внедрения

После правок не ограничивайтесь визуальной проверкой страницы. Откройте несколько URL с параметрами и проверьте исходный код:

• в <meta name="robots" должен появляться noindex там, где это нужно;
• canonical должен вести на чистый URL без лишних параметров;
• редирект должен отдавать 301, а не 302;
• страницы без параметров должны остаться индексируемыми.

Дополнительно проверьте ответ сервера через curl или DevTools. Например:

curl -I "https://example.com/article/?utm_source=test"

В ответе вы должны увидеть либо корректный canonical в HTML, либо редирект на чистый URL, если вы выбрали этот путь. После этого отправьте важные страницы на повторную проверку в Search Console и отслеживайте, как меняется список обнаруженных URL.

Частые ошибки и как их исправить

Закрыли всё через robots.txt

Это частая ошибка: URL перестаёт сканироваться, но уже известные варианты могут остаться в индексе без нормального сигнала для удаления. Для индексации важнее noindex, canonical и редирект, а не только запрет обхода.

Сломали рабочие параметры

Если вы вырезали все query-параметры без разбора, могли задеть поиск по сайту, пагинацию, фильтры или технические запросы плагинов. Исправление одно: составить белый список параметров, которые должны сохраняться, и закрывать только мусорные.

Поставили canonical на главную

Так делать не стоит, если страница не является дублем главной. Canonical должен указывать на наиболее близкую каноническую версию того же контента, а не на произвольный URL.

Использовали 301 там, где нужен только noindex

Если параметр нужен для аналитики, рекламы или временной навигации, редирект может мешать работе внешних систем. В таких случаях лучше оставить URL доступным, но закрыть его от индексации.

Чек-лист перед публикацией правок

• Список параметров разделён на служебные, маркетинговые и контентные.
• Для мусорных URL настроен noindex,follow.
• Canonical очищен от лишних параметров.
• Ненужные старые параметры отдают 301-редирект.
• Полезные фильтры и сортировка не сломаны.
• Проверка в браузере и через curl подтверждает нужный ответ.
• В Search Console отслеживаются новые варианты URL после изменений.

Что учесть по безопасности и производительности

Не храните логику фильтрации параметров в случайном сниппете без контроля версий. Лучше вынести код в дочернюю тему или небольшой mu-plugin, чтобы он не исчез после обновления темы. Если сайт большой, не делайте тяжёлую обработку на каждом запросе: проверка $_GET и фильтр wp_robots должны оставаться лёгкими.

Если задача шире и у вас одновременно есть дубли, лишние архивы и мусорные страницы, иногда проще собрать это в одном SEO-инструменте. Например, в Clearfy Pro есть блоки для управления дублями и технической чистки сайта: https://wpshop.ru/plugins/clearfy. Но даже с плагином полезно понимать, какие именно URL вы закрываете и почему.

Если нужен следующий шаг, логично отдельно разобрать, как настроить индексацию архивов, пагинации и страниц поиска так, чтобы не плодить дубли уже на уровне шаблона.