Формирование адресной строки компонентом bitrix:catalog.element

Оказывается, это относительно нормальная/распространенная ситуация. Но мешает SEOшникам.

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

Алексей, элемент однозначно относится к определенному разделу (к нескольким сразу может относиться только на разных уровнях). Т.е. путь определить однозначно можно.
Требуется сделать так, чтобы элемент был доступен только по одному единственному правильному адресу. А по любому другому произвольному (как это есть сейчас) - чтобы не был.

Алексей, адрес у элемента один. Но. Часть пути строится компонентом catalog.section., затем сам элемент выводится компнентом catalog.element. При выдаче описания самого элемента учитывается только символьный код самого элемента. А пусть, построенные catalog.section не учитывается. Его можно безболезненно удалить, заменить на любую комбинацию символов и т.п.
На сайте кривых ссылок нет. Если идти по сайту-по дереву- получается нормальный адрес. А если вручную забить вот такой измененный - при условии что www.site.ru/razdel/ есть в начале и корректно указан символьный код элемента - элемент будет отображен. Оптимизаторы это нашли и ругаются - получается бесконечное дублирование контента.
Нужно сделать так, чтобы по придуманному адресу элемент не выводился. А выводился только по правильному.
ЗЫ. это динамически формируемые разделы.

Это понятно. Просто мне показалось, что ваши оптимизаторы продвигают сайт в поисковых системах, и озабочены, чтобы поисковые системы видели правильные ссылки, которые влияют на рейтинг страниц.
А, разве поисковые ситемы не по меню сайта ходят и не по ссылкам, сгенерированным на сайте?
Поисковые же системы руками ссылки не перебирают, из головы их не выдумывают, а значит и дублированного контента увидеть не могут. Нет? Не очень понятно, почему эта задача попала в разряд сеошных, т.е. озаботила сеошников настолько, что они хотят, чтобы это исправили. Им не всё ли равно?

к сожалению, замеченная ситуация есть почти на 80% сайтах под битриксом в случае использования чпу. ссылки неверные получаются путем либо перемещения/удаления каког-то элемента, либо случайными ошибками посетителей, а гугл и яндекс их запоминают. проверено не на 1 сайте.
как я обходил: у меня структура была четкая и 1 элемент лежал в 1 раделе - получал путь в виде строки или массива (не всегда работает) разбивал на составляющие и проверял у раздела элемента id(символьный код ) совпадает или нет. если нет выводил глобальную ошибку и ставил статус 404

так и нужно получить адресную строку
например такое занчение:

далее


у тебя уже готовый массив осталось сравить $arResult['SECTION_ID'] и скажем $arrurl[4] - совпадают хорошо нет ставим статус 404

Итого. Получилось. Делюсь опытом (отладочные сообщения разумеется комментируются):
//получаем текущую адресную строку браузера

$cur_page = $APPLICATION->GetCurPage();
echo "Адресная строка_элемент: ", $cur_page;

//получаем код текущего элемента
$element_id = CIBlockSection::GetList(null, Array('ELEMENT_CODE' => $arElement["CODE"] , false , false);
//echo "<pre>"; print_r($arResult['CODE'] ; echo "</pre>";

//получаем ID родительского раздела текущего элемента
$nav = CIBlockElement::GetElementGroups($arResult['ID'], false);
//echo "<br/>"; echo "<Text>Длина нава</Text>";
//echo $nav->SelectedRowsCount();

//получаем структуру родительских разделов до определенного в предыдущем пункте раздела
$SectionID = 0;
if ($ar_group = $nav->Fetch()) $SectionID = $ar_group['ID'];

$navChain = CIBlockSection::GetNavChain(13, $SectionID);

$realNavChain = "";
while ($arNav=$navChain->GetNext()):
  //echo "<pre>"; print_r($arNav); echo "</pre>";
  //echo $arNav['CODE'];
  //echo '/';

//убираем лишнее из символьного кода элемента (из подраздел-1/подраздел1-1 оставляем подраздел1-1)
 $arrurl = explode("/", $arNav['CODE'] ;
 $arrlast = end($arrurl);
 //echo $arrlast;
//приводим правильный адрес страницы к приличному виду:
 $realNavChain = $realNavChain.$arrlast."/";
endwhile;
  $realNavChain_full = "/what_teach/".$realNavChain.$arResult['CODE'];
  $path = $arNav['CODE'];
  //echo $path;
  echo "Реальная адресная строка_элемент: ".$realNavChain_full;
//проверка на совпадение адресов:
if ($cur_page==$realNavChain_full) { //если "да" - выводим чего нам там надо } else {выводим 404 ошибку}

Ну да. Поэтому через одно место
В админке же хранится структура, какая должна быть.
Поэтому мы определяем текущий элемент - символьный код (он уникален для каждого элемента, как и ID, но в адресной строке у меня используется символьный код).
Для этого элемента вытаскиваю его родительский подраздел (в твоем примере - подраздел 1-1-1)
Потом для полученного подраздела выстраиваю дерево разделов (GetNavChain работает для разделов, не для элементов).

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