Добрый день! На сайте есть перечень элементов с описанием, разложенных тематически по папочкам. Например, по адресу www.site.ru/razdel/level1/level2/level3/level4/element можно просмотреть описание нужного нам элемента. А по адресу, например, www.site.ru/razdel/level1-1/level2-1/level3-1/element-1 можно просмотреть описание другого элемента. С помощью дорогих наших SEO обнаружили, что нашему сайту совершенно наплевать, что у нас написано в качестве этих level. Можно любой из этих level4, level2-1 и т.д. заменить любым набором символов, можно вообще удалить. Главное, чтобы осталось www.site.ru/razdel/ и символьный код нужного элемента. Элемент выводит компонент bitrix:catalog.element
Возникает вопрос - смысл тогда вообще строить эту логическую цепочку каталога? И как сделать так, чтобы смысл все-таки был (чтобы анализировался весь указанный путь, а не только конечный элемент)?
Оказывается, это относительно нормальная/распространенная ситуация. Но мешает SEOшникам.
В качестве решения есть предложение для вызываемого элемента определять путь, по которому он должен быть вызван (правильная последовательность левелов для элемента) и сравнивать с запросом в адресной строке. Пока второй шаг проблемы - определить правильную последовательность родительских элементов для нужного элемента.
X-Lady пишет: Пока второй шаг проблемы - определить правильную последовательность родительских элементов для нужного элемента.
Думаю, правильной не существует, т.к. нужный элемент может быть одновременно привязан к разным родительским разделам, и не известно в каком разделе этот элемент будет больше нужен и востребован.
Цитата
X-Lady пишет: Возникает вопрос - смысл тогда вообще строить эту логическую цепочку каталога?
Это политический вопрос, а не вопрос логики и понимания разработчика. Людям путь в баузере вообще не нужен, им в сто раз важнее то, что написано в цепочке навигации на странице элемента. Сколько раз SEOшникам придёт в голову переделывать, столько и будете переделывать, т.к. в этом нет окончательной твёрдой всем понятной логики, а только частные мнения.
Вообще, сейчас идёт тенденция сокращать путь url до самого минимума, как для удобства публикации в твиттере, а не делать его как можно подробнее и длиннее. Подробность в url - это пройденный этап, на мой взгляд, но у разных людей разное мнение.
Алексей, элемент однозначно относится к определенному разделу (к нескольким сразу может относиться только на разных уровнях). Т.е. путь определить однозначно можно. Требуется сделать так, чтобы элемент был доступен только по одному единственному правильному адресу. А по любому другому произвольному (как это есть сейчас) - чтобы не был.
X-Lady пишет: Требуется сделать так, чтобы элемент был доступен только по одному единственному правильному адресу. А по любому другому произвольному (как это есть сейчас) - чтобы не был.
Не совсем понятно. У Вас на сайте у элемента есть несколько адресов, а Вы хотите сделать его доступным только по одному адресу. Или у Вас на сайте и так только один адрес и есть, а Вы считаете, что поисковая машина начнёт выдумывать сама новые адреса и проверять их работоспособность на Вашем сайте и хотите запретить поиковику делать такой перебор адресо. Но, поисковики же не занимаются подбором url, они их берут из явных ссылок.
Алексей, адрес у элемента один. Но. Часть пути строится компонентом catalog.section., затем сам элемент выводится компнентом catalog.element. При выдаче описания самого элемента учитывается только символьный код самого элемента. А пусть, построенные catalog.section не учитывается. Его можно безболезненно удалить, заменить на любую комбинацию символов и т.п. На сайте кривых ссылок нет. Если идти по сайту-по дереву- получается нормальный адрес. А если вручную забить вот такой измененный - при условии что www.site.ru/razdel/ есть в начале и корректно указан символьный код элемента - элемент будет отображен. Оптимизаторы это нашли и ругаются - получается бесконечное дублирование контента. Нужно сделать так, чтобы по придуманному адресу элемент не выводился. А выводился только по правильному. ЗЫ. это динамически формируемые разделы.
X-Lady пишет: Оптимизаторы это нашли и ругаются - получается бесконечное дублирование контента.
Это понятно. Просто мне показалось, что ваши оптимизаторы продвигают сайт в поисковых системах, и озабочены, чтобы поисковые системы видели правильные ссылки, которые влияют на рейтинг страниц.
Цитата
X-Lady пишет: Если идти по сайту-по дереву- получается нормальный адрес. А если вручную забить вот такой измененный...
А, разве поисковые ситемы не по меню сайта ходят и не по ссылкам, сгенерированным на сайте? Поисковые же системы руками ссылки не перебирают, из головы их не выдумывают, а значит и дублированного контента увидеть не могут. Нет? Не очень понятно, почему эта задача попала в разряд сеошных, т.е. озаботила сеошников настолько, что они хотят, чтобы это исправили. Им не всё ли равно?
лично мне кажется - что нет на сайте корявых ссылок - и отстаньте. но видимо умудрились получить как-то - предъявили список ссылок по которым индекс этот поисковый куда-то убегает.
к сожалению, замеченная ситуация есть почти на 80% сайтах под битриксом в случае использования чпу. ссылки неверные получаются путем либо перемещения/удаления каког-то элемента, либо случайными ошибками посетителей, а гугл и яндекс их запоминают. проверено не на 1 сайте. как я обходил: у меня структура была четкая и 1 элемент лежал в 1 раделе - получал путь в виде строки или массива (не всегда работает) разбивал на составляющие и проверял у раздела элемента id(символьный код ) совпадает или нет. если нет выводил глобальную ошибку и ставил статус 404
Код
ShowError("Элемент не найден.");
@define("ERROR_404", "Y");
CHTTP::SetStatus("404 Not Found")
Да, действительно. Я тоже на многих сайтах это встречала. У нас тоже структура четкая, но один элемент может лежать, скажем, в четырех разделах - один в другом.
Можно подробнее, как получить путь? Если говорить о GetCurPage(); - выдает то, что введено в адресной строке. Бесполезная информация, если нет правильного пути, с которым сравнивать.
примерно так. но нужно проверить все уровни (если их 4 - то все 4, если их 2 - то 2). количество уровней не фиксированное - зависит от конкретного случая. пытаюсь получать структуру от корня через
CIBlockElement::GetElementGroups пока без особых успехов
//получаем структуру родительских разделов до определенного в предыдущем пункте раздела $SectionID = 0; if ($ar_group = $nav->Fetch()) $SectionID = $ar_group['ID'];
Ну да. Поэтому через одно место В админке же хранится структура, какая должна быть. Поэтому мы определяем текущий элемент - символьный код (он уникален для каждого элемента, как и ID, но в адресной строке у меня используется символьный код). Для этого элемента вытаскиваю его родительский подраздел (в твоем примере - подраздел 1-1-1) Потом для полученного подраздела выстраиваю дерево разделов (GetNavChain работает для разделов, не для элементов).
Следующие танцы с бубном - это у меня заморочки с этим символьным кодом - он составной. Не знаю какого черта, но видимо так надо зачем-то. Через всю админку так насквозь прописано. Ну и вот. В итоге сочиняем адрес, который считаем правильным. И сравниваем с текущим.
т.е. у тебя получается в первый проход ты сочиняешь такой адрес и устанавливаешь его, а во второй проход делаешь туже проверку, чтобы отсечь случайные(или намеренные) ошибки пользователей?
Не совсем. По сути первым шагом я получаю текущий адрес браузера (правильный/неправильный - пофигу). Вторым шагом - выстраиваю такой адрес, какой считаю правильным. Третьим шагом - тупо сравниваю - совпадают - молодец - показываю страницу, не совпадают - досвидос, 404.
Адрес из второго шага никуда не устанавливается. По идее он и должен быть в адресной строке, если приходить на страничку по ссылкам сайта (переходами по менюхам, из ссылок в новостях, откуда угодно).