В данной статье (уровень веб-мастера - продвинутый) речь пойдёт о, пересекающейся по разным признакам, т.н. "фасетной" навигации. Для упрощения усвоения материала рекомендую пробежаться по статье в Википедии "Фасетная классификация " и публикации на английском языке (но с картинками!) "Design better faceted navigation for your websites ".
Фасетная навигация с фильтрацией по цвету или ценовому диапазону может быть полезна для ваших посетителей, но зачастую вредит в поиске из-за того, что создаёт множество комбинаций адресов с дублирующимся контентом . Из-за дублей поисковые системы не смогут быстро сканировать сайт на предмет обновлений контента, что соответственно влияет и на индексацию. Чтобы минимизировать эту проблему и помочь веб-мастерам сделать фасетную навигацию дружелюбной в отношении поиска, мы бы хотели:
Идеально для пользователей и поиска Google
Чёткий путь к продуктам/страницам статьи:
Представление URL для страницы категории:
http://www.example.com/category.php?category=gummy-candies
Представление URL для конкретного продукта:
http://www.example.com/product.php?item=swedish-fish
Нежелательные дубликаты, вызванные фасетной навигацией
Одна и та же страница доступна с различных веб-адресов:
Каноническая страница
URL: example.com/product.php? item=swedish-fish
Дублированная страница
URL:example.com/product.php? item=swedish-fish&category=gummy-candies&price=5-10
category=gummy-candies&taste=sour&price=5-10
Ошибки:
- Бессмысленно для Google, так как пользователи редко ищут [мармелад по цене 9:55 долларов].
- Бессмысленно для поисковых роботов, которые обнаружат один и тот же элемент ("фруктовый салат") от родительских страниц категорий (либо "Жевательный мармелад" или "кислый Жевательный мармелад").
- Отрицательный момент для владельца сайта, потому запросы на индексацию разбавляются многочисленными версиями одной и той же категории.
- Отрицательный момент для владельца сайта, потому что это бесполезная и лишняя нагрузка в пропускной способности сайта
URL: example.com/category.php? category=gummy-candies&taste=sour&price=over-10
Ошибки:
- Неправильно отдаётся код для поисковых систем (в таком случае страница должна отдавать код 404)
- Пустая страница для пользователей
Наихудшие решения (не дружелюбные в отношении поиска) фасетной навигации
Пример №1 : В составе URL применяются не стандартные параметры: запятые и скобки, вместо ключ=значение& :
- example.com/category? [ category:gummy-candy ][ sort:price-low-to-high ][ sid:789 ]
- example.com/category?category , gummy-candy , sort , lowtohigh , sid , 789
example.com/category?category=gummy-candy&sort=low-to-high&sid=789
Пример №2
: Использование каталогов или путей к файлам, а не параметров в списках значений, которые не изменяют содержание страницы:
example.com/c123
/s789/
product?swedish-fish
(где /c123/ категория, /s789/ ID сессии, что не изменяет содержимое страницы)
Хорошее решение:
- example.com /gummy-candy/ product?item=swedish-fish&sid=789 (каталог, /gummy-candy/, меняет содержимое страницы в значимым образом)
- example.com/product?item=swedish-fish&category=gummy-candy&sid=789 (параметры URL дают большую гибкость для поисковых систем, чтобы определить, как эффективно сканировать)
Общие значения, которые не меняют содержимое страницы и должны быть перечислены в качестве параметров URL, включают:
- ID сессии
- Отслеживание идентификаторов
- Referrer идентификаторы
- Отметки времени
Использование незначительных данных, генерируемых пользователями сайта (например, как долгота/широта или "дней назад"), в сканируемых и индексируемых адресах:
- example.com/find-a-doctor? radius=15&latitude=40.7565068&longitude=-73.9668408
- example.com/article?category=health& days-ago=7
- example.com/find-a-doctor?city=san-francisco&neighborhood=soma
- example.com/articles?category=health&date=january-10-2014
- example.com/filtering/ find-a-doctor?radius=15&latitude=40.7565068&longitude=-73.9668408
- example.com/filtering/ articles?category=health&days-ago=7
User-agent: *
Disallow: /filtering/
Пример №4 . Добавление параметров URL без логики.
- example.com/gummy-candy/lollipops/gummy-candy/ gummy-candy/product?swedish-fish
- example.com/product?cat=gummy-candy&cat=lollipops&cat=gummy-candy &cat=gummy-candy&item=swedish-fish
- example.com /gummy-candy/ product?item=swedish-fish
- example.com/product?item=swedish-fish&category=gummy-candy
Пример №5 : Предлагать дальнейшие уточнения (фильтрация), когда есть нулевые результаты.
Плохо:
Разрешать пользователям выбрать фильтры, когда существуют нулевые элементы для уточнения.
Уточнение к странице с нулевыми результатами (например, price=over-10), что расстраивает пользователей и вызывает ненужные запросы для поисковых систем.
Как надо:
Создавать ссылки только тогда, когда есть элементы для выбора пользователем. При нулевом результате ссылку помечать "серой" (т.е. недоступной для клика). Для дальнейшего улучшения юзабилити рассмотреть вопрос о включении показателя количества доступных элементов рядом с каждым фильтром.
Вывод страницы с нулевыми результатами (например, price=over-10) не допускается, плюс запрещается пользователям делать ненужные клики, а поисковым система сканировать эту не полезную страницу.
Необходимо предотвращать появление ненужных адресов и минимизировать пространство для посетителя, создавая URL только при наличии продукции. Это поможет пользователям оставаться занятыми на вашем сайте (меньше кликов по кнопке назад, когда не находится ни одного товара), уменьшит число возможных URL, известных поисковым системам. Кроме того, если страница не просто "временно нет в наличии", а вряд ли когда-нибудь будет содержать релевантную информацию, стоит рассмотреть возможность сделать для неё код ответа 404 . На 404-ой странице вы можете оформить полезное сообщение для пользователей с большим количеством опций в навигации или окно поиска, чтобы пользователи могли найти родственные продукты.
Для новых сайтов, веб-мастера которых рассматривают внедрение фасетной навигации, есть несколько вариантов оптимизации сканирования (совокупность адресов на вашем сайте, известных роботу Google) уникальных страниц контента и уменьшения попадания в индекс поисковой системы дублирующихся страниц (консолидация сигналов индексации).
Определите, какие параметры URL требуются для поисковых систем, чтобы сканировать каждую индивидуальный страницу с контентом (то есть, определить, какие параметры необходимы для создания, по меньшей мере одного клик-пути к каждому пункту). Обязательные параметры могут включать в себя item-id , category-id , page т.д.
Определите, какие параметры будут полезны для посетителей с их запросами, и какие скорее всего только вызовут дублирование при сканировании и индексировании. В примере с кондитерскими товарами (мармелад) параметр URL "taste " может быть ценным для пользователей с запросами в примере taste=sour . Тем не менее, логично посчитать параметр "price" вызывающим лишнее дублирование category=gummy-candies&taste=sour&price=over-10 . Другие распространенные примеры:
- Ценные параметры для поисковиков: item-id , category-id , name , brand ...
- Ненужные параметры: session-id , price-range ...
Вариант 1: и внутренние ссылки
Пометьте все ненужные URL-адреса атрибутом . Это уменьшит трудозатраты поискового робота и предотвратит снижение частоты сканирования. Глобально управлять сканированием нужно через robots.txt (Примеч. переводчика: см. статью " ").
Воспользуйтесь атрибутом rel="canonical", чтобы отделить страницы для поискового индекса от страниц, не нужных там (например на странице price=5-10
можно прописать атрибут rel="canonical", указывающий на категорию всего кислого мармелада example.com/category.php?category=gummy-candies&taste=sour& page=all
).
Вариант 2: Robots.txt и Disallow
URL-ы с ненужными параметрами включают в директорию /filtering/
, которая будет закрыта в robots.txt (запрет disallow). Это даст всем поисковым системам сканировать только "правильное" внутриссылочное (содержимое) сайта, но будет блокировать разом сканирование нежелательных URL. Например (example.com/category.php?category=gummy-candies
), если ценными параметрами были item, category и taste, и лишними были идентификатор сеанса и price, то URL будет для taste таким:
example.com/category.php?category=gummy-candies&taste=sour
,
но все ненужные параметры, такие как price, URL включит в предопределенный каталог - /filtering/:
example.com/filtering/
category.php?category=gummy-candies&price=5-10
,
который затем через robots.txt будет запрещен:
User-agent: *
Disallow: /filtering/
Вариант 3: Раздельные хосты
Убедитесь, что лучшие решения, перечисленные выше (например, для ненужных адресов) все еще применяются. В противном случае поисковые системы уже сформировали большую ссылочную массу в индексе. Таким образом, ваша работа будет направлена на снижение дальнейшего роста ненужных страниц, просмотренных с помощью робота Google и консолидацию сигналов индексации.
Используйте параметры со стандартной кодировкой и форматом ключ=значение (key=value).
Убедитесь, что значения, которые не меняют содержимое страницы, такие как идентификаторы сеансов, реализованы в виде ключ=значение, а не каталогов.
Не позволяйте кликать и не генерируйте URL-адреса, когда не существует элементов для фильтра.
Добавьте логику в отображение параметров URL: удалите ненужные параметры, а не добавляйте постоянно значения (например, избегайте такой генерации ссылки: example.com/product?cat=gummy-candy&cat=lollipops &cat=gummy-candy&item=swedish-fish ).
Сохраняйте ценные параметры в URL, перечислив их в первую (так как
URL видны в результатах поиска) очередь и менее уместные параметры в
последнюю (например, идентификатор сессии).
Избегайте подобной структуры ссылок: example.com/category.php?session-id=123&tracking-id=456
&category=gummy-candies&taste=sour
Настройте параметры URL в Инструментах для веб-мастеров, если имеете чёткое представление о работе ссылок на вашем сайте.
Убедитесь, что при использовании JavaScript для динамического управления контентом (sort/filter/hide) без обновления URL, есть реальные веб-адреса на вашем сайте, имеющие ценность в поиске, например, это основные категории и страницы продуктов, которые доступны для сканирования и индексирования. Старайтесь не использовать только домашнюю страницу (т.е. один URL) для всего вашего сайта, а через JavaScript динамически изменять контент навигацией - это, к сожалению, выдаст в поиске пользователям только один URL. Кроме того, проверьте, чтобы производительность не повлияла на работу динамической фильтрации в худшую сторону, так как помешает пользователю работать с сайтом.
Улучшите индексацию различных страниц одного контента указанием атрибута rel="canonical" на привилегированную версию страницы. Атрибут rel="canonical" может быть использован внутри одного и нескольких доменов.
Оптимизируйте индексацию контента, разбитого на страницы "паджинации" (например, page=1 и page=2 из категории "gummy candies") посредством (либо):
- Добавьте атрибут rel="canonical" в серию страниц с указанием канонической категории с параметром “view-all” (например, page=1, page=2, и page=3 из категории "gummy candies" с with rel=”canonical” на category=gummy-candies&page=all ), удостоверившись, что страница необходима пользователям и загружается быстро.
- Используйте разметку разбиения на страницы rel="next" и rel="prev" , чтобы указать на связь между отдельными страницами (см. статью "Paginaton with rel="next" and rel="prev" ") .
В сегодняшнем уроке мы с вами попробуем воссоздать имитацию фасетного (фасеточного) поиска средствами Javascript. Я подразумеваю, что вы уже знаете что такое фасетный поиск, раз читаете данный туториал, в противном случае погуглите или загляните на Amazon или мою Демку .
Для начала нам понадобится библиотека github.com/eikes/facetedsearch. Скачайте её и подключите файл facetedsearch.js к нашему проекту. Так же нам понадобятся библиотеки jQuery и Underscore.
Дисклеймер: Я понимаю, что JQ уже давно не торт, но использую его как привычный синтаксический сахар, вы можете перепилить это под более привычные вам библиоетки или на ванильном JS.
Итак для начала сделаем простенькую разметку с подключенными зависимостями:
Document // Сюда мы выведем фасетные фильтры // А тут будут наши элементы
Теперь нам нужно описать настройки нашего приложения и создать шаблон вывода элементов массива которые мы будем сортировать при помощи фасетов:
$(function(){
var item_template = // Описывем шаблон
"" +
"
Ну и собственно создать сам JSON массив с элементами для отображения в нашем фасетном поиске на JS:
Var items = [ { "firstname": "Mary", "lastname": "Smith", "imageURL": "http://lorempixel.com/150/150/cats/2", "description": "Sed Ea Amet. Stet Voluptua. Nonumy Magna Takimata ", "category": "Mouse", "language": ["Smalltalk", "XSLT"], "continent": "Africa" }, { "firstname": "Patricia", "lastname": "Johnson", "imageURL": "http://lorempixel.com/150/150/cats/3", "description": "Ut Takimata Sit Aliquyam Labore Aliquyam Sit Sit Lorem Amet. Ipsum Rebum. ", "category": "Lion", "continent": "North America" }, ... ];
Данный массив я бы вынес в отдельный JS файл который бы формировался динамически, из БД например.
Вот собственно и всё, мы получаем фасетный поиск на JavaScript и можем его кастомизировать. Далее я привожу переведённую документации библиотеки, где вы можете подсмотреть необходимые вам триггеры.
Документация ФункцииДве функции экспортируются в пространство имен jQuery.
facetelize Используется для инициализации фасетного поиска с заданными настройками.
facetUpdate Может использоваться, если вы хотите изменить состояние фасетного поиска извне.
Настройки объектовitems: Массив элементов, которые будут отфильтрованы и отсортированы в процессе.
facets: Объект, для которого ключи соответствуют ключам элементов и значениям, является заголовком для этого фасета. Элементы будут отфильтрованы на основе того, какое значение они имеют для этих ключей.
orderByOptions: Подобно фасетам, за исключением того, что эти пары «ключ-значение» используются только для сортировки. Когда ключ RANDOM включен, результаты могут быть рандомизированы.
facetSelector: Это селектор, который используется для поиска DOM-узла, из которого выбираются фильтры фасетов.
resultSelector: Это селектор, который используется для поиска DOM-узла, где отображаются результаты.
resultTemplate: Строка, которая используется Underscore шаблонизатором Для рендеринга каждого элемента из массива items . Следующие атрибуты добавляются к каждому элементу, который также можно использовать в шаблоне: batchItemNr , batchItemCount и totalItemCount .
state: Этот объект сохраняет текущие фильтры, сортирует: currentResult и прочие. Вы можете предоставить строку orderBy или объект filters для их предварительной настройки.
enablePagination: Boolean для включения пагиналора и кнопи "load more", по умолчанию true .
paginationCount: Если включен пагинатор, задаёт количество элементов на страницу, по умолчанию - 50.
facetSortOption: Используйте эту функцию, чтобы изменить порядок элементов фасетов. Принимает объект, в котором ключи соответствуют именам фасетов и значениям в массив значений фасетов, которые могут быть расположены в том порядке, в котором вы хотели бы их видеть. В этом примере будут отсортированы континенты в другом порядке, элементы, не включенные в массив, будут добавлены в алфавитном порядке:
FacetSortOption: {"continent": ["North America", "South America"]}
Есть еще несколько шаблонов, пожалуйста, посмотрите исходный код facetedsearch.js , чтобы увидеть все доступные параметры шаблона.
СобытияВы можете привязываться к некоторым событиям, которые должны отправить уведомления, когда произошли некоторые действия. Для этого используем систему событий jquery:
facetuicreated: Вы можете привязать эту функцию к DOM элементу settings.facetSelector который должен быть уведомлен, когда пользовательский интерфейс был создан.
facetedsearchresultupdate: Вы можете привязать эту функцию к DOM элементу settings.resultSelector что бы получить уведомление о результатах обновления.
facetedsearchfacetclick: Это событие вызывается при щелчке фасета и его срабатывании на settings.facetSelector элементе. Который получает идентификатор фасета как аргумент.
facetedsearchorderby: Это событие вызывается при щелчке элемента сортировки по элементу settings.facetSelector. Он получает ID order в качестве аргумента.
$(settings.resultSelector).bind("facetedsearchresultupdate", function(){ // do something, maybe });
{ "query": { "and": [ { "terms": {"country": ["be", "fr"]} }, { "terms": {"category": ["books", "movies"]} } ] } }
Для счетчиков мы можем использовать встроенные агрегаты из Elasticsearch. Каждый из двух фасетов хранится как одно поле в индексе, поэтому мы можем использовать агрегирование терминов в каждом из этих полей. Агрегация вернет счетчик за значение этого поля.
{ "query": { "and": [ { "terms": {"country": ["be", "fr"]} }, { "terms": {"category": ["books", "movies"]} } ] }, "aggregations": { "countries": { "terms": {"field": "country"} }, "categories": { "terms": {"field": "category"} } } }
Если бы вы выполнили этот запрос, вы заметите, что счетчики отключены. В двух не отобранных странах, в Португалии и Бразилии, есть счетчик 0. Хотя есть фактические результаты, если мы хотим их выбрать (из-за ORвнутренней грани). Это происходит потому, что по умолчанию Elasticsearch выполняет свои агрегирования в результирующем наборе. Это означает, что если вы выберете Францию, фильтры другой страны будут иметь счет 0, потому что в результирующем наборе содержатся только элементы из Франции.
Чтобы исправить это, нам нужно дать команду Elasticsearch выполнить агрегацию во всем наборе данных, игнорируя запрос. Мы можем сделать это, определив наши скопления как глобальные.
{ "query": { "and": [ { "terms": {"country": ["be", "fr"]} }, { "terms": {"category": ["books", "movies"]} } ] }, "aggregations": { "all_products": { "global": {}, "aggregations": { "countries": { "terms": {"field": "country"} }, "categories": { "terms": {"field": "category"} } } } } }
Если бы мы просто сделали это, наши счетчики всегда были бы одинаковыми, потому что они всегда будут рассчитывать на весь набор данных, независимо от наших фильтров. Наши агрегаты должны стать немного более сложными, чтобы это работало, нам нужно добавить к ним фильтры. Каждое агрегирование должно рассчитывать на набор данных со всеми применяемыми фильтрами, за исключением собственных. Таким образом, агрегация за счет во Франции рассчитывает на набор данных с применением фильтра категории, но не фильтр стран:
{ "query": { "and": [ { "terms": {"country": ["be", "fr"]} }, { "terms": {"category": ["books", "movies"]} } ] }, "aggregations": { "all_products": { "global": {}, "aggregations": { "countries": { "filter": { "and": [ { "terms": {"category": ["books","movies"]} } ] }, "aggregations": { "filtered_countries": { "terms": {"field": "country"} } } }, "categories": { "filter": { "and": [ { "terms": {"country": ["be","fr"]} } ] }, "aggregations": { "filtered_categories": { "terms": {"field": "category"} } } } } } } }
{ "took": 153, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 3, "max_score": 0, "hits": ["..."] }, "aggregations": { "all_products": { "doc_count": 21, "filterted categories": { "doc_count": 13, "categories": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "movies", "doc_count": 6 }, { "key": "music", "doc_count": 4 }, { "key": "books", "doc_count": 3 } ] } }, "filtered_countries": { "doc_count": 15, "countries": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "fr", "doc_count": 6 }, { "key": "br", "doc_count": 4 }, { "key": "be", "doc_count": 3 }, { "key": "pt", "doc_count": 2 } ] } } } } }
Yii2 framework $terms = QueryHelper:: terms ("categories.name" , "my category" ) ; $nested = QueryHelper:: nested ("string_facet" , QueryHelper:: filter ([ QueryHelper:: term ("string_facet.facet_name" , [ "value" => $id , "boost" => 1 ] ) , QueryHelper:: term ("string_facet.facet_value" , [ "value" => $value , "boost" => 1 ] ) , ] ) ) ; $filter = QueryHelper:: should ($nested ) ;
