Автор: Дмитрий Васильев, NetCat (Директор)

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

Что не умеет Яндекс

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

Мгновенная переиндексация

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

Синонимы

Название нашего продукта часто пишут по-русски как «неткэт», «неткат», «неткет». Яндексу в голову не придет, что по таким запросам нужно показать страницы, где написано NetCat (кроме запроса «неткат», его Яндекс распознал). Что уж говорить про случаи типа «CMS — цмс, цмска, сиэмэс». А встроенному поиску мы можем явно задавать подобные синонимы.

Управление весом тэгов при расчете коэффициента релевантности

Написание текстов «для Яндекса» имеет кардинальные отличия от написания текстов для людей. В первом случае нам нужно, чтобы из миллиона страниц «на эту тему» Яндекс выше всех показал страницу на нашем сайте. Во втором — чтобы человек, УЖЕ пришедший на сайт, быстро нашел нужную ему страницу и купил наш продукт. Поэтому, если человек ищет на нашем сайте «розовый слоник», нам нужно показать ему не длинную статью с идеально выверенным количеством данных словосочетаний, а страницу с парой фоток и кнопкой «купить». Имея возможность задать веса тэгов и отдельных блоков веб-страниц (например, по атрибуту class) для внутреннего поисковика, мы можем подготовить контент таким образом, чтобы процесс «ввел запрос — купил» занял у пользователя минимум времени.

Гибкое задание запрещенных для индексирования страниц

В файле robots.txt мы можем написать инструкцию Disallow, которая запретит внешним поисковикам индексировать некоторые части сайта. Как показали летние скандалы с попаданием приватной информации в поисковики, это не всегда помогает. Но даже если не брать это в расчет, синтаксис disallow очень примитивен, и было бы куда лучше указать запрещенные области регулярным выражением. Пример: страница sloniki.html?action=add, предназначенная для добавления администратором контента на соответствующую страницу, вполне может попасть в индекс, пусть даже там будет только заголовок «Розовые слоники» и форма авторизации. Но зачем нам замусоривать результаты поиска?

Автоподбор вариантов запроса по мере его ввода

Все знакомы с выпадающим списком, который Яндекс или Гугл показывает нам по мере ввода запроса. Но эта подсказка — лишь список наиболее популярных запросов. Внутренний же поиск может подгружать не только популярные запросы, но и заголовки страниц (то есть названия документов), подходящие под вводимый запрос. Начав вводить «розовы», мы увидим список содержимых тэга title, где содержится этот фрагмент; нажав на нужный нам «Розовые слоники», мы сразу попадем на искомую страницу вместо результатов поиска.

Гибкое расписание переиндексации

Если наш сайт большой, его полная переиндексация может отнять много времени и ресурсов. Но если раздел «Форум» нужно переиндексировать каждый чаc, «Новости» каждый день, а «О компании» вообще никогда, было бы здорово так и делать. Внутренний поиск вполне может позволить себе разные расписания для разных разделов. Конечно, в sitemap мы можем управлять частотой переидексации при помощи атрибута changefreq, но... Вряд ли Яндекс с Гуглом воспримут наше пожелание как инструкцию к действию.



А также:

• указание области поиска (например, искать везде или только на форуме)
• извлечение дополнительных атрибутов из объектов и поиск по ним (найти все статьи такого-то автора, все товары в таком ценовом диапазоне)
• сортировка результатов поиска не только по релевантности, но и по дате (как на Хабре)

... и не только поиск

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

Автоматическое построение sitemap.xml

Кто тщательнее всех составит полный список страниц сайта для внешних поисковиков, как не локальный поисковый робот? При этом, на уровне структуры сайта мы можем задать параметры changefreq и priority, для разных разделов разные.

Поиск битых ссылок

Способов поиска внутренних ссылок на несуществующие страницы как минимум два. Первый — написать обработчик ошибки 404, который будет отправлять письмо с адресом страницы и реферера (или добавлять сообщение в базу сайта) каждый раз, когда кто-то зайдет на такую страницу. Второй — поручить это поисковому роботу. Это явно более правильный способ.

Сбор статистики по запросам

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



Кстати, отдельный пункт — статистика по запросам конкретных зарегистрированных пользователей. Только не подумайте, что я призываю вас за ними следить :)

Не отстаем от «старших»

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

Полноценная морфология

