» »

На чем лучше реализовать фасетный поиск. PINQ - Опрашиваемые наборы данных. Фасеточный поиск. Решения для фасетной навигации
11.04.2020

Мы кратко рассмотрели установку и базовый синтаксис PINQ, портированную на PHP версию LINQ. В этой статье мы рассмотрим, как использовать PINQ для имитации возможности фасеточного (аспектного) поиска в MySQL.

В этой статье мы не будем рассматривать все аспекты фасеточного поиска. Интересующиеся люди могут поискать подходящую информацию в интернете.

Типичный фасеточный поиск работает следующим образом:

  • Пользователь вводит ключевое слово, или несколько ключевых слов для поиска. Например, “маршрутизатор” для поиска продуктов, у которых в слово “маршрутизатор” встречается в описании, ключевых словах, названии категории, тегах и проч.
  • Сайт возвращает список продуктов, подходящих под эти критерии.
  • Сайт предоставляет несколько ссылок для подстройки условий поиска. Например, может позволить указать конкретных производителей маршрутизаторов, либо задать диапазон цен, или другие особенности.
  • Пользователь может продолжать указывать дополнительные критерии поиска для того, чтобы получить интересующий его набор данных.

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

К сожалению, фасеточный поиск не встроен в MySQL. Так что же нам делать, если мы всё-таки используем MySQL, но хотим дать пользователю такую возможность?

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

Расширяем демонстрационный пример из первой части

Замечание : весь код из этой части, и из первой части, можно найти в репозитории .

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

Начнём с index.php , добавив в него следующие строки:

$app->get("demo2", function () use ($app) { global $demo; $test2 = new pinqDemo\Demo($app); return $test2->test2($app, $demo->test1($app)); }); $app->get("demo2/facet/{key}/{value}", function ($key, $value) use ($app) { global $demo; $test3 = new pinqDemo\Demo($app); return $test3->test3($app, $demo->test1($app), $key, $value); });

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

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

Но в этом примере мы не будем реализовывать такое поведение - все фильтры будут отражать граничные значения оригинального набора данных. Это первое ограничение и первый кандидат на улучшение в нашем демонстрационном примере.

Как видно в вышеприведённом коде, реальные функции располагаются в другом файле, под названием pinqDemo.php . Давайте взглянем на соответствующий код, который предоставляет возможность фасеточного поиска.

Класс аспекта

Первым делом создадим класс, представляющий аспект. В целом, аспект должен содержать несколько свойств:

  • Данные, которыми он оперирует ($data )
  • Ключ, по которому производится группировка ($key )
  • Тип ключа ($type). Может быть одним из следующих:
    • указывать полную строку, для точного совпадения
    • указывать часть строки (обычно - начальную), для поиска по шаблону
    • указывать диапазон значений, для группировки по диапазону
  • если тип ключа - диапазон значений, необходимо определить шаг значения для определения нижней и верхней границы диапазона; или же если тип - часть строки, необходимо указать, сколько первых букв будет использоваться для группировки ($range)

Группировка - наиболее критичная часть аспекта. Вся агрегированная информация, которую, возможно, сможет вернуть аспект, зависит от критериев группировки. Обычно наиболее используемыми критериями поиска являются “Полная строка”, “Часть строки”, или “Диапазон значений”.

