Структура интернет-магазина

Ограничивать ЧПУ в 2-3 уровня - тоже не ново. ) 

ХК и ЧПУ служат в первую очередь для формирования структуры, во вторую для удобство навигации (с фишками, типа выпадающего списка на этом уровне, например). Вообще, всё аргументируется семантикой. Диван выигрывает у мягкой мебели в 50 раз. 

Да кстати. Движок сайта так построен. 

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

Да прогоняй свои гипотезы через Ai. Как ты определишь то, как иерархию видит поисковик? Для поисковика существуют рекомендации: чпу, хк. Но тут основное - рекомендации. Захочет поисковик построить иерархию по тегам, а не категориям - построит. Подумает, что у тебя интент не howto, а какая-то конкретная категория - сделает иначе. 

И, главное, зачем вообще? Ты строишь структуру сайта на этапе его разработки, согласно с бизнес-моделью и спросом. Тут никакого значения не имеет по существу, какой мусор сейчас накинут. Косвенно имеет значение то, что выдаёт pageweight (условно просчитываение PR каждой страницы). 

Зачем ты делаешь какую-то абсолютно бесполезную дичь, неприменимую никоим образом ни для чего вообще?

Думаю, что сам вопрос сформулирован не вполне корректно.

ЧПУ применительно к URL - способ реализации URL адресов для человека (исходя из названия - "человеко-понятное управление").

Это речь про то, что:

Динамически нечитаемая запись URL, например,

shop.com/product.php?item=28493

записывается как

shop.com/catalog/smartphones/apple-iphone-15/

В то числе ЧПУ - это про иерархичность URL адресов, но не обязательно, потому что может быть выбрана плоская структура, где все url адреса на общем уровне вложенности.

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

Далее ХБ (хлебные крошки) - это элемент пользовательской навигации - строчка под заголовкам страницы, которая указывает в каком разделе пользователь находится, чтобы 

а) была наглядность

б) пользователь мог переключится на уровень выше (что примечательно только выше)

но при этом ХБ могут содержать не всю верхнюю вложенность, ХБ (в случае большой вложенности может сокращаться), чтобы уместить ХБ в рабочую ширину (для mobile view это актуально).

Поэтому сравнивать ХБ с ЧПУ некорректно, тем более, что ХБ могут реализовываться достаточно вольно, например вот так,

Главная ... Диваны -> Прямые 

где уровне "Каталог" и "Мягкая мебель" могут быть скрыты.

А могут быть и вообще два крайних уровня, например вот так,

... / Диваны -> Прямые

Это точнее назвать хлебными крошками и обычно в ХБ выводятся не title-ы, а короткие названия:

Главная -> Каталог -> Мягкая -> Диваны -> Прямые

Часто могут быть более развёрнутые:

Главная -> Каталог мебели -> Мягкая мебель -> Диваны -> Прямые

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

Когда мы реализуем URL таксономию, то лучше в slug-ах не дублировать лишние слова т.е.

site.ru/catalog/myagkaya/divany/pryamye/

Раз магазин посвящён только мебели, то слово mebel повторять на разных уровнях не следует.

Однако в title и H - да, важно использовать полную рабочую связку слов

/catalog/ -> Каталог мебели

/myagkaya/ -> Мягкая мебель

/divany/ -> Диваны

/pryamye/ -> Прямые диваны

И теперь к главному вопросу, который часто задаётся, почему у одного сайта логика одна, а у другого другая? 

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

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

ПС может отранжировать в топе и [такой вариант] и [сякой вариант], и с вложенностью промежуточных категорий, и с дублированными slug-ами.

Для ПС приоритетны те сайты, где лучше покупают, таксономия и реализация ЧПУ и URL, важный, но второстепенный фактор.

Если вы не дублируете разделы, страницы и прочие навигационные косяки, ПС может отранжировать в топе и сайт с динамическими URL, где вложенность вообще будет реализована через get параметры.

Вот такие дела :)

Хорошо подмечено. В итоге намешали разные вещи. Не могу не признать что Антоний все разложил по полочкам. 

Застелил простынку 😀

p.s. Но на самом деле вопрос ёмкий и довольно многогранный, часто возникающий. 

Тогда вопрос , именно к твоему опыту - а насколько это все влияет на видимость сайта. Ты написал теорию, все понятно. А есть реальные кейсы, что исправление неправильной структуры  улучшало позиции. Что касается ЧПУ - мне кажется это вообще доли процента. Это все больше  для UX/UI -  для пользователя, не для поисковика. 

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

(открывая шкаф, доставая свежую простынку) - Обратимся к практике.

Бизнес практика показывает, что такого запроса и такой задачи (оценить влияние изменённой структуры на сайт) у бизнеса нет. Такая задача как подряд может возникать между SEO специалистами, между собственником (который пытается разобраться в SEO) и SEO специалистом, но только как отдельный рабочий эпизод.

В чём специфика. Бизнес не приходит к SEO за разовой работой (варианты услуги линк билдинга и отдельных задач относится к вышеуказанным эпизодам делегирования).

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

Поэтому отвечая на твой вопрос,

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

Т.е. сложно представить себе ситуацию, где всё идеально, и всё продумано и реализовано, но вот структура - беда.

Задача кейса - продемонстрировать комплексную работу, потому что кейсы демонстируют как мы умеем и как после нашей работы бизнесу становится хорошо.

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

Следовательно, в бизнес контексте практически невозможно себе представить ситуацию, где взятый в работу сайт, будет модернизироваться по структуре и всё. А потом будут производиться замеры реализации структуры. Всё необходимые задачи внедряются поступательно и тут всегда вместе и структура, и on page оптимизация, и копирайтинг, и маркетинговые внедрения, и UX/UI решения и дизайнерские дополнения.

Бизнесу нужно всё в комплексе, желательно быстро и за разумные деньги. Для него структура - частности.

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

Это что касается практической стороны seo в коммерческих задачах.

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

Для меня полезность ЧПУ и структурной модернизации очевидна (и кроме того о чём пишут в справочниках) помогает:

- Быстрее сформировать навигационные цепочки в серпе

- Быстрее сформировать Быстрее ссылки

- Однозначно определить правила url адресации, логику вложенности, правила нотирования и канонизации

- Получить более удобное представление структуры в Вебмастере, где покластерно выводится объём индексации

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

Кто знает как, зачем и какие задачи это решает, тот от приведения структуры к нужному виду не откажется.

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

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

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

Всё это совсем-совсем базовые и фундаментальные вещи, на которых строится всё остальное. Можно ли ими частично пренебрегать? Формально - можно (если в каких-то обстоятельствах можно) и достигать своих результатов.

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

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

Теперь к главному

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

Надеюсь ответил на вопрос.

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

Да, спасибо, примерно такой ответ я и ожидал услышать. Думаю, он будет полезнее  даже не мне, а ТС. 

Но все-таки - нужно меньше букф 😂. Мало кто долетит до середины Днепра дочитает до конца. Понимаю желание подробнее раскрыть тему, но, исходя из контингента тут - оверхед)