Структура URL граненой навигации

1. уникальность
2. Множественный выбор
3. Нестандартная кодировка URL
4. Являются ли грани иерархическими?
5. Неизменные ценности
6. Фасетный Порядок
7. Пользовательский опыт
8. Логические дополнения

Фасетная навигация - это набор элементов и функциональных возможностей пользовательского интерфейса, которые позволяют фильтровать и уточнять представления категорий. В сообществах SEO, UX и других разработчиков веб-сайтов ведутся споры о том, как лучше всего представить фасетную навигацию в URL.

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

- Лучшая (и 5 из худших) практик многогранной навигации

Правильный способ обозначения фасетов в URL-адресе - использование параметров запроса. Однако некоторые считают, что виртуальные подкаталоги представляют собой лучшую альтернативу для SEO и UX. Мы сравним различные варианты включения фасетов в URL, начиная с упрощенных примеров каждого метода.

Параметры запроса https://example.com/category?option=true Виртуальные подкаталоги https://example.com/category/filter/option/true

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

Чтобы определить, какая структура URL лучше всего подходит для SEO, давайте взвесим все «за» и «против» каждого варианта в соответствии с «лучшими и худшими» практиками многогранной навигации, определенными Google.

уникальность

В идеальном состоянии уникальный контент - будь то отдельный продукт / статья или категория продуктов / статей - будет иметь только один доступный URL.

Поскольку это относится к уникальности URL, ни параметры запроса, ни виртуальные подкаталоги не имеют преимуществ.

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

Совет: это также относится к URL-адресам http и https, а также к URL-адресам, которые можно посещать с поддоменом и без него (например, www); канонизация или перенаправление этих URL поможет избежать штрафов за дублирование контента.

Множественный выбор

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

1. Параметры запроса
   • https://example.com/category?color=black,white
   • https://example.com/category?color=black,white&size=8,10
2. Виртуальные подкаталоги
   • https://example.com/category/filter/color/black,white/
   • https://example.com/category/filter/color/black,white/size/8,10/

Эти подходы вызывают опасения по поводу правильного кодирования URL.

… [Опасность иерархической классификации как общего решения кроется] в философии смысла. … Поскольку отношения между субъектами похожи на сеть, а не на древовидную структуру, даже для людей, согласных с сетью, может быть выбрано другое древовидное представление.

- Классные URI не меняются Тим Бернерс-Ли

Нестандартная кодировка URL

Google рекомендует не использовать «нестандартную кодировку URL для параметров ... вместо ключа = значение и пары».

Google предоставляет два «худших» примера, в которых пары ключ-значение неправильно помечены::, а не =, и когда несколько параметров добавляются с помощью [] и ,, вместо &.

Если пары ключ-значение помечены правильно, в URL-адресе могут использоваться допустимые специальные символы.

Запятая, например, является разрешенным символом пути (например, «pchar») как часть под разделителей (то есть «под-разделителей»), определенных в RFC 3986 § 2.2 как для параметров запроса, так и для сегментов пути. Как RFC 3986 § 3.3 состояния:

зарезервированные символы точки с запятой («;») и «равно» («=») часто используются для разделения параметров и значений параметров, применимых к этому сегменту. Запятая («,») зарезервированный символ часто используется для аналогичных целей.

Хотя эти символы могут использоваться как в сегментах пути, так и в сегментах запросов, эти символы редко встречаются в сегментах пути, поскольку параметры разделения в сегменте пути не дают четкой иерархии .

Являются ли грани иерархическими?

Суть вопроса заключается в том, являются ли фасеты иерархическими данными.

Согласно Запись в Википедии о «Граненой классификации» , грани не иерархические:

Иерархическая классификация относится к классификации объектов с использованием одной иерархической таксономии . Фасетная классификация может фактически использовать иерархию в одном или нескольких ее фасетах, но позволяет использовать более одной таксономии для классификации объектов.

Как мы видели в наших примерах выше, «множественные таксономии», представленные фасетами, плохо подходят для включения в сегмент пути URL. Возвращаясь к вопросу использования нестандартной кодировки URL, согласно RFC 3986 § 3.3 :

Компонент пути содержит данные, обычно организованные в иерархической форме, которые вместе с данными в неиерархическом компоненте запроса ( Раздел 3.4 ), служит для идентификации ресурса…

RFC 3986 § 3.4 продолжает:

Компонент запроса содержит неиерархические данные

Это дает понять, что фасеты не должны появляться в сегментах пути, а должны отображаться как параметры запроса. На самом деле, Google инструктирует:

Используйте параметры (когда это возможно) со стандартным кодированием и парами ключ = значение.

Использование виртуальных подкаталогов для обозначения фасетов является нестандартным, и Google может лучше предположить содержание страницы, когда фасеты передаются через параметры запроса. Google даже предоставляет Инструмент Параметры URL в консоли поиска Google, которая позволяет администраторам сайтов указывать Google, как интерпретировать параметры запроса; для виртуальных подкаталогов такого инструмента не существует.

Неизменные ценности

Другая «худшая практика», как определено Google, это «использование каталогов или путей к файлам, а не параметров, для перечисления значений, которые не изменяют содержимое страницы».

В структуре граненых URL-адресов на основе каталогов все следующие URL-адреса будут обслуживать один и тот же контент:

• https://example.com/category/filter/option/
• https://example.com/category/filter/
• https://example.com/category/

Эта проблема менее очевидна при использовании параметров запроса, поскольку существует четкое разграничение между иерархией и фасетами с использованием пар ключ-значение. Эта проблема может быть решена путем канонизации, но не считается лучшей практикой, как отмечалось от Google ; Рекомендуется использовать параметры запроса, поскольку «параметры URL-адреса позволяют поисковым системам гибко определять, как эффективно сканировать».

Фасетный Порядок

Независимо от того, какая структура URL используется, фасеты всегда должны быть представлены единым образом (например, в алфавитном порядке), поэтому несколько URL не индексируются для одного и того же содержимого. Возьмите следующие URL в качестве примера:

• https://example.com/category?test=0,1
• https://example.com/category?test=1,0

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

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

Пользовательский опыт

Как фронтальный компонент веб-сайтов, URL-адреса являются важной частью взаимодействия с пользователем. URL-адрес выступает в качестве контрольной точки для текущего представления, и опытные пользователи могут использовать URL-адрес в качестве «виртуальной цепочки», чтобы перемещаться по иерархии вашего сайта в обратном направлении. Поддержание понятного URL-адреса является важным и нетривиальным делом.

Примечание: я написал обширный пост о важности разработки URL-адресов как части пользовательского интерфейса сайта ,

Логические дополнения

Google не советует «добавлять параметры URL без логики». Ненужные параметры должны быть удалены, чтобы поддерживать понятную человеку структуру URL, когда это возможно. Google рекомендует удалить информацию о сеансе пользователя из URL-адреса и вместо этого сохранить эти данные в файлах cookie. Отсутствие ненужных данных в URL-адресе не только помогает пользователям понять содержание, присутствующее в текущем представлении, но также помогает SEO, как отмечает Google:

Посторонние параметры URL только увеличивают дублирование, вызывая менее эффективные сканирование и индексацию.

Похожие

Комментарии