Namespace classFacet { use Pinq\ITraversable, Pinq\Traversable; class Facet { public $data; // Оригинальный набор данных public $key; // поле, по которому производится группировка public $type; // F: вся строка; S: начало строки; R: диапазон; public $range; // играет роль, только если $type != F ... public function getFacet() { $filter = ""; if ($this->type == "F") // вся строка { ... } elseif ($this->type == "S") // начало строки { ... } elseif ($this->type == "R") // диапазон значений { $filter = $this->data ->groupBy(function($row) { return floor($row[$this->key] / $this->range) * $this->range; }) ->select(function (ITraversable $data) { return ["key" => $data->last()[$this->key], "count" => $data->count()]; }); } return $filter; } } }

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

Задаём аспекты и отображаем исходные данные

Public function test2($app, $data) { $facet = $this->getFacet($data); return $app["twig"]->render("demo2.html.twig", array("facet" => $facet, "data" => $data)); } private function getFacet($originalData) { $facet = array(); $data = \Pinq\Traversable::from($originalData); // 3 примера создания различных объектов аспектов, и возврат аспектов $filter1 = new \classFacet\Facet($data, "author", "F"); $filter2 = new \classFacet\Facet($data, "title", "S", 6); $filter3 = new \classFacet\Facet($data, "price", "R", 10); $facet[$filter1->key] = $filter1->getFacet(); $facet[$filter2->key] = $filter2->getFacet(); $facet[$filter3->key] = $filter3->getFacet(); return $facet; }

В методе getFacet() мы делаем следующее:

  • Конвертируем оригинальные данные в объект Pinq\Traversable для последующей обработки
  • Создаём три аспекта. Аспект ‘author’ будет группировать по полю author , и реализует группировку по всей строке; аспект ‘title’ - по полю title с группировкой по части строки (по первым 6 символам); аспект ‘price’ - по полю price с группировкой по диапазону (с шагом 10)
  • Наконец, извлекаем аспекты и возвращаем их функции test2 , чтобы их можно было вывести в шаблон для отображения

Вывод аспектов и отфильтрованных данных

В большинстве случаев фильтры будут отображены в виде строки, и будут вести к просмотру отфильтрованного результата.

Мы уже создали маршрут ("demo2/facet/{key}/{value}") для вывода результатов фасеточного поиска и ссылок фильтров.

Маршрут принимает два параметра, в зависимости от ключа, по которому производится фильтрация, и от значения для этого ключа. Функция test3 , которая привязана к этому маршруту, представлена ниже:

Public function test3($app, $originalData, $key, $value) { $data = \Pinq\Traversable::from($originalData); $facet = $this->getFacet($data); $filter = null; if ($key == "author") { $filter = $data ->where(function($row) use ($value) { return $row["author"] == $value; }) ->orderByAscending(function($row) use ($key) { return $row["price"]; }) ; } elseif ($key == "price") { ... } else //$key==title { ... } return $app["twig"]->render("demo2.html.twig", array("facet" => $facet, "data" => $filter)); }

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

Наконец, мы отображаем исходные данные (вместе с фильтрами) в шаблоне. Этот маршрут использует тот же шаблон, который мы использовали в " demo2 ".

Search Bar

    {% for k, v in facet %}
  • {{k|capitalize}}
      • {% for vv in v %}
    • {{vv.count}}{{vv.key}}
      • {%endfor%}
    {%endfor%}

Нужно помнить, что аспекты, генерируемые нашим приложением, являются вложенными массивами. На первом уровне это массив всех аспектов, и, в нашем случае их три (соответственно, для author , title , price).

У каждого аспекта есть массив “ключ-значение”, так что мы можем итерировать его обычными методами.

Заметьте, как мы строим URL для наших ссылок. Мы используем и ключ внешнего цикла (k), и ключи внутренних циклов (vv.key) в качестве параметров для маршрута ("demo2/facet/{key}/{value}"). Размер массивов (vv.count) используется для отображения в шаблоне.

На первом изображении представлен изначальный набор данных, а на второй - отфильтрованный по диапазону цен от 0$ до 10$, и отсортированный по автору.

Здорово, у нас получилось имитировать фасеточный поиск в нашем приложении!

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

Возможные улучшения

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

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

Ограничения

Фасеточный поиск, реализованный в этой статье, имеет серьёзные ограничения (что, возможно, относится и к другим реализациям фасеточного поиска):

Мы каждый раз выбираем данные из MySQL

Это приложение использует фреймворк Silex. Как и в любом фреймворке с единой точкой входа, вроде Silex, Symfony, Laravel, его файл index.php (или app.php) вызывается каждый раз, когда происходит анализ маршрута, и выполняются функции контроллера.

Если посмотреть в код в нашем index.php , можно обратить внимание, что следующая строчка кода:

$demo = new pinqDemo\Demo($app);

вызывается каждый раз, когда отображается страница приложения, что значит, что каждый раз выполняются следующие строки кода:

Class Demo { private $books = ""; public function __construct($app) { $sql = "select * from book_book order by id"; $this->books = $app["db"]->fetchAll($sql); }

Будет ли лучше, если мы не будем использовать фреймворк? Что ж, несмотря на факт того, что разрабатывать приложения без фреймворков, является не очень хорошей идеей, могу сказать, что мы встретимся с теми же проблемами: данные (и состояние) не сохраняются между разными HTTP запросами. Это фундаментальная характеристика HTTP. Этого можно избежать, используя механизмы кеширования.

Мы сэкономили несколько SQL запросов, используя аспекты. Вместо того, чтобы передать один select запрос на выборку данных, и три запроса group by с соответствующими условиями where , мы выполнили только один запрос where , и использовали PINQ для получения агрегированной информации.

Заключение

В этой части мы реализовали возможность фасеточного поиска по коллекции книг. Как я и сказал, это всего лишь маленький пример, который есть куда ещё улучшать, и у которого есть ряд ограничений.

Умный фильтр или Фасетный поиск – это фильтр по категориям товара, которую можно видеть в крупных интернет магазинах и том же яндекс.маркете. Он помогает последовательно сортировать товары с нужными пользователю свойствами, отсеявая все лишнее. Это очень удобная опция, позволяющая быстро найти нужный товар или материал на сайте.

И так давайте перейдем непосредственно к установке и настройке нужных нам модулей

Для начала нам понадобятся скачать и установить следующие модули: Search API , Search API Database Search , Entity API и Views .

На странице модулей включаем:

  • Search API
  • Search views
  • Database search
  • Entity API
  • Views
  • Views UI
  • Ctools

Создание поискового сервера

Идем в Конфигурация > Поиск и метаданные > Search API (/admin/config/search/search_api) и нажимаем Добавить сервер .
Затем вводим имя сервера, в выпадающем списке Класс сервиса (Service class) выбираем Database service и сохраняем.

Создание индекса

Идем в Конфигурация > Поиск и метаданные > Search API (/admin/config/search/search_api), жмем Добавить сервер (Add index) .
Вводим название индекса, в поле Тип элемента (Item type) выбираем ‘Материал ‘, в поле Сервер выбираем Database server , жмем Создание индекс.


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

В следующей открывшейся форме Фильтры (workflow) я оставил все по умолчанию, переходим на вкладку Просмотр (Status ), и нажимаем Индексировать сейчас (Index Now ).
После завершения индексации, создадим страницу поиска.

Создание страницы поиска

Идем в Structure > Views и жмем Добавить новое представление (Add new view) .
В новом представление в выпадающем списке Показать (Show) выбираем ранее созданный нами индекс, остальные поля (название, title и путь) заполняете так как вам нужно.


Далее нажимаем Сохранить и настроить (Continue & edit), настраиваем представление как обычно. В критериях фильтрации я добавил показ только опубликованных материалов и нужный тип node и настроил отображение необходимых полей (нужно добавить эти поля в индекс, чтобы иметь возможность фильтровать по ним).

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

A/search_api_ranges.module +++ b/search_api_ranges.module @@ -144,11 +144,8 @@ function search_api_ranges_minmax($variables, $order = "ASC") { // otherwise our min/max would always equal user input. $filters = &$query->getFilter()->getFilters(); foreach ($filters as $key => $filter) { - - // Check for array: old style filters are objects which we can skip. - if (is_array($filter)) { - if ($filter == $variables["range_field"] || ($filter != $variables["range_field"] && $filter == "")) { - $current_filter = $filters[$key]; + if(isset($filter->tags) && is_array($filter->tags)){ + if(in_array("facet:".$variables["range_field"], $filter->tags)){ unset($filters[$key]); } }

Патчим JQuery UI Slider: настраиваем редирект

В версии модуля 7х-1.5 я столкнулся с тем, что если виджет слайдера расположен на странице, отличной от страницы поиска, то после изменения диапазона цены проиходило пере направление на текущую страницу, а не на страницу поиска.
Ошибка кроется в функии search_api_ranges_block_slider_view_form_submit() (файл search_api_ranges.module, строка 364).
Я не стал особо разбираться, что там и зачем, просто немного изменил код в строке 427:

Drupal_goto($path, array("query" => array($params), "language" => $language)); + drupal_goto($values["path"], array("query" => array($params), "language" => $language));

после чего проблема решилась.

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

Примечание: Механизм фасетного поиска доступен с версии 15.0.1 модуля Информационные блоки и интегрирован с компонентом Компонент - это программный код, оформленный в визуальную оболочку, выполняющий определённую функцию какого-либо модуля по выводу данных в Публичной части. Мы можем вставлять этот блок кода на страницы сайта без непосредственного написания кода. Умный фильтр Компонент подготавливает фильтр для выборки из инфоблока и выводит форму фильтра для фильтрации элементов. Компонент должен подключаться перед компонентом вывода элементов каталога, иначе список элементов фильтроваться не будет. Компонент стандартный, входит в дистрибутив модуля и содержит три шаблона: .default , visual_horizontal и visual_vertical . (Последние два шаблона не поддерживаются, остались для сохранения совместимости.)

В визуальном редакторе компонент расположен по пути Контент > Каталог > Умный фильтр .

Компонент относится к модулю Информационные блоки.

Подробнее о фасетном поиске

Создадим фасетные индексы за несколько простых действий:

Нужно ли пересоздавать фасетные индексы?

Фасетные индексы пересоздаются автоматически или требуется пересоздать их вручную в зависимости от произведенных действий:

Автоматически Добавили новые или отредактировали существующие товары .
не создают новых свойств.
Вручную Система подскажет вам об этом с помощью сообщения вверху страниц
административного раздела.
 		Добавили новые или отредактировали разделы каталога .
При добавлении нового или удалении свойства из умного фильтра .
При выгрузке товаров, например, из 1С, если товары создают новые свойства.

Фасетный поиск улучшает работу каталога товаров. Для его использования необходимо:

  1. Создать фасетные индексы для каталога с товарами;
  2. Следить за оповещением о необходимости пересоздания индексов вручную.

Фасетная навигация – это проблема всех e-commerce сайтов. Чрезмерное количество страниц, которые используются для разных вариантов одного и того же элемента, создает угрозу эффективности поиска. Это может негативно повлиять на SEO и пользовательский опыт. Что такое фасетная навигация, и как ее улучшить, рассказали специалисты из блога SEO Hacker.

Фасетная навигация: определение

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

Фасеты и фильтры отличаются друг от друга. Вот в чем заключается разница:

  • Фасеты – индексированные категории. Они помогают уточнять списки товаров и действуют как расширение основных категорий. Фасеты добавляют уникальное значение для каждого выбора, который делает пользователь. Так как фасеты индексированы, они должны отправлять релевантные сигналы поисковой системе, гарантируя, что страница содержит все важные атрибуты.

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

Потенциальные проблемы

У каждой возможной комбинации фасетов есть собственный уникальный URL-адрес. Он может стать причиной некоторых проблем с точки зрения SEO. Вот основные из них:

  • Дублированный контент.
  • Трата бюджета на сканирование.
  • Устранение разницы в ссылках.

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

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

Решения для фасетной навигации

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

AJAX

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

AJAX может быть эффективен только до запуска сайта e-commerce. Для решения проблем уже существующих ресурсов он не используется. Также этот метод требует определенных трат с вашей стороны.

Тег noindex

Тег noindex используется для того, чтобы боты исключили определенную страницу из индекса. Таким образом она не будет отображаться в результатах поиска Google. Это позволяет уменьшить количество дублированного контента, отображаемого в индексе и результатах поиска.

Это не решит проблемы с бюджетом на обход, потому что боты все равно будут посещать вашу страницу. Это также не помогает распределить ценность ссылок.

Атрибут rel=canonical

С помощью этого атрибута вы сообщаете Google, что у вас есть одна основная предпочтительная страница для индексирования и ранжирования, а все остальные версии контента с этой страницы – всего лишь дубликаты, которые не нужно индексировать.

София Ибрагимова

Контент-маркетолог

Если на одну и ту же страницу вашего сайта можно попасть по нескольким URL-адресам, поисковые роботы будут расценивать каждый адрес как отдельную страницу. Боты решат, что контент на вашем сайте неуникален, а это отрицательно скажется на ранжировании и снизит ваши позиции в выдаче. Чтобы этого избежать, укажите основную каноническую страницу, вставив в блок HEAD следующую последовательность символов:

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

Robots.txt

Закрытие части страниц от индексации позволяет добиться хороших результатов. Это простой, быстрый и надежный способ. Удобнее всего установить настраиваемый параметр для указания всех возможных комбинаций фасетов и фильтров, которые вы хотите заблокировать. Включите его в конец каждого URL-адреса, который хотите скрыть (http://полный адрес страницы/robots.txt) или используйте метатег Robots в области HEAD кода страницы.

При изменении в URL-адресе необходимо помнить, что роботам требуется 3-4 недели, чтобы заметить эти изменения и среагировать на них.

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

Консоль Google Search

Это отличный способ временно исправить свои проблемы, пока вы работаете над созданием более совершенной и удобной системы навигации. Вы можете использовать консоль Google Search, чтобы сообщить поисковику, как сканировать ваш сайт.

  • Нажмите на кнопку «Параметры URL» (URL Parameters):

  • Укажите влияние каждого из ваших параметров на страницу и то, как Google должен обрабатывать эти страницы.

Помните, что этот способ скрывает дублированный контент только от поисковых роботов Google. В Bing и Yahoo станицы по-прежнему будут отображаться.

Как улучшить фасетную навигацию

Рассмотрим вкратце все методы, которые позволяют создать правильную фасетную навигацию:

  • Использование AJAX
  • Удаление или скрытие ссылок на категории или страницы фильтров, на которых отсутствует контент.
  • Разрешение индексирования определенных комбинаций фасетов, которые имеют большой объем поиска трафика
  • Установка иерархии сайтов через хлебные крошки в категориях и подкатегориях.
  • Создание канонических (основных) страниц для дублированного контента.
  • Консолидация индексирующих свойств со страниц компонентов на весь ряд с помощью разметки страницы с rel = "next" и rel = "prev" .

Заключение

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

В данной статье (уровень веб-мастера - продвинутый) речь пойдёт о, пересекающейся по разным признакам, т.н. "фасетной" навигации. Для упрощения усвоения материала рекомендую пробежаться по статье в Википедии "Фасетная классификация " и публикации на английском языке (но с картинками!) "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 дают большую гибкость для поисковых систем, чтобы определить, как эффективно сканировать)
Поисковым роботам трудно дифференцировать полезные значения (например, "gummy-candy") от бесполезных (например, "SESSIONID"), когда эти значения помещаются непосредственно в пути ссылки. С другой стороны, параметры URL обеспечивают гибкость для поисковых систем, чтобы быстро проверить и определить, когда данное значение не требует доступ сканирующего робота (краулера) ко всем всем вариантам.

Общие значения, которые не меняют содержимое страницы и должны быть перечислены в качестве параметров URL, включают:

  • ID сессии
  • Отслеживание идентификаторов
  • Referrer идентификаторы
  • Отметки времени
Пример №3 : Преобразование созданных пользователями значений (возможно бесконечных) в параметры URL, которые доступны для сканирования и индексирования, но бесполезны для поиска.
Использование незначительных данных, генерируемых пользователями сайта (например, как долгота/широта или "дней назад"), в сканируемых и индексируемых адресах:
  • 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
Вместо того, чтобы позволить пользователем генерировать значения для создания сканируемых URL-адресов (что приводит к бесконечным возможностям с очень небольшой ценностью для посетителей), лучше публиковать категорию страницы для наиболее популярных значений, вдобавок можно включать дополнительную информацию, чтобы страница представляла большую ценность, чем обычная поисковая cтраница с результатами. Кроме того, можно подумать о размещении сгенерированных пользователем значениях в отдельном каталоге, а затем через robots.txt запретить сканирование из этого каталога.
  • example.com/filtering/ find-a-doctor?radius=15&latitude=40.7565068&longitude=-73.9668408
  • example.com/filtering/ articles?category=health&days-ago=7
И в robots.txt:
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
Посторонние параметры URL только увеличивают дублирование, в результате сайт менее эффективно сканируется и индексируется. Поэтому необходимо избавляться от ненужных параметров URL и периодически заниматься уборкой мусорных ссылок перед генерацией новых URL. Если многие параметры необходимы для пользовательского сеанса, можно скрыть информацию в куки, а не постоянно добавлять значения, как cat=gummy-candy&cat=lollipops&cat=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 ...
Рассмотрим реализацию одного из нескольких вариантов конфигурации для URL-адресов, которые содержат ненужные параметры. Просто убедитесь, что "ненужные" параметры URL действительно не требуются для сканирования поисковым роботам или для нахождения пользователем каждого отдельного продукта!

Вариант 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" ") .
Включите только канонические ссылки в файлы Sitemap .
Похожие статьи:
Категории
Популярное