Кейс: как убрали 404 для UTM и других GET-параметров на ЧПУ-страницах

← Кейсы

На сайте с ЧПУ обычная страница открывалась корректно, но тот же URL с рекламной меткой или произвольным GET-параметром возвращал 404. Это означало, что ссылка из рекламы, аналитики или внешнего сервиса могла вести на несуществующую страницу, хотя сам документ на сайте был.

Кейс устранения 404 при GET-параметрах на ЧПУ-страницах

Симптом

Адрес без параметров работал:

/articles/example/

Но при добавлении метки:

/articles/example/?utm_source=test

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

Почему это критично

UTM, yclid и другие GET-параметры часто добавляются рекламными системами, аналитикой и партнёрскими сервисами. Если сайт воспринимает каждый такой URL как отдельный неправильный маршрут, рекламный трафик теряется, а поисковые и аналитические данные становятся недостоверными.

Где искали причину

Проверили правила ЧПУ, urlrewrite.php, собственный роутер и условие, по которому определялась текущая страница. Оказалось, что часть логики сравнивала адрес запроса целиком, вместе со строкой параметров, вместо использования только пути.

Что изменили

Маршрутизацию перевели на анализ pathname без query string. GET-параметры остались доступны приложению через обычные механизмы PHP, но больше не участвовали в определении существования страницы.

Отдельно проверили, чтобы исправление не ломало canonical и не создавало новые ЧПУ-дубли.

Какие сценарии протестировали

обычный URL без параметров;
URL с ?test=1;
UTM-метки;
yclid и рекламные идентификаторы;
несколько параметров одновременно;
реально несуществующий URL — он по-прежнему должен отдавать 404.

Почему нельзя просто отключить 404

Иногда проблему пытаются решить универсальным fallback, который отдаёт успешную страницу почти для любого адреса. Это опасно: поисковик начинает видеть soft 404 и множество мусорных URL. Правильное решение — игнорировать query string при маршрутизации, но сохранять честный 404 для несуществующего пути.

GET-параметры должны менять данные запроса, а не само существование ЧПУ-страницы, если бизнес-логика явно не требует обратного.

Результат

После изменения логики страницы стали одинаково открываться с рекламными и аналитическими параметрами. Реальные ошибки маршрута продолжили возвращать 404, а canonical остался привязан к чистому адресу страницы.

Вывод

Проблема находилась не в Битрикс как таковом, а в собственном слое маршрутизации. Поэтому при нестандартном ЧПУ важно тестировать не только «чистые» URL, но и реальные ссылки, которые приходят из рекламы, поиска, мессенджеров и аналитических систем.

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