Главная/SEO/utm_referrer, ysclid и yclid: как проверить метки после установки антибота

utm_referrer, ysclid и yclid: как проверить метки после установки антибота

ВВиталий ГротОпубликовано 5 октября 20266 мин7 703 знаков
Схема сохранения параметров перехода: исходный URL, редиректы и конечная страница

После установки защиты визиты могут сменить источник в аналитике, а доля прямых заходов — вырасти. До усиления блокировок проверьте, сохраняются ли параметры utm_referrer, ysclid и yclid при редиректах и прохождении проверки.

Сначала проверьте путь визита

Человек переходит из поиска, проходит проверку и видит страницу. Между первым кликом и загрузкой счётчика могут оказаться несколько ответов сервера: переход на HTTPS, смена домена, нормализация слеша, страница защиты и редирект CMS. Если на одном из этапов пропадает информация об источнике, отчёт уже не описывает исходный переход так, как вы ожидали.

23 декабря 2025 года разработчик AntiBot.Cloud рекомендовал проверять utm_referrer, ysclid и yclid на всех типах URL. По его сообщению, удаление этих параметров и потеря реферера при анти-DDoS-проверке могут сопровождаться проблемами с отчётами Метрики. Рекомендация разработчика

Это диагностическая гипотеза. Высокая роботность или рост отказов сами по себе не доказывают, что сайт удаляет метки. Чтобы подтвердить проблему, нужно увидеть изменение конкретного запроса.

Что сравнивать

ЭлементДля чего нужен в этой проверкеГде смотреть
utm_referrerРазработчик рекомендует проверять его при установленном AntiBot.CloudАдрес до и после проверки, цепочка редиректов
ysclidПараметр, который может сопровождать переход из ЯндексаИсходная ссылка и конечный URL
yclidПараметр, встречающийся в переходах из рекламы ЯндексаИсходная ссылка и конечный URL
HTTP RefererЗаголовок запроса с информацией о предыдущей странице, если браузер его передалNetwork в браузере и access log
CanonicalУказание предпочтительного URL для поисковикаHTML конечной страницы

Параметр в адресе и HTTP-заголовок — разные поля. Наличие utm_referrer не означает, что браузер передал Referer, а отсутствие Referer не объясняется автоматически потерей параметра.

Какие страницы включить в проверку

Выберите по одному представителю каждого шаблона:

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

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

Начните с известного перехода из поиска или рекламы. Для технической проверки отдельно можно добавить к тестовому адресу условные значения. Они проверяют передачу строки, но не воспроизводят настоящий рекламный клик или поведение Метрики.

Пример условного адреса:

https://example.com/catalog/item?ysclid=diagnostic&yclid=diagnostic

Значения diagnostic вымышлены. Такой тест отвечает на вопрос «сохраняется ли параметр», а не на вопрос «как сервис атрибутирует реальный визит».

Как найти этап, на котором пропадают параметры

  1. Откройте DevTools → Network и включите сохранение журнала при переходах, обычно Preserve log.
  2. Перейдите по выбранной ссылке в чистой сессии браузера, чтобы увидеть первое прохождение защиты.
  3. Найдите первый запрос документа и его исходный URL.
  4. Для каждого ответа 3xx сравните заголовок Location с предыдущим адресом.
  5. Пройдите обычную проверку и сравните конечный URL с исходным.
  6. Посмотрите, на какой странице загружается счётчик и какие данные доступны к этому моменту.

Не ограничивайтесь адресной строкой. Промежуточный редирект может потерять параметр, а последующая загрузка — вернуть похожую строку. Журнал показывает каждый шаг.

Где исчез параметрЧто проверять
При HTTP → HTTPSПравило перенаправления и передачу query string
При переходе www → без wwwПравило смены домена
При нормализации слешаНастройки веб-сервера или CMS
После страницы проверкиКонфигурацию защиты и обработку возврата на исходный URL
На одном типе страницЕго маршрутизатор, SEO-плагин и обработчик запроса

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

Почему рост прямых заходов ещё не означает атаку

В ноябре 2023 года разработчик разбирал сайт, на котором после установки защиты оставались прямые заходы и высокая доля отказов. По его описанию, на части страниц CMS обрезала дополнительные GET-параметры, в том числе utm_referrer и ysclid. Описание случая

Этот случай показывает, где искать ошибку. Он не доказывает, что удаление ysclid всегда превращает визит в отказ: в сообщении это было предположением автора по результатам разбора.

Проверьте отдельно три результата:

  • дошёл ли посетитель до содержимого;
  • сохранились ли данные перехода;
  • изменились ли заявки и другие действия на сайте.

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

Canonical и удаление параметров решают разные задачи

Чтобы указать предпочтительный URL страницы, используют rel="canonical". В документации Google это сильный сигнал выбора канонической версии, а не гарантия её выбора. Элемент не перенаправляет браузер сам по себе. Документация Google

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

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

Если метки сохраняются, а отказы остаются

Проверьте соответствие запроса странице. 24 декабря 2025 года разработчик напоминал: причиной отказа может быть нецелевой трафик, которому страница не отвечает на вопрос. Сообщение о качестве трафика

Например, посетитель ищет инструкцию по применению товара, а попадает на карточку с ценой и кнопкой покупки. Защита может корректно пропустить человека, но его задача останется нерешённой. Дополнительная капча это не исправит.

Также изучите исключения ALLOW. Разрешённые полезные боты, которые исполняют JavaScript, могут оставаться в отчётах аналитики. Комментарий разработчика

Что зафиксировать после исправления

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

Изменение источников сразу после исправления ещё не доказывает рост или падение спроса. Сначала установите, что изменился способ измерения. Сопоставляйте отчёты за сравнимые периоды и учитывайте реальное число заявок. Более общий разбор — трафик после установки антибота.

Сохраняйте данные, необходимые конкретному сценарию. Не удаляйте неизвестные параметры без разбора их назначения; для проверки выберите разные типы страниц.

Нет. Потеря параметра — установленная техническая проблема, если вы увидели её в запросе. Её влияние на отчёт и причины отказов проверяют отдельно.

Нет. Вымышленное значение позволяет проверить передачу параметра через редиректы, но не воспроизводит атрибуцию настоящего клика.

Нет. Элемент сообщает поисковику предпочтительный адрес. Удаление меток из адресной строки выполняется другими механизмами.