Проверка индексации страницы сайта в Яндекс. Вариант для ленивых.

Последние несколько дней времени на более-менее серьезную работу с Delphi практически не было – все MathCAD да MathLab, сплошные дифуры да теплофизика, поэтому единственное на что выкроил времени сегодня – это добавить небольшую фишку в программу “Пинговалка” – проверку индексации пропингованых страничек в Яндекс и Google. В принципе сама процедура проверки индексации – вещь элементарная до безобразия: отправил запрос, составленный по шаблону, получил код, пропарсил на предмет чего-либо (или строки, информирующей о том, что страница не найдена или, наоборот – что нашлась 1 страница). При этом для парсинга можно использовать что угодно – от возможностей MSHTML до VB RegExp и новинок Delphi XE в виде TRegExp.

Однако, что касается реализации приведенного выше алгоритма на практике, то можно столкнуться с такой нехорошей штукой, как каптча от Яндекса. Хорошо, когда необходимо проверить только одну страничку: попалась каптча – загрузили, заставили пользователя ввести её куда-нибудь, отправили и продолжаем работу. А если страниц, скажем 500 или 1000? Каждый раз вводить каптчу – не резон. Один из вариантов – использование задержек между проверками, списка прокси и т.д. Но, на самом деле, есть ещё два достаточно просто реализуемых варианта о которых и пойдет сегодня речь.

Первый вариант и он же самый правильный, как с точки зрения самого Яндекса, так и с точки зрения точности получения данных – это использование Яндекс.XML. Для тех, кто хотя бы чуть-чуть знает как работать с XML в Delphi, не составит никакого труда отправить POST’ом XML-запрос и разобрать тем же NativeXML ответ сервера.

В чем преимущество этого варианта работы:

1. Абсолютно легален и не нарушает лицензионного соглашения Яндекс;
2. Простота реализации
3. Самая высокая точность и не важно, что вы ищите в Яндексе: информацию про продвижение в блогах или, как в моем случае, проиндексированную страничку своего сайта. Ответ сервера будет по содержанию абсолютно одинаков.
4. Лёгкость парсинга. Достаточно использовать любую библиотеку для работы с XML, чтобы получить результат – никаких регулярных выражений и танцев с бубном вокруг HEX-редакторов.
5. Независимость от интерфейса Web-странички. При использовании регулярных выражений их часто приходится держать, что называется, под рукой, та как малейшая смена представления результатов на странице может потребовать смены регулярного выражения.

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

1. Если Вы не подтвердите в Яндексе номер своего мобильного телефона, то не сможете отправить больше 10 запросов в сутки (IP-шник регистрируется в аккаунте)
2. При подтвержденной мобиле лимит возрастает до 1000 запросов, что так же “не айс”. Например, количество проиндексированных страниц в моем блоге составляет чуть менее 2000 – на проверку уйдет двое суток :).

Так как я не партнер Яндекса по части рекламы и 1000 запросов мне маловато, то пришлось искать другой вариант. Причём такой, чтоб и не сильно париться со всякими прокси и, чтоб по точности не ниже, чем c Яндекс.XML. И, как ни странно, ответ подсказал тот же Яндекс :).

Заходим на вот эту страничку сервиса и что мы наблюдаем? Список сервисов, реализующих поиск через Яндекс.XML. Часть из этих сервисов ищут по всему серверу, т.е. дают возможность парсить выдачу Яндекса практически без запинок на каптчах и прочих методах защиты. Например, тот же TYT.BY реализует полноценный поиск и без проблем пропускает авто-запросы с небольшой задержкой.

Всё, что остается – набрать список сервисов и парсить выдачу в любой удобной последовательности – через  сервис, попеременно по нескольким сервисам, одновременно по пачке сервисов и т.д. и т.п. – возможностей масса.

Какие плюсы у этого метода:

1. Получаем все возможности Яндекс.XML без ограничений по количеству запросов
2. Достаточно высокая точность

Недостатки:

1. Зависимость результата от дизайна страницы с выдачей, т.к. придётся использовать какую-либо библиотеку для парсинга. Обойти можно, но, скажем так, не совсем легко – требуется написать очень уж навороченное регулярное выражение и не факт, что оно будет работать абсолютно всегда.
2. Низкая скорость по сравнению с Яндекс.XML
3. Изменения в работе с Яндекс.XML сервиса может повлиять на результат работы алгоритма в целом.

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

1. Парсинг страницы с выдачей на Яндекс
2. Использование возможностей Яндекс.XML
3. Парсинг страницы выдачи любого сервиса, который использует полноценный поиск через Яндекс.XML

Книжная полка

	Автор: Андрей Шкрыль Название: Разработка клиент-серверных приложений в Delphi Описание: Рассмотрены практические вопросы по разработке клиент-серверных приложений в среде Delphi 7 и Delphi 2005 с использованием СУБД MS SQL Server 2000, InterBase и Firebird. Приведена информация о теории построения реляционных баз данных и языке SQL. Освещены вопросы эксплуатации и администрирования СУБД.
	Автор: Антон Григорьев Название: О чем не пишут в книгах по Delphi Описание: Рассмотрены малоосвещенные вопросы программирования в Delphi. Описаны методы интеграции VCL и API. Показаны внутренние механизмы VCL и приведены примеры вмешательства в эти механизмы. Рассмотрено использование сокетов в Delphi: различные режимы их работы, особенности для протоколов TCP и UDP и др.