Скрипт парсинга выдачи яндекс и гугл. Бессерверный парсер выдачи Google на Javascript. Настройки «Поисковые системы»

Все сталкивались с ситуацией, когда нужно собрать и систематизировать большое количество информации. Для стандартных задач по SEO-оптимизации сайта есть готовые сервисы , например, Netpeak Checker — для сравнения показателей конкурирующих сайтов или Netpeak Spider — для парсинга внутренней информации по сайту. Но что, если задача нетривиальна и готовых решений нет? Есть два пути: делать все руками и долго, или загнать рутинный процесс в матрицу, автоматизировать его и получать результат в разы быстрее. О таком кейсе и пойдет речь.

Познакомиться поближе и получить краткий мануал об использовании можно (на русском) или на moz.com (на английском). Давайте попробуем спарсить что-нибудь хорошее с помощью Kimono. Например, дополним созданную нами таблицу с городами списком курортов в стране Города 2. Как это можно реализовать при помощи Kimono Labs. Нам понадобятся:

• приложение для Google Chrome — Kimono;
• таблица Google Docs.

1. Находим сайт с необходимой нам информацией — то есть перечнем стран и их курортов. Открываем страницу, откуда необходимо получить данные.

2. Кликаем на иконку Kimono в правом верхнем углу Chrome.

3. Выделяем те части страницы, данные из которых нам необходимо спарсить. Если нужно выделить новый тип данных на той же странице, кликаем на «+» справа от «property 1 » — так указываем Kimono, что эти данные нужно разместить в новом столбце.

4. Кликнув на фигурные скобки и выбрав «CSV », можно увидеть, как выбранные данные будут располагаться в таблице.

5. Когда все данные отмечены:

• кликаем «Done » (в правом верхнем углу);
• логинимся в Kimono, чтобы привязать API к своему аккаунту;
• вводим название будущего АРI;
• кликаем «Create API ».

6. Когда API создано, переходим в таблицу Google, куда хотим загрузить выбранные данные. Выбираем «Connect to Kimono » и кликаем на название нашего API — «Resorts ». Список стран и ссылок на страницы с курортными городами выгружается на отдельный лист.

7. Переходим снова на сайт, берем для примера Ирландию, и снова выбираем через Kimono города, которые необходимо спарсить. Создаем API, называем его «Resorts in countries ».

9. В «Crawl Strategy » выбираем «URLs from source API ». Появляется поле с выпадающим списком всех API. Выбираем созданное нами ранее API «Resorts » и из него автоматически загружается список URL для парсинга. Кликаем синюю кнопку «Start Crawl » (начать обход) и следим за статусом парсинга. Kimono обходит страницы, парсит данные по заданному ранее шаблону и добавляет их в таблицу — то есть делает все то же самое, что и для Ирландии, но уже для всех других стран, что ввели автоматически и без нашего участия.

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

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

Например, это можно сделать так . Разметить массив данных (список городов), используя логические функции и возвращая значение ячейке, равное TRUE или FALSE. На примере ниже выделили для себя города, которые находятся именно в Австралии:

• TRUE = город находится в Австралии;
• FALSE = город находится в другой стране.

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

По аналогии можем вывести курортные города и для других стран.

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

Как говорилось вначале, нам регулярно нужно составлять по 20 однотипных таблиц. Это рутинный процесс, съедающий по 40-50 минут на одну таблицу, и по 16 часов времени на каждые 20 шт. Согласитесь, 2 рабочих дня на одинаковые таблички — необоснованная трата времени. После автоматизации на одну таблицу уходит 5-10 минут, а на 20 — около 2 часов. Таблица имеет 17 ячеек, парсинг производится из 5 источников. Заполнение таблицы происходит автоматически при заполнении всего 2 ячеек с исходными данными.

Настройка и автоматизация парсинга суммарно заняла 30 часов времени, то есть потраченное время «окупится» уже на этапе генерации второй 20-ки таблиц.

Этот парсер прост, как трусы по рубль двадцать. И это не только про его возможности (они кстати скромные, ни поддержки прокси, ни антикапчи), а и про интерфейс тоже.

Но на всякий случай расскажу что и куда клацать, чтобы было хорошо:)

1 - Запросы к ПС, построчно. Русские символы вводите как есть, программа сама сделает urlencode. Клик правой кнопкой мыши откроет меню с парой плюшек.

2 - Кликните, чтобы к каждому запросу добавить site:TLD, где список этих самых TLD находится в файле zones.txt.

Нафиг это нужно? Все очень просто, сравним запрос "google parser" с запросом "google parser site:ru"
В первом случае поисковая выдача будет содержать все найденные сайты, а во втором только сайты в зоне ru.
Это полезно, если требуется получить более 1000 результатов. В идеале, для каждой доменной зоны можно получить по 1000 ссылок.
Например , по запросы "парсер google " мы получили только 1000 ссылок.
А если кликнуть "site:TLD", то сможем получить до 11000 ссылок:

