А вот еще одна интересная особенность продукта, в какой-то мере раскрывающая и работу "пауков" большого Яндекса. Веб-страницы могут содержать специальный мета-тег robots. Этот мета-тег имеет более высокий приоритет, чем настройки индексатора или директивы управления, заданные в файле robots.txt. То есть если директивы управления в файле robots.txt разрешают индексировать все файлы в каталоге, то блокирующий мета-тег <meta name="robots" content="noindex, nofollow"> может запретить индексирование страницы, находящейся в этом каталоге.

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

AllowMetaRobots — учитывает при индексировании содержимое метатега robots;

IgnoreMetaRobots — игнорирует содержимое мета-тега.

При индексировании документов по протоколу HTTP Яndex.Server поддерживает стандарт исключений для роботов. В соответствии с этим стандартом, правила, управляющие поведением поискового робота, должны располагаться в файле /robots.txt, лежащем в корне веб-сервера. Но и здесь есть обходные маневры (впрочем, обходные лишь для вас, поскольку на свой веб-сервер этот поисковик вы будете устанавливать сами, и сами будете определять, что включать в состав индексируемых документов, а что не включать). Пример конфигурации HTTP-запросов при индексировании хоста приведен в листинге 10.2.

Если вам нужно, чтобы Яndex.Server при индексировании вашего сайта не учитывал общие правила для поисковых роботов, модифицируйте файл robots.txt, добавив специальное правило для User-Agent, заданного при конфигурировании HTTP-запросов. В следующем примере (листинг 10.3) каталог скриптов закрывается от всех роботов, кроме робота MyYandexServer, которому открыто все.

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

Каждая секция DocFormat должна включать обязательную директиву MimeType. Также могут присутствовать необязательные директивы Extensions, Module, Symbol и Config. Директива MimeType задает произвольное имя документного формата, уникально идентифицирующее этот формат. Обычно в качестве идентификатора формата используется так называемый медиа-тип , значения которого специфицированы для большого количества форматов.

Директива Extensions задает расширения файлов данного формата. Если для получения содержимого документа используется файловая система, документы в файлах с заданными расширениями будут считаться имеющими медиатип, указанный в директиве MimeType. Тем не менее если для получения содержимого документа используется веб-сервер, возвращающий заголовок Content-type, в качестве медиа-типа используется значение этого заголовка. Пример секции DocFormat приведен в листинге 10.4.

Одно из важнейших свойств поисковой системы — возможность индексирования файлов произвольного формата. Это обеспечивается с помощью отдельных модулей — парсеров (еще их называют интерпретаторами форматов документов). Для каждого типа файлов применяется свой модуль. В платную версию поисковика включены парсеры для документов в форматах XML, RTF, PDF, MP3, FLASH, MS Word, MS Excel, MS PowerPoint, помимо входящих в стандартную поставку парсеров для форматов text/html и text/plain. Используя спецификацию, независимые разработчики могут разработать и иные парсеры, необходимые для используемых ими форматов данных, однако подключить их можно только к платной версии.

Из всех парсеров, поставляемых с программой, два являются конфигурируемыми. Это парсеры HTML и XML-документов. Остальные используются "как есть". В документации, входящей в комплект поставки, есть разделы, посвященные вопросам настройки парсеров под решение конкретных задач.

У большинства типов документов есть своя внутренняя структура, определенные элементы которой несут свойственную лишь им смысловую нагрузку. В почтовых письмах это могут быть поля from, to, Subj, в вебдокументах — это заголовок, тело документа, ключевые слова. В теле могут присутствовать заголовки различных уровней, ссылки, картинки и т. д. Различные части структурированных таким образом документов в Яндексе называются зонами.

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