Дмитрий Мрачковский
Смотря как закрывать. Если через robots.txt - то и не загрузит. Если через мета noindex follow - загрузит, увидит ссылки на ней, в индекс страницу не добавит.
Но вот с закрытием о компании, контактов и тем более целых категорий - явный перебор (особенно последнее). Это очевидно полезные страницы.
Плюс при открытой пагинации был нестандартный кейс ее использования - определение переоптимизации для основной (первой) страницы каталога.
Так что в индексе не мешает, пользу принести может, времени на настройку много не отнимает. Не вижу причин не использовать такие страницы.
Вложенность сама по себе не влияет на скорость индексации, о чем говорили и Яндекс, и Google. Важно то, как быстро поисковики узнают о новых страницах. Если у нас есть товар, добраться до которого нужно последовательно через 3 категории, и товар, ссылка на который есть с главной страницы (при том, что уровень вложенности у них одинаковый), то второй, конечно, с большей вероятностью попадет в индекс поисковиков быстрее. Поэтому нужно всеми способами стараться сообщать поисковикам об актуальных страницах на сайте (прежде всего, с помощью sitemap.xml).
Совершенно верно, об этом и речь) Многие отмечают, что при переходе на m-поддомен трафик с поиска растет.
Вот как раз, чтобы "необходимые шаги", которые могут появиться в перспективе, не повредили десктопу или мобайлу, и выбирают зачастую мобильную версию. Чаще такие проблемы бывают с адаптивным дизайном, когда внедряют нововведения в десктопе, а в мобайле что-то ломается, или наоборот.
Из перечисленного, 5 лет назад были только различные способы адаптации. Ранжирование же и в целом восприятие адаптированных сайтов поисковыми системами коренным образом изменилось. Если Вам это понятно, кажется очевидным и не требующим объяснений - это замечательно) Но на практике, в работе постоянно приходится сталкиваться с сайтами, у которых одни и те же ошибки и проблемы. Проблема есть - значит тема актуальна, тем более во время повсеместного включения MFI для сайтов в Google. Именно для владельцев/маркетологов таких сайтов и написана эта статья.
Такой вариант тоже не исключен)
Да, встречалось и такое. Думают, что делают адаптивную вёрстку, а на самом деле выводили 2 варианта шаблона в коде и неиспользуемый просто не отображали.
Если "нормальные" адаптивные решения работают отлично именно у Вас, как у пользователя, это не значит, что у других тоже все в порядке - у многих адаптивы могут загружаться и отрисовываться очень долго. Тогда мобильная версия или RESS будут намного выигрышнее смотреться. А еще не забываем про Speed Update от Google, где скорость загрузки будет играть более значимую роль. Ну и AMP не панацея даже для Гугла, не говоря уже о Яндексе.
Здравствуйте. Ответ на Ваш вопрос есть в разделе о рекомендациях по применению смарт-фильтра (т.к. требования к нему и к тегированным выборкам во многом совпадают):
Не допускайте индексацию страниц, у которых выбрано более одного значения для какого-либо свойства. Также для таких страниц не стоит использовать шаблоны генерации мета-тегов и заголовков.Это значит, что, например, выбраны сразу 2 цвета для туфель - желтый и красный (2 значения для свойства "цвет"), или 2 вида туфель - лодочки и стилеты (2 значения для свойства "тип"). Т.е. не следует допускать индексацию страниц вида "желтые и красные туфли лодочки" или "желтые туфли лодочки и стилеты". Если выбрано по одному значению для каждого свойства, как в Вашем примере, такие страницы, конечно, следует открывать для индексации (в случае смарт-фильтра) или создавать вручную (в случае тегированных выборок).
Не открывайте для индексации страницы, у которых выбрано более трех свойств фильтрации.Здесь речь идет именно о количестве примененных свойств, даже если у каждого выбрано только по одному значению. Например, если мы возьмем "красные кожаные туфли с открытым носом на шпильке", то здесь используется сразу 4 свойства - цвет (красные), материал (кожаные), тип (с открытым носом), каблук (на шпильке). Подобные комбинации запрашивают крайне редко (если вообще запрашивают), и, как говорилось в статье, подобные страницы не будут полезны для поисковых систем и могут мешать корректной индексации. Поэтому введено ограничение на попадание страниц в индекс при использовании не более 3-х различных свойств. В случае с "желтые туфли лодочки" используется только 2 свойства - по этому критерию такая комбинация тоже проходит и можно создавать такую страницу.
Алексей, это очень хороший вопрос. В подобной ситуации лучше смотреть не на различия в запросе, а на различия в интенте, т.е. в задаче, которую необходимо решить посетителю. Различные запросы с одинаковым интентом можно объединять на одной странице, как в данном случае. У меня в практике были случаи, когда одну страницу разделяли на 3, ориентируясь именно на группировку по запросам, после чего позиции по всем запросам (включая исходную страницу) стали хуже. После того, как вернули объединённую страницу и доработали выводимый на ней контент, позиции стали лучше, чем были до разделения. Это связано с тем, что такие страницы ценнее в плане полноты охвата контента, необходимого пользователю. Если разделять запросы на различные страницы, то они могут конкурировать друг с другом, будут разделяться поведенчески показатели вместо того, чтобы аккумулироваться на одной странице. Их могут признать как дубликатами, так и недостаточно качественными - в любом случае, хорошего мало.
Наверное многие слышали про алгоритм Палех и такое понятие, как LSI - они тесно связаны с определением пользовательского интента, а это, в свою очередь, является одной из главных задач для поисковых систем - решать проблему пользователя.
Все зависит от ниши. Для электроники, например, можно использовать тип товара + бренд + модель. Можно ещё артикул добавить. В этом плане хороший пример - Мвидео. Но например для смартфонов они ещё используют цвет и объём памяти. Они могут себе это позволить, т.к. на каждую вариацию товара у них есть много отзывов, образующих уникальный ценный контент. Для небольшого магазина это может наоборот создать трудности - будет много очень похожих страниц, отличающихся парой слов/цифр и с дублированными описаниями. Тогда нет смысла разносить вариации товара, а сделать общую карточку, где цвет/память можно будет выбрать перед добавлением в корзину. Но это уже больше вопрос представления ассортимента, чем задания названий. В любом случае, не должно быть товаров с одинаковыми названиями. URL, соответственно, транслитерация названия. При этом желательно, чтобы слова в адресе не повторялись (такое может быть, если в адресе товаров используется вся цепочка с родительскими категориями до него и будет повторяться тип товара в символьном коде категории и символьном коде товара).
А под «посмотреть пример готовой семантики» что имеете а виду?
Такую страницу нельзя назвать именно страницей каталога, физически она не создается. Она формируется динамически исходя из примененных параметров, которые выбраны пользователем или определены в URL'е, если было прямое обращение к ней. По сути, этот компонент работает как обычный фильтр, но обычно адрес страницы фильтрации формируется с помощью GET-параметров, а в смарт-фильтре - с помощью четко определенной вложенности свойств товаров. Также, как говорилось в статье, таким страницам назначаются правила формирования заголовков и мета-тегов.
Да, все так - категории в одной директории, товары - в другой. Поисковики правильно воспримут весь путь до товара со всеми вложенными категориями и отобразят навигационную цепочку в сниппете поисковой выдачи, если корректно построите хлебные крошки. Ещё лучше будет, если разметите их с помощью микроразметки.
Не понял Вас. Что именно имеете в виду?)
на практике очень часто встречается ситуация, когда ни внутренних, ни внешних ссылок на сайте на страницы дублей нет, а вот поисковые системы их индексируют. И тут никакой паук вам не поможет.Если поисковик проиндексировал - нам же проще. Выгружаем проиндексированные страницы из вебмастера или парсим выдачу, прогоняем список пауком, находим дубликаты (полные дубли на ура в нем распознаются, плюс можно найти какие-то единичные некорректные страницы, которые не являются дубликатами, но являются ошибками). Настраиваем корректные коды ответов для неверных страниц (301 или 404), прогоняем еще раз пауком, чтобы убедиться, что все верно. Список страниц с кодом 404 отправляем на удаление из индекса, с кодом 301 - на переобход.
Сервис, как я понимаю, перебирает все указанные в примерах варианты дублей и смотрит на их поведение. Но проблем здесь 2, первая в статье уже была собственно озвучена, а вторая - в комментариях:
1) Могут быть варианты дубликатов, которые сервис не учитывает, допустим, если эти дубликаты могут быть связаны не с неверно настроенными кодами ответов. Например, он мог бы элементарно проверять добавление произвольного GET-параметра и смотреть, разрешена ли индексация такой страницы в robots.txt.
2) На сайте могут быть какие-либо неизвестные типы страниц - их можно банально пропустить и не добавить в сервис для проверки.
А так - лучше изначально продумывать структуру сайта, корректно настраивать коды ответов для всех типов страниц, настроить индексацию в robots, правильно формировать XML-карту и убрать в счетчике Метрике функцию отправки страниц на индексацию. Тогда проблем с дублями не будет. Актуально, конечно, для новых сайтов. Для сайтов с историей вариант проверки индекса с помощью паука кажется более очевидным и наглядным.
Как минимум, у каждого товара необходимо выбрать главную категорию, к которой он будет привязан и чей путь будет отражен в хлебных крошках. Это необходимо для ПС, при отключенном JS и при переходе на страницы товаров по прямым ссылкам (закладки, рефералы и т.д., т.е. попали на товар не по ссылке на вашем сайте). Фактически, это второй вариант.
Динамическое формирование можно добавить для удобства пользователей и использовать при навигации по сайту (при переходе на товар по ссылкам на сайте).