ID на ранжирование уж точно не влияет :)
Все верно. Когда базовые технические вопросы решены (даже с допустимой вариативностью в url-ах), главный фокус - это содержание, маркетинг и UX/UI для CJM и решения потребительских задач.
А расчёт (или как предлагает Сергей - "прогон") алиаса по BM25 - это в приоритете задач нюанс сильно второстепенного порядка. Иметь ввиду это не помешает, но рубиться, допустим, за несколько лишних слов в URL (если они там будут) вообще не стоит.
Да, бывает такая специфика товара, где доп. коды выносятся в название.
Где-то нужно и уместно, где-то - избыточная информация.
По обстоятельствам. Долгие споры по вопросу - "нужно или не нужно" довольно бессмысленны.
Символ "_" здесь скорее всего лишний, он не несет функциональной нагрузки.
В CMS-ках и фреймворках много чего есть, но когда ты имеешь дело просто с набором URL-ов, то именно из списка URL-ов тебе необходимо выполнять выборки.
Здесь верно, только "не прогоняется", а рассчитываются.
Лишнего здесь ничего нет.
В чём твой корень несогласия? В том, чтобы в товарном алиасе вместо транслитерации названия и ID был просто ID?
Что значит непостоянная? Выполнили импорт из 1C, конкретному товару назначился ID, дальше он указывает на уникальный объект и используется как уникальная метка в URL-е. ID у него не меняется (вручную он не исправляется).
ID - уникальный признак объекта. Априори он неизменный.
Но бывает. Например, два визуально и технологически идентичных товара. Разница - производитель и цена.
Получается. По названию и хар-ким всё идентично, кроме производителя.
Часто бывает в какой-нибудь метизной продукции.
Я сталкивался и не раз.
Как сказал выше, могут быть два абсолютно одинаковых товара.
А бывает вообще один и тот же товар, но в зависимости от поставщика и времени закупки цена другая.
В общем бывает много занятные случаев, поэтому id снимает проблему.
Для задания уникальности токена (и соот-но результирующего url-а).
Названия товаров могут полностью дублироваться.
Лучше -> название + id т.е. /nazvanie-tovara_id/
Это нагляднее, понятнее, в постаналитике даст возможность составлять атрибуции для объединения url-ов в отдельные группы.
Допустим у вас -> /../uglovye/divan-solnichko_23351/
Тогда у вас будет возможность выбрать все диваны solnichko в кластере uglovye.
А если там будет просто цифровая запись, то, соот-но, не будет.
Т.е. название товара может быть критерием рабочей выборки.
Например, у вас появилась задача - вывести сколько раз просматривали страницы с диванами solnichko. У вас будет возможность для такой атрибуции. А если там будут только цифры, то такой возможности не будет, вам придётся вручную сопоставлять название товаров и соответствующие им цифры в id.
Я бы сказал проще:
Категория - это общий хаб с товарами. /smartfony
Листинг - это скорее внутренние страницы фильтров/подкатегорий. Они в основном генерируются через фильтрацию в основной категории. /smartfony?color=white
Ммм... чем больше сущностей, тем больше разночтений из-за разного понимания определений.
Для меня хаб - это скорее корневой раздел, который ключевым образом объединяет важные рабочие элементы.
В этом смысле хабом я назвал бы раздел Каталог, который включает всю вложенную в него структуру категорий.
и то, полноценным хабом я бы назвал её не по иерархическому старшенству, а только в лучше, если по своему представлению эта будет насыщенная страница, объединяющие разнородные элементы.
Скажем, если мы оставляет только Каталог и смотрим на эту страницу, как на центральный узел,
то - да, можно назвать её хабом, потому что hub и есть "узел".
Дальше. Листинг - это фактический перечень, перечень может быть товарный, может быть категориальный, листингом можно назвать html карту сайта (если все элементы вывести одним уровнем без вложений), листингом могут быть записи в разделе статей/блоге.
Cтруктура сайта - это не про то, что будет выводится на странице, структура сайта - это то, в каком соотношении находятся страницы и объединяющие их категории. Т.е. являются ли они дочерними или сестринскими, на каком уровне вложенности находятся, пересекаются ли они по названиям, как будут реализованы в представлении URL (через вложенность или через последовательности в get параметрах).
Вот с этого тезиса и выбирается решение.
Как уже говорил выше реализации структуры могут быть разные. Для различных обстоятельств - свои более или менее удачные решения.
Да, логика верная. Главное, что вы четко осознаете эти зависимости, а значит сможет сформулировать ТЗ, как и в какой логике формируется результирующий вывод (т.е. какие элементы нижнего уровня должны выводиться).
Да, есть вариации о которых вы сказали, но есть ситуации, где родительский уровень не всегда можно однозначно определить, он в контексте может быть и таким, и другим, и третьи, и здесь приходится на отдельный объект назначать свои признаки и вопрос привязки в URL для определения канонического адреса должен быть однозначен.
Можно выбрать вариант два, если описанных мною вариантов не будет, структура будет жёсткая и нерасширяемая.
Но как только возникает ситуация, где появляются категории объединяющие в себе разные товары по новому признаку, который раньше не учли, то начинается "мягкий пепец".
Я ещё не видел активно развивающихся бизнесов, которые с самого начала застывали в своём товаром ассортименте и в выбранном варианте структуры. Поэтому лучше сразу заложить принцип, где объектам (товарам) можно определить многовариантые связи с категориями, а не просто жёстко привязать товар к одной категории, которая очевидно предполагается и назначить вложенность.
Пожалуйста 😎
Есть 2 варианта: - отдельная папка под товары "/tovar/stellazh-umka-roziviy" и там лежат все товары - или же в основной категории "/mebel-dlya-doma/stellazhi/stellazh-umka-roziviy"
Как лучше? В моих примерах выше второй вариант, но в целом многие используют первый. ИИ тоже его рекомендует.
Это уже вопрос, который стал классическим, но здесь он неточен. В отдельный раздел Товары нужно размещать не категорию, а уже непосредственно товары, поэтому дальше речь пойдет о товаре, а не о промежуточной категории /stellazh-umka-roziviy/
Лучше - первый. Почему?
Потому что образованных категорий может быть (условно) бесконечно много и категории формируются признаками: по виду, по типу, по способу использования, и т.д. Отсюда следует, что у одного и того же товара множество признаков.
Следовательно, один и тот же товар может попадать в разные категории. Поэтому, если товар прикреплять к каждой категории, то могут возникать перекрёстные дубли т.е. ваш конкретный стеллаж будет находиться и в категории Стеллажи и в других, к которым он будет относится.
Поэтому лучше формировать отдельный раздел Товары (обычно слаг /poduct/) и в него размещать все товары. А самому товару (стеллажу) назначать соответствующие признаки, которые позволят включить товар в листинги разных товарных групп (т.е. соответствие подходящим категориям).
Например, конкретный товар зеркало, может включаться как в категорию Зеркала, так и в категорию Аксессуары.