Многие локальные поисковики для работы со словоформами обходятся стеммингом. Этот термин обозначает отбрасывание окончания слова в попытке найти его корень и как следствие — словоформы. Берем слово «розовый», применяем стемминг, получаем «розов», и теперь все слова, начинающиеся на этот «корень», считаем словоформами. Так мы по запросу «розовый» найдем «розовых», «розовые» и пр. Но стемминг дает слишком большую погрешность и не подходит, к примеру, для изолированных глаголов («идти — пошел — дойти»). Наиболее точный поиск словоформ дают морфологические словари. Для текстов бытовой или деловой тематики они не такие большие (NetCat использует бесплатный словарь от aot.ru, русский и английский словари вместе занимают всего 15 мегабайт, что не так много для современных хостингов; можно использовать другие словари; также можно добавлять словари других языков).



Кстати, пользуясь случаем, хочу сказать огромное спасибо автору библиотеки морфоанализа phpMorphy, которая оказалась очень полезной для наших задач. 

Борьба с опечатками

Бороться с опечатками можно двумя способами. Первый — находить наиболее похожее слово, как делает тот же Яндекс, второй — использовать нечеткий поиск.



А вот исправление раскладки клавиатуры — это гораздо проще.

Экзотические случаи

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

RTL-языки и иероглифы

Европейские языки (в т.ч. русский) имеют направление написания слева направо (left-to-right, LTR). Но арабская вязь пишется в обратном направлении. Если ваш проект ориентирован на эту языковую аудиторию, готовьтесь написать (или подключить готовый) стеммер. А иероглифы — вообще отдельный случай, там одним стеммером не обойтись. 

Поиск по закрытым областям

Системы разграничения прав в интернет-проектах встречаются разные, в том числе вполне параноидальные (об этом я хочу написать отдельную статью). Пример сложного варианта: издательские системы. Журналист может иметь права на добавление статьи (в определенные разделы!) и ее коррекцию, пока она не откорректирована редактором. Редактор имеет право на просмотр, коррекцию и включение-выключение всех материалов в рамках своей тематики. Главный редактор не имеет права корректировать заказные статьи без одобрения коммерческого отдела. С точки зрения параноидальной системы разграничения прав идеальный поисковый модуль индексировал бы весь контент, размещенный на проекте, а при поиске проверял бы права пользователя и выводил бы только доступные ему материалы. И при этом позволял бы делать фильтр по статусу документа. 

Автоопределение тематики страниц

Анализируя проиндексированную страницу текста, можно с некоторой долей погрешности определить ее тематику. Полезные эффекты от такой фичи: автоматическая каталогизация материалов и построение облака тэгов, анализ интересов сообщества или отдельных его членов (для UGС-проектов), построение списков связанных материалов (видели блоки «см. также»?). Наиболее же часто такой анализ используется для таргетирования контекстной рекламы.

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

Еще одно интересное применение поисковой машины пришло мне в голову в процессе написание этой статьи. Оно подходит, к примеру, для коллективных блогов и СМИ. Анализируя тексты разных авторов, мы можем строить их рейтинги по разным параметрам. Первое, что приходит в голову: словарный запас. Кроме того: рейтинг авторов-холериков (кто чаще остальных использует восклицательные знаки), любителей пространных рассуждений (кто любит знаки вопроса), по словам-паразитам и т.д. Может, предложить Хабраадминистрации сделать что-то подобное? :) Правда, коммерческое обоснование такой игрушки я пока не придумал.

Если вы пишете свой поиск...

... для начала нужно ответить на вопрос, а нужен ли он, не стоит ли использовать уже имеющиеся решения: Яндекс.Сервер, Sphinx и пр. Главное преимущество собственного поисковика: возможность тесной интеграции с другими модулями CMS, используемой на сайте. Речь не только о встраивании интерфейса управления в админку, а об интеграции с системой разграничения прав, управления структурой, пользователями и пр. (об этом я уже писал).

Что касается технологий, то гибких и мощных платформ хватает. В поисковом модуле NetCat по умолчанию используется Zend_Search_Lucene. У этого решения есть недостатки, например, сравнительно низкая скорость работы. В нашем случае это оправдано тем, что сайт под NetCat должен работать на любом стандартном UNIX-хостинге без необходимости установки дополнительных компонентов, а Zend_Search_Lucene не требуется ничего, кроме PHP. Справедливости ради надо заметить, что мы сделали модуль расширяемым, то есть заменять можно не только словари, но и программные компоненты: если проект достаточно крупный, а сервер выделенный, можно заменять компоненты, отвечающие за хранение и извлечение информации, индексацию, приведение к базовой форме и пр. Например, использовать тот же Sphinx или Solr (а если надо, то и Яндекс.XML).

Если же вы разрабатываете не универсальную CMS, а конкретный крупный проект, выбрать и настроить оптимальную платформу не проблема. Гораздо важнее понять, как использовать ее возможности максимально эффективно.

Все скриншоты в статье сделаны на нашем сайте и в его системе администрирования.

Оригинал статьи: http://habrahabr.ru/company/netcat/blog/136492/