Антоний Казанский

Для задания уникальности токена (и соот-но результирующего url-а).

Названия товаров могут полностью дублироваться.

Лучше -> название + id т.е. /nazvanie-tovara_id/

Это нагляднее, понятнее, в постаналитике даст возможность составлять атрибуции для объединения url-ов в отдельные группы.

Допустим у вас -> /../uglovye/divan-solnichko_23351/

Тогда у вас будет возможность выбрать все диваны solnichko в кластере uglovye.

А если там будет просто цифровая запись, то, соот-но, не будет.

Т.е. название товара может быть критерием рабочей выборки.

Например, у вас появилась задача - вывести сколько раз просматривали страницы с диванами solnichko. У вас будет возможность для такой атрибуции. А если там будут только цифры, то такой возможности не будет, вам придётся вручную сопоставлять название товаров и соответствующие им цифры в id.

Ммм... чем больше сущностей, тем больше разночтений из-за разного понимания определений.

Для меня хаб - это скорее корневой раздел, который ключевым образом объединяет важные рабочие элементы.

В этом смысле хабом я назвал бы раздел Каталог, который включает всю вложенную в него структуру категорий.

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

Скажем, если мы оставляет только Каталог и смотрим на эту страницу, как на центральный узел,

то - да, можно назвать её хабом, потому что hub и есть "узел".

Дальше. Листинг - это фактический перечень, перечень может быть товарный, может быть категориальный, листингом можно назвать html карту сайта (если все элементы вывести одним уровнем без вложений), листингом могут быть записи в разделе статей/блоге.

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

Вот с этого тезиса и выбирается решение.

Как уже говорил выше реализации структуры могут быть разные. Для различных обстоятельств - свои более или менее удачные решения. 

Да, логика верная. Главное, что вы четко осознаете эти зависимости, а значит сможет сформулировать ТЗ, как и в какой логике формируется результирующий вывод (т.е. какие элементы нижнего уровня должны выводиться).

Да, есть вариации о которых вы сказали, но есть ситуации, где родительский уровень не всегда можно однозначно определить, он в контексте может быть и таким, и другим, и третьи, и здесь приходится на отдельный объект назначать свои признаки и вопрос привязки в URL для определения канонического адреса должен быть однозначен.

Можно выбрать вариант два, если описанных мною вариантов не будет, структура будет жёсткая и нерасширяемая. 

Но как только возникает ситуация, где появляются категории объединяющие в себе разные товары по новому признаку, который раньше не учли, то начинается "мягкий пепец".

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

Пожалуйста 😎

Это уже вопрос, который стал классическим, но здесь он неточен. В отдельный раздел Товары нужно размещать не категорию, а уже непосредственно товары, поэтому дальше речь пойдет о товаре, а не о промежуточной категории /stellazh-umka-roziviy/

Лучше - первый. Почему?

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

Следовательно, один и тот же товар может попадать в разные категории. Поэтому, если товар прикреплять к каждой категории, то могут возникать перекрёстные дубли т.е. ваш конкретный стеллаж будет находиться и в категории Стеллажи и в других, к которым он будет относится.

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

Например, конкретный товар зеркало, может включаться как в категорию Зеркала, так и в категорию Аксессуары.

Это тенденция (отключение поисковых операторов) наметилась уже давно.

Для меня листинг - это вид представления данных, а категория - это структурный элемент в контексте общей структуры.

Категория может содержать в себе товарный листинг, а может и не содержать (и содержать перечень подкатегорий, например).

Для меня это всё равно, что сравнивать статическую страницу и таблицу, главную и строку поиска, карту сайта и форму обратной связи. Совершенно ненужный контекст разговора. Мы ушли в сторону и начали обсуждать абстрактные формы, а это всегда неблагодарный разговор. Беспредметно он незачем.

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

Когда мы формируем структуру сайта в виде mind-карты (беру произвольный пример, карта не моя), то структура может выглядеть след. образом,

Где категория обобщает условную совокупность,

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

Страница Контакты - это не категория, это отдельная статическая страница, она никакие товары не объединяет.

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

Будет ли листинг на странице, или форма, или таблица, или текстовые блоки, или галереи - это уже вопрос в контексте отдельной страницы.

Был конкретный вопрос от TC,

на него уже ответили.

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