День поиска: как я решил проблему дублей из-за сессий

Есть интересный проект - интернет-магазин зоотоваров «ЗвероМир». Вкратце, запустили продвижение по товарным запросам типа «сухой корм для кошек». И тут в Яндекс.Вебмастере я увидел тревожную картину: сотни проиндексированных URL с непонятными символами, например: /catalog/korm-dlya-koshek?utm_session=9jh863578. Позиции по основным страницам начали «прыгать», а в отчёте «Страницы в поиске» царил хаос. Я потратил целый день, чтобы докопаться до причины: дубли из-за параметров сессий. А решение, как часто бывает, оказалось на поверхности, но чтобы его найти, пришлось пройти через дебри.

Cайт, который «размножается» в глазах робота

Всё началось с того, что в Яндекс.Вебмастере в разделе «Диагностика» -> «Анализ ответа сервера» начали появляться ошибки. Робот жаловался, что не может получить доступ ко многим страницам. При этом в разделе «Индексирование» -> «Страницы в поиске» количество проиндексированных URL зашкаливало и в разы превышало реальное число страниц на сайте.

Я начал проверять эти странные адреса. Они выглядели так:

/catalog/korm-dlya-koshek?**utm_session=7f8g9h0j

/catalog/korm-dlya-sobak?**sid=k1l2m3n4

/catalog/igrushki-dlya-koshek?**phpsessid=o5p6q7r8

Это были параметры сессий (utm_session, sid, phpsessid). Они добавляются к URL, когда пользователь заходит на сайт, чтобы система могла «помнить» его (например, что положил в корзину). Для каждого нового посетителя генерируется уникальный набор символов. И каждый раз, когда робот Яндекса или Google заходил на сайт под видом нового пользователя, он получал новый, уникальный URL с этими параметрами. В итоге, вместо одной страницы «корм для кошек» в индексе могло оказаться десятки её копий с разными phpsessid.

Почему это опасно для SEO?

Последствия такого «размножения» страниц катастрофичны:

• «Распыление» ссылочного веса. Все внутренние и внешние ссылки, ведущие на каталог, делились между десятками дублей, а не концентрировались на одной канонической странице. Это лишало её сил для борьбы в топе.
• Дублированный контент. Поисковик видел сотни страниц с одинаковым содержимым (каталогом кормов). Он не понимал, какую из них считать главной, и мог выбрать для показа в выдаче не ту, которую мы продвигаем, а случайный дубль с параметром сессии.
• Санкции за неуникальный контент. Поисковые системы не любят, когда на одном сайте много одинаковых страниц. Это могло привести к пессимизации всего сайта в выдаче.
• Пустая трафика краулингового бюджета. Робот тратил ограниченное время на обход одних и тех же страниц с разными параметрами, вместо того чтобы индексировать новые, полезные разделы.

Диагностика

Сначала я подумал, что проблема в CMS (на «1С-Битрикс»). Но потом, покопавшись в настройках и пообщавшись с разработчиком, выяснил, что это самописный функционал сессий, написанный когда-то для отслеживания источников трафика.

Мой день ушёл на:

1. Поиск в Google по запросам «дубли страниц из-за сессий», «как убрать phpsessid из URL».
2. Изучение логики работы сессий на этом конкретном сайте.
3. Проверку, не передаются ли эти параметры через внутренние ссылки (оказалось, что да, в некоторых местах).

Анализ файла robots.txt и nginx.conf (конфигурация сервера), чтобы понять, как с этим бороться.

Решение - 2 простых шага, которые всё исправили

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

Шаг 1. Запрет индексации URL с параметрами сессий через robots.txt.

В файл robots.txt мы добавили правила, явно запрещающие индексацию любых URL, содержащих определённые параметры. Это директива для роботов:

User-agent: *
Disallow: /*?utm_session
Disallow: /*?sid
Disallow: /*?phpsessid
Важно: Это не удаляет уже проиндексированные дубли, но предотвращает их попадание в индекс в будущем. Робот, увидев такой URL, просто не станет его индексировать.

Шаг 2 (и главный). Настройка канонических тегов (rel=»canonical»).

Это была основная работа. Мы на уровне кода сайта настроили, чтобы на каждой странице, к URL которой были добавлены параметры сессий, в секции <head> автоматически прописывался канонический тег, ведущий на чистую, основную версию страницы.

Например, для страницы /catalog/korm-dlya-koshek?phpsessid=o5p6q7r8 в код добавилась строчка:

html
<link rel=»canonical» href=»/catalog/korm-dlya-koshek» /> (только полный путь).
Что это даёт? Это явный сигнал поисковому роботу: «Да, здесь есть страница с параметрами, но её главная, оригинальная версия - вот эта. Всё ссылочное ранжирование и контент относи сюда». Это самый корректный и рекомендуемый способ борьбы с техническими дублями.

Результаты

Через несколько дней после внедрения изменений ситуация начала выправляться:

1. В Вебмастерах Яндекса и Google количество ошибок и странных URL пошло на убыль.
2. График проиндексированных страниц стал приходить в норму, уменьшаясь до реального числа.
3. Позиции по товарным запросам стабилизировались и пошли вверх.
4. Ссылочный вес перестал «распыляться» и сконцентрировался на целевых страницах.

Главный урок

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

Теперь «проверка на дубли» - это не просто пункт в аудите. Это отдельная, глубокая процедура, где я специально ищу:

1. Параметры сессий (sid, phpsessid, utm_session).
2. Параметры сортировки и фильтрации (?sort=price, ?filter=color).
3. Версии для печати (?print=yes).
4. HTTP и HTTPS версии (если не настроены редиректы 301).

И для каждого такого случая теперь знаю «протокол лечения»: robots.txt для запрета + rel=»canonical» для указания главной версии. Потому что иногда один день, потраченный на решение такой «простой» проблемы, стоит месяцев работы по наращиванию ссылок.