Пути обхода временного бана Google за частые обращения к базе

*Гостевой пост

Этот пост посвящен особенностям работы со скриптом nTrendsMaster, массовой проверке выдачи Google на предмет количества конкурентов по нужным запросам и проблеме тайм-аута со стороны Google вообще. Пост очень хорош в плане расширения кругозора (я о многих написанных здесь вещах раньше и понятия не имел 🙂 ) и в некотором роде объясняет причины проблем, которые могут возникнуть у вас во время использования заточенных под Google скриптов и программ (в том числе и Market Samurai).

Пост представляет собой компиляцию из комментариев и переписки с Интернет-предпринимателем Олегом Савченко и публикуется с его разрешения.

—————

Расклад такой (у меня во всяком случае):

• запускаем скрипт и даем ему 100-200 слов – все отрабатывает без проблем…
• запускаем его еще раз с таким же количеством… и еще… если не выдерживать между запусками паузу хотя бы в полчаса, то буквально после 3 запусков (то есть после 400-600 проверенных слов) лезут ошибки по проверке конкурентных страниц ;-((

После того как я тут же пробую искать что-то в гугле, я вижу капчу. Скрипт запускался с Денвера, поэтому капча говорит о том, что мой айпишник на время попал в бан. То есть в ручном режиме я могу ввести код этой картинки дальше какое-то время спокойно пользоваться гуглом. Но в течение еще примерно 5-6 часов эта самая капча может рандомно появляться при любых моих обращениях к Гуглю (а может и не появляться). В любом случае в это время использовать скрипт с этого же адреса не получится, ибо он ни картинку распознать, ни вбить код не сумеет…

Какие я вижу пути решения:

1. Увеличение пауз между запросами к гуглю в скрипте. Но не просто увеличение пауз, а еще и их рандомизация. Многие десктопные приложения (KRA PRO, IBP и другие) не попадают под бан гугля именно поэтому. Однако они ставят между каждым запросом от 7 до 30 секунд перерыва!!! Если просто ставить 5 (7, 10, 15) секунд и все паузы делать одинаковыми, гугль все-равно просекает автоматизацию и выдает капчу ;-((

Чем плох этот путь? Тем что время на проверку скриптом становится сопоставимым со временем на проверку вручную. Но есть и плюсы: ты в это время все равно занимаешься не проверкой, а чем-то другим. Получается “долго, но без тебя”, поэтому вариант имеет право на существование. К сожалению, иногда он все-таки дает сбой. Возможно, потому, что я курлом (функция такая curl в PHP) дергаю страницы, а, может, надо больше под браузер косить (есть и такие библиотеки, которые более-менее точно позволяют эмулировать браузер). Короче, тут есть еще над чем подумать…

2. Использование ключей от гугли. Но проблема здесь в том, что гугль официально больше не поддерживает SOAP API, а всем рекомендует переходить на AJAX API. Я заметил, что результаты в этом случае сильно отличаются от поиска в ручном режиме (в разы, а то и в десятки раз!!!). Вот тут (http://www.google.com/search?hl=en&safe=off&q=ajax+google+api+estimatedResultCount) вы увидите что эта проблема повсеместная… Так что новый API использовать в целях каких-либо SEO исследований крайне не рекомендую.

Что касается старого метода, с использованием Google SOAP Search API, то тут все хорошо: результаты расходятся “в пределах разумного” (на разных гугловых серверах они также расходятся, так что все ОК). НО! Гугль больше не выдает пользователям эти самые “старые” API-шные ключики. А значит написать скрипт, который будет публичным, попросту невозможно.

Народ просек разницу между старыми и новыми ключиками и кинулся старыми торговать… А я еще удивлялся — кому они нужны по 25$-то??? Но вот на forums.digitalpoint.com им именно такая цена назначена. А с одного ключика только 1000 запросов в день можно сделать. У них такой лимит всегда был. То есть, владея одним ключом и скриптом, на базу из 10 000 нужно потратить 10 дней. Ну или купить 10 ключей, но овчинка выделки не стоит. Бесплатный скрипт, который для работы требует дополнительных 250$ на собственные ключики – это не серьезно…

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

К тому же, покупка в онлайне не гарантирует того, что одновременно с тобой этот же самый ключик у того же продавца не купило еще пара десятков покупателей ;-)) и тогда этот ключ становится вообще бесполезным. То есть покупать надо только у проверенных лиц, которые могут гарантировать уникальность продажи. А где же их взять-то?

3. Сочетание первого с работой через прокси. Можно создать несколько одновременных потоков (с разных прокси, т.е. с разных айпи-адресов, они будут приходить на гугль), каждый из которых будет выдерживать разумные паузы и тогда скорость работы всего скрипта увеличится во столько раз, сколько этих самых потоков будет задействовано. Здесь сложность заключается в поиске РАБОТАЮЩИХ и при этом действительно АНОНИМНЫХ прокси, которые бы точно не светили настоящий айпишник перед гуглем. Среди десятков, сотен, а то и тысяч бесплатно доступных списков прокси в интернете после проверки остаются рабочими доли процента. Вот вчера проверял специальной софтинкй более 2000 прокси — работало только около сотни, а анонимными было штук 20… То есть скрипт надо еще оборудовать и такой составляющей, как граббинг списков проксей и их регулярную проверку на работоспособность. А это уже отдельный монстр получается. Я такие работающие системы знаю, даже использую платный скрипт, а вот интегрировать его в этот скрипт напрямую не удастся — только через импорт-экспорт. Впрочем, эта проблема решается, но опять же о массовости использования в этом случае можно забыть. К чему я это все? К тому, что сделать скрипт “для себя” вполне реально. Только нужен свой собственный прокси-чекер или купленные прокси. И то и другое стоит денег.

4. Вариант “для маньяков”. Приобретается 5-6 хостингов с работающими открытыми соединениями для PHP-скриптов (не каждый хостинг это позволяет, т.е. сами скрипты на PHP сейчас повсеместно доступны, а вот чтобы этим скриптам была открыта “дорога” на установку соединений с внешними серверами, это далеко не у всех). Но найти таких провайдеров вполне реально. Затем пишется скрипт, который задание, скажем, из 1000 слов разбивает на 5 порций по 200 и раскидывает на 5 хостингов, где они спокойно в обычном режиме без всяких переделок проверяются. Ведь по 200 слов обычно все проходит… А потом они результаты скидывают обратно в этот “центральный” скрипт, который тебе и выдает объединенную картинку. Это как бы и прокси, и не прокси одновременно 😉 Но цена 5 хостингов – сами понимаете… причем ежемесячно… Проще купить прокси-чекер и с Денвера все запускать…

5. Использование данных от Wordtracker или другого подобного сервиса. У них обычно Competitors довольно близки к данным гугли по США. Популярность ключевых слов нас не интересует, тут нам гугльтрендс в помощь, только данные о конкурентах… Но, опять же, финансовая сторона вопроса…

Вот такой расклад. Я склоняюсь к последнему. То есть в самом скрипте выключить нафиг проверку конкурентов. А прогонять все на поиск нужного количества запросов. И уже “отсеянное” (отбрасываем все, что ищут слишком редко или слишком часто) отправлять на проверку конкурентов. Единственное, что в этом случае получается многоходовая комбинация, а хотелось бы “все и сразу”, но пока этот вариант мне кажется довольно привлекательным (учитывая то, что подписку на вордтрекер или любой другой аналогичный сервис все равно желательно иметь). Но если вордтрекер не по карману – тогда варианты выстраиваются так:

• со старыми ключами (не для всех подходит);
• с прокси и многопоточным выполнением запросов (сложно в изготовлении, но реально);
• с несколькими хостингами (цена может быть сопоставима с ценой вордтрекера).

Записи по теме:

• Вся правда о клоакинге
• Как быстро узнать о взломе блога
• Как Profit Hunter чек обналичивал
• Увеличение конверсии Интернет-магазина