3 - Файл, в который будут сохранены найденные ссылки. Если указанный файл существует, то он будет просто дополнен, а не перезаписан.

4 - Файл, в который будут сохранены найденные домены . Если указанный файл существует, то он будет просто дополнен, а не перезаписан.

5 - Интервал задержек между запросами. Лучше не торопить события и выставив что-то между 20-30, пойти сделать себе чай, бутерброд с колбасой и почитать новости, пока программа будет работать:)

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

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

На сервере у нас один IP. Можно докупить еще, но зачем? У нас же еще есть IP"шки клиентов, которые к нам заходят.
Сервер - машинка слабая (в сравнении с клиентскими компами), а брать мощный сервер дорого. Почему бы не использовать мощность зашедшего посетителя, у него в разы больше памяти и вообще...

Можно пилить не на серверном php, а на браузерном JS. Сие значит - все будет происходить по большей части в браузерах, а не на сервере. Так, сервис сможет работать даже на нищебродском бесплатном хостинге. Памяти хватит на любое количество потоков (свою память мы почти не тратим), да и капчи будут лезть для каждого клиента индивидуально (в зависимости от аппетита с его IP).

Сначала я попробовал подгружать гуглю через iframe - не получилось (в заголовках ответа сервера такое запрещено). Только в древнем IntrenetExplorer6 так можно - он не поддерживает запрета (но IE6 это древний ненужный недобраузер).

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

Вот кусок кода оттуда с моими русифицированными комментами
Код:

google.load("search","1") //гловское загрузить (поиск, 1 версии)

//все внути функции (назвать можно как хочется)
function i_want_find(){ //я обозвал "найти все что я хочу"
var searchControl=new google.search.SearchControl(); //создаем новый контроль поиска

//искать в регионе (задается ниже по коду)
var localSearch = new google.search.LocalSearch();
searchControl.addSearcher(localSearch);

//поиски (какие хотим) - ненужное убрать
searchControl.addSearcher(new google.search.WebSearch()); //обычный такой поиск в гугле
searchControl.addSearcher(new google.search.VideoSearch()); //искать видяхи
searchControl.addSearcher(new google.search.BlogSearch()); //рыться в блогах
searchControl.addSearcher(new google.search.NewsSearch()); //найти повод для полит-срача в новостях
searchControl.addSearcher(new google.search.ImageSearch()); //поиск картиночек
searchControl.addSearcher(new google.search.BookSearch()); //книжки можно найти
searchControl.addSearcher(new google.search.PatentSearch()); //поиск патентов (даже их)

//задаем регион поиска для "искать в регионе" (смотри выше где используется)
localSearch.setCenterPoint("New York, NY");

//куда надо выводить результаты (я выведу в div с id="vihlop")
searchControl.draw(document.getElementById("vihlop"));

//повеливаю исполнить запрос и найти наше RuSeo
searchControl.execute("сайт");
}

Google.setOnLoadCallback(i_want_find); //каллбэк длинной функции описанной выше

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

Яндекс такого не дает.

Или я плохо искал. Есть конечно но там требуется рега и получение ключа для своего IP. Или заставлять юзеров получать ключи, или реализовывать на своем сервере.
Во втором случае плохо все: от того что нам понадобится сервер помощнее, до ограничения яндексом количества запросов (за расширение просят платить).
Короче, яндекс опять отстой.

У кого есть идеи "что парсить будем"? Я вообще искал технологию чтобы кэш гугла открывать без php, а описанным выше я такого проделать не смог.

И так для начала нам нужно определиться что мы хотим парсить. Гесты, форумы, определнные CMSки, борды и пр. У всех у них есть определенные отличительные признаки, по которым с помощью операторов Гугла можно найти их в индексе. Сегодня хочу показать вам пример парсинга сайтов на DLE.
Нам понадобиться:
- Пасрес Байрона (Hkey free C++ Google parser) parser.rar (cкачиваний: 79)
-

В аттаче.txt файлом zones.zip (cкачиваний: 51)
- И программа Befouler (строкоизвращатель) befouler.zip (cкачиваний: 64) Внимание! Требует наличия в системной директории Windows библиотеки msvbvm50.dll,
скачать dll можно по ссылке: http://www.filesearch.ru/cgi-bin/s?query=msvbvm50.dll
Думаю ни для кого не секрет, что независимо от того стоит-ли на сайте ЧПУ или нет, DLE можно найти в 99% случаев по форме регистрации.
index.php?do=register

На данный момент гугл мне выдает, что результатов 344 000. Неплохо. Но вся проблема в том, что он показывает только первые 200 результатов. Для того, чтобы спарсить максимальное количество сайтов нужно будет немного подумать и применить некоторые операторы Гугла:
inurl:
Это значит, что будут найдены сайты, вернее страницы, в адресе которых находится указанные нами символы.
site:
Ищет ключевое слово исключительно на страницах указанного сайта или доменной зоны.
intitle:
Ищет страницы, в теге Title которых используется ключевое слово или фраза

Для этого берем наш строкоизвращатель и делаем следующее: (все картинки кликабельны)

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

inurl:"index.php?do=register" site:.

Нажимаем старт и в правом окошке у нас получается исходный код. Копируем его и сохраняем где нам удобно.

Теперь с помощью данных запросов мы сможем увидеть все DLE сайты в каждой указанной нами доменной зоне. Тем самым мы сможем спарсить большее количество сайтов, но их все-равно окажеться мало. Опять-же только в зоне.ru гугл выдает 104 000 сайтов. Для этого нам поможет очередной оператор, это

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

или-же самому написать нужнее слова.

ТОП 1000 в.txt фармате, почищен от п0рн0

top-1000.zip (cкачиваний: 21)

Берем наш файл с ТОП 1000, выбираем пункт "вставить в начало каждой строки" и в "исхондной подстроке" пишем: inurl:"index.php?do=register" site:.ru intitle:"

Далее сохраняем то, что у нас получилось справа, снова открываем его в строкоизвращателе, выбираем пункт "добавить в кажду строку" и добавляем кавычки (") (естественно без скобок). Все, у нас получилось почти 1000 поисковых запросов к Гуглу в зоне.ru, которые помогут нам отобрать максимальное количество сайтов на ДЛЕ из выдачи. По каждому запросу в выдаче от 5 до 50 сайтов, а запросов у нас 1000! Далее просто перебираем через блокнот путем замены самые популярные зоны: .com, .info, .biz, .net Лично я больше не стал брать, думаю этого хватит.

(правка - заменить)

Думаю из скриншота все понятно.

Теперь открываем наш парсер, загружаем для начала наш файл со словами и начинаем парсить. Обязательно поставьте задержку в 11-13 сек (13000) Это поможет вам избавиться от постоянной капчи, но даже если она у вас появляется, в программке есть минибраузер, где вы сможете ввести код капчи и спокойно продолжить парсинг.

После парсинга жмем кнопку "очистить дубли" и вуаля, у нас есть достаточно приличная база сайтов на DLE Не забудьте только отпрарсить другие популярные и просто другие зоны.

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

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

Один из клиентов, заказавших продвижение сайта , в процессе работ по оптимизации продолжал доработку выгрузки товаров из 1С. В связи с этим при каждой выгрузке каталога менялись символьные коды элементов. К ним добавлялась частица «_1», «_2» и т.д. При этом каждая выгрузка успевала частично проиндексироваться.

Итог: мы получили в индексе около 4 000 страниц, 3 600 из которых оказались битыми и отдавали 404 ошибку.

Ни для кого далеко не секрет, что в Яндекс и Google существует ограничение на парсинг выдачи в 1 000 элементов. Здесь мы сталкиваемся с первой проблемой: как спарсить 4 000 страниц при ограничении в 1000? Именно в этом случае на помощь и приходит ComparseR.

Если на сайте корректная ссылочная структура и все страницы можно найти по ссылкам на страницах (во втором случае рассмотрим ситуацию, когда это не так), то в первую очередь необходимо провести сканирование сайта с помощью краулера и построить дерево текущей структуры:

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

Отправляем все несуществующие страницы на удаление с помощью функции «Добавить/Удалить URL» и оставляем сайт индексироваться.

У интернет-магазина были разные разделы для розничных и корпоративных клиентов. При этом ассортимент их пересекался примерно на 40%, а оставшиеся 60% товаров корп. раздела вполне могли пригодиться и розничным покупателям. Было решено объединить их, и, чтобы не потерять аудиторию из поиска, которая шла на корпоративный раздел, настроить 301 редиректы.

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

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

Благо, ComparseR после версии 1.0.77 научился делать произвольные запросы к выдаче. Именно это нас и спасло. Страниц товаров в корпоративном разделе было проиндексировало около 1 800, корректной структуры, чтобы построить дерево, также не осталось из-за удаления корпоративного каталога. Пришлось взять страницу раздела из кэша Яндекса и вручную скопировать все урлы его подразделов.

После этого отправляем произвольные запросы по очереди к обеим поисковым системам:

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

Результатом стал готовый список наименований товаров, по которому программисты уже вытащили корректные url перемещенных в розничный раздел элементов и сопоставили их со списком спарсеyных страниц. Задача решена.