Суть в том, что Яндекс проиндексирует все (при технической возможности), что доступно для индексации, а затем оставит в индексе и будет ранжировать всё, что имеет пользовательский спрос. Если раздел или страница пользуется спросом, то Яндекс будет индексировать и ранжировать, в том виде в котором на неё имеется спрос.
В этом смысле Яндексу всё равно что называется и как называется правильно - "Диспенсер для скотча" или "Пистолет для скотча", ПС не оперирует смыслами, она оперируют статистическими метриками. Следовательно, если кто угодно назовёт что угодно и это будет пользоваться спросом и Яндекс это зафиксирует, то он проиндексирует, а ещё будет ранжировать в топе, а последователи скажут - ну вот, раз в топе, значит правильно.
Чисто практически плодить лишние сущности не надо, в мегамаркетах может быть как угодно только потому, что админ в один период времени назвал товарную группу так, а потом он же (или другой) не найдя подходящую - назвал по-другому.
Теперь к тому, что делать. Возьмите категорию, определите общее название, синонимы и LSI слова. Определите наиболее частотное использование - выберите это название как основное, а далее в зоне описания используйте синонимы и LSI, чтобы у вас по тексту было прямое вхождение. И не мучайте себя этим вопросом :)
Да, лучше, если у title страницы будет формироваться с порядковым номером. Т.е. Название категории - 1, Название категории - 2, Название категории - 3 и т.д.
Если вы не будете индексировать страницы (а страницы пагинации индексировать и не нужно), то для ПС это неважно.
Однако для удобства и наглядности лучше делать как следует.
Согласен с предыдущим мнением.
Современный пользователь зачастую набирает быстро и допускаешь ошибки, и опечатки. Каждый из нас в этом вопросе небезупречен.
Сохранять возможность редактирования сообщения в течении N времени, на мой взгляд, самое оптимальное решение.
Отсутствие Метрики на сайте не является ограничением для ранжирования. Яндекс всё равно будет ранжировать сайт с той релевантностью, которую рассчитает.
Другое дело, что точность и полнота сигналов по такому сайту для анализаторов будет меньше, а следовательно развитие такого сайта будет просто дольше.
Я разбирал этот вопрос со Сливинским (меня самого этот вопрос принципиально волновал), поэтому теперь есть уверенность в данном вопросе.
Посему, тут каждый решает как ему лучше с Метрикой или без.
Как правильно вложить span с заголовком h1 - ?
<div itemscope itemtype="http://schema.org/Organization">
Первый вариант: <span itemprop="name"><h1>Мой сайт - Заголовок</h1></span>
Второй вариант: <h1> <span itemprop="name"> Мой сайт - Заголовок</span></h1>
</div>
Cкорее всего более актуально использовать так:
<h1>Контакты </h1>
<span itemprop="name">Название компании</span>
<div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
<span itemprop="streetAddress">улица, номер дома</span>
<span itemprop="postalCode">индекс</span>
<span itemprop="addressLocality">город</span>,
Телефон: <span itemprop="telephone">номер телефона</span>,
Факс: <span itemprop="faxNumber"> номер факса</span>,
Электронная почта: <span itemprop="email">почта</span>
это будут просто дубли из одного кластера, грубо говоря обычная ошибка сайтостроителей
В общем, разобрались. Дубли title-ов, а особенно множественные - это беда, это создаёт перекосы релевантности, поэтому когда Вебмастер их подсвечивает (и/или они внезапно обнаруживаются) - надо разбираться в причинах и устранять.
Главная может быть любой и кроме товарного вывода там может быть что угодно.
Допустим, заказчик захочет выводить на Главной не весь перечень категорий, которых может быть много, а только анонс последних добавленных товаров и он может быть достаточно длинный в несколько строк.
Дублировать длинный анонс последних товаров и следом полный перечень товарных категорий избыточно, поэтому необходима страница, где будут только категории и всё.
Для тебя это может не быть проблемой, но я предпочитаю иерархическую вложенность по назначению.
Допустим, это городской портал, где десятки и сотни направлений, когда у каждого направления свой кластер и свои данные по кластеру - это всегда удобнее (для анализа) и нагляднее.
Я выше написал - анализ индексации вести, парсить данные, указывать регулярные выражения для обработки адресов, попадая по единый признак на уровне кластера (т.е. для последующей аналитики).
Например, на уровне кластера catalog
Я вижу какое кол-во страниц кластера было загружено поисковым роботом и какое кол-во страниц находит в настоящий момент в поиске.
Соот-но, по кластерам я наглядно вижу объём индексации каждого кластера. Когда объём страниц в поиске проседает - это для меня сигнал для организации необходимых рабочих мероприятий.
Когда у тебя в корне и товары, и категории, и служебные страницы - это множество элементов разного назначения в пространстве одного уровня вложенности.
Если тебе так удобнее, пожалуйста, делай, я лично не против :)
совершенно верно,
а данные по индексу я из карт сайта смотрю - они у меня разные для товаров и отдельно для листингов и/или служебных
Ну, вот, я у меня для каждого направления свой кластер:
Товары - /tovari/
Новости - /novosti/
Публикации - /pub/
Все дочерние элементы в своих кластерах.
Решения могут быть разные, каждый реализует то, которое ему лучше и соответствует структурным решениям и SEO требованиям.
Страница с перечнем родительских категорий. Их может быть десятки и более.
Не зависит, но ты предлагаешь размещать уникальные url-ы в корне, где по уровню вложенности они будут пересекать с другими пунктами меню (я писал выше), а также у всех товаров будет свой кластер с которым удобнее работать, нежели в корне будут перемешаны и товарные страницы и всё остальное.
а зачем
catalog
Страница c перечнем категорий:
Ботинки,
Сапоги,
и т.д.
tovari ?
Товарный кластер, который будет формировать уникальные url-ы по товарам.
Объём индексации товарного кластера будет удобно видно в Вебмастере (Индексирование -> Структура сайта) - Загружено/В поиске.
В твоём случае страницы товара и допустим служебные страницы: Контакты, рубрикатор Новости, О нас и т.д. будут на одном уровне вложенности.
