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

конечно же лезет, только успевай подставлять

тогда это просто нету канона)) то есть не использование

Но на канонической-то он есть. Наверное, это какое-то своеобразное использование. 😊 Это я и назвал "сильно недоделанным canonical".

Я прочитал ваш тред)) Антоний просто не так выразился, а потом поправился 

все же понимают что на канонической канон не нужен вообще)) главное что бы на дублях он был

Но он абсолютно допустим. Кроме того, это самая простая реализация для естественных дублей.

После участия в этом обсуждении я уже не знаю, кто что понимает. 😊 Спокойной ночи.

конечно, и по этому его всегда и делают 

на самом деле и вы и Антоний все понимаете одинаково

Совершенно верно.

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

А вот возможные дубли и служебные страницы для индекса не нужны и тег canonical может не содержаться вообще, поэтому мы запрещаем их для индексации, не включаем их в формирование XML карты, следовательно, не создаем себе лишнего объёма работ. 

Вот в том то и дело, что необязательно :) 

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

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

Но. Всё это довольно пустые разговоры в попытках расширить смыслы по конструкции используемых фраз.

По-настоящему важно другое,

Сlean-param способен снижать нагрузку на переобход страниц, так как робот физически не будет видеть адреса по мусорным get параметрам, тогда как правило по canonical фиксируется поисковым роботом подокументно, а значить робот должен каждый мусорный get параметр загрузить и уже потом алгоритм примет решение - брать его в индекс как важный или выбросить из индекса как неканоническую страницу.

И это конкретно указано в справке,

источник

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

Я опирался на то предложение, в котором вы написали, что он есть. 😊

Я с этим спорил? Я написал, что не использую Clean-param за ненадобностью. Т.е. вполне успешно обхожусь без него.

Вы там зачем-то разделили "отдельные страницы" и "группы адресов". Я написал, что мне это непонятно. Почему для "групп адресов" не подходит noindex и т.п. Из-за повышенной нагрузки при обходе? Бывают случаи, когда в роботс что-либо писать уже поздно. А если все предусмотрено заранее, то при использовании соответствующей адресации "группы адресов" можно закрывать от сканирования более простым и универсальным способом: [Disallow:] /collection/, /search/, etc.

Предлагаю прекратить этот пустой разговор. По крайней мере со мной.

Спасибо огромное, действительно для Drupal помог токен [current-page:url-with-query:with-some-parameters:page], он убирает все лишние параметры из адреса пагинации, оставляет только page.

Еще обратите внимание на то, в каком шаблоне используется этот "токен". Если в общем для разных типов страниц, то он будет пропускать параметр page даже для тех страниц, где данный параметр совершенно не нужен (в адресе канонической). Например, если отдельные статьи выводятся по адресам вида /articles/<number or slug>, то при запросах по адресам /articles/<number or slug>?page=<N> такие адреса (со строкой запроса page=<N>) не должны появляться в теге canonical.