Как правильно бороться с мусорными параметрами в URL

Да, немного не красиво вышло.

[OFFTOP]Да, некрасиво. Но кто провокатор? 😊 Я тоже удивился, как на таком ровном месте можно так разойтись. 😊[/OFFTOP]

Если формировать каноникал, то нужно брать не приходящий урл,  а тот, который оригинальный на эту страницу. В движке он где-то должен быть на странице. Но это уже нужно код смотреть, а простыми настройками не обойдешься.

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

Все верно. Я об этом писал в теме. Хотя в шаблоне уже больше шансов "обойтись простыми настройками", т.к. основной этап обработки запроса уже пройден, все лишнее отсечено.

В принципе можно фильтровать адрес из текущего запроса, приводя его к каноническому. Но зачем такие сложности, когда можно сразу сформировать канонический, используя средства "движка"?!

Так вы делаете попытку публичных извинений за написанную фразу или сами себя извиняете?

Приношу свои извинения

Извинения приняты.

Я сильно сомневаюсь, что это всегда лучше. Если речь не о сокрытии UTM-меток и т.п. (их переносе в куки и т.п.) и не о последствиях того, что параметры когда-то поддерживались, а теперь нет, то делать переадресацию из-за любого мусора в query string - это лишнее. В обычных условиях рекомендуют делать переадресацию только для коррекции "тайпина" пользователя, например лишних (или недостающих) завершающих слэшей (часто это касается только путей), неверного регистра букв и т.п. Иногда путем переадресации убирают завершающие знаки препинания, амперсэнды и т.п., но я, например, этого не делаю. Даже /path? не корректирую.

Это как так правильные? Он либо на себя либо не на себя. Третьего нет

Антоний описал третий вариант: использование canonical без размещения canonical на дублях канонической. 😊