«Сначала договоримся о терминологии», — так любил начинать разговор мой декан, преподаватель дискретной математики. Те времена уж позади, но я с ним согласен. Итак — о терминологии.
Любой, даже самый что ни на есть начинающий «манимейкер» понимает, что заработать на своем сайте (блоге, форуме, портале) он сможет только при наличии на нем посетителей, т.е. трафика. Привлечение пользователей поисковых систем Google, Яндекс и им подобных требует манипуляций, благодаря которым сайт манимейкера оказывается в Топе выдачи, т.е. результатов поиска.
Основная задача оптимизатора — правильный выбор ключевых слов («кейвордов»).
ПРАВИЛЬНЫЕ кейворды должны быть релевантны, относительно высоко искабельны и относительно низкоконкурентны.
Поиск релевантных кейвордов — это отдельная тема. Есть специальные базы данных (не бесплатные, разумеется), есть публично доступные сервисы вроде — публичность подразумевает ограниченность функционала, но не всегда и не везде. В общем, это не тема данного мастер-класса, об этом можем поговорить в другой раз. А вот о проверке частоты запросов и количества конкурентов — о том, к чему я и вел разговор, — читайте в следующей части.
Есть целый ряд программных продуктов, позволяющих манимейкеру проверять параметры кейвордов. Разумеется, они тоже бывают платные и бесплатные, вот об одном из бесплатных скриптов, а именно о nTrendsMaster, мы и поговорим. Он всем хорош (подробно о нем можно почитать ):
Разумеется, в бочке меда не обошлось без ложки дегтя. Дело в том, что при большом количестве проверяемых кейвордов довольно быстро наступает момент, когда в результатах мы видим сплошные нули или ошибки. Примерно через 200-300 запросов.
Это связано с тем, что Google, получая от одного и того же компьютера десятки запросов в секунду, идентифицирует вас как робота. А поскольку сервис Google не предназначен для марсиан или роботов, он прекращает обслуживать эти запросы. На практике это выглядит так, как будто вас предупреждают о вирусной опасности (см. скриншот), но на самом деле это обычная капча.
Таким образом, вы даете понять, что, прежде всего, ВИДИТЕ это сообщение, ну и что вы способны понять, о чем там шла речь. То есть, что вы не робот.
Для программных продуктов, которые собирают автоматически те или иные данные с Google, эта страница становится непреодолимым препятствием (есть конечно умельцы, но для большинства эта ситуация неразрешима). Это и есть бан Google.
Применительно к конкретному скрипту nTrendsMaster, расклад такой (у меня, во всяком случае):
После того как я тут же пробую искать что-то в Googleвручную, в моем браузере появляется капча. Скрипт запускался с Denwer’а, поэтому капча говорит о том, что адрес моего компьютера на время попал в бан. То есть в ручном режиме я могу ввести код этой картинки и дальше какое-то время спокойно пользоваться Google. Но в течение еще примерно 5-6 часов эта самая капча может рандомно появляться при любых моих обращениях к Google (а может и не появляться). В любом случае, в это время использовать скрипт с этого же адреса не получится, ибо он ни картинку распознать, ни вбить код не сумеет.
И что-то с этой ситуацией надо делать. О том, какие я вижу пути решения, читайте в следующей части мастер-класса.
1. Увеличение пауз между запросами к Google в скрипте. Но не просто увеличение пауз, а еще и их рандомизация. После анализа работы нескольких десктопных приложений, занимающихся в том числе и автоматическими запросами к Google (KRA PRO, IBP и другие) можно сделать вывод, что их работа не вызывает бан Google именно поэтому. Если просто ставить паузу в 5 (7, 10, 15) секунд и все паузы делать одинаковыми, Google все равно довольно быстро обнаруживает работу автоматической проверки и выдает капчу. Однако они делают перерыв между каждым запросом от 7 до 30 секунд в случайном порядке выбирая интервалы — и это позволяет им сохранять работоспособность!
Чем плох этот путь? Тем, что время на проверку скриптом становится сопоставимым со временем на проверку вручную. Но есть и плюсы: манимейкер в это время все равно не занимается проверкой, а делает что-то другое, что ему нужно.
Получается «долго, но без тебя», поэтому вариант имеет право на существование. К сожалению, иногда он все-таки дает сбой. Возможно, потому, что в тестах я использовал функцию curl для получения ответов от сервера Google, а, может быть, надо больше стараться имитировать реальную работу браузера (есть и такие функции или целые их библиотеки вроде Snoopy, которые более-менее точно позволяют эмулировать браузер). В общем, тут есть еще над чем подумать...
2. Использование API-ключей от Google. Есть такие программные решения, которые поисковая система сама официально предлагает разработчикам. Они как раз ориентированы на автоматическую работу, а не на ручную. Казалось бы, это именно то, что нам надо! Но проблема здесь в том, что Google официально больше не поддерживает SOAP API, а всем рекомендует переходить на AJAX API (объяснение разницы этих подходов не входит в рамки этого мастер-класса). Я заметил, что выдача в этом случае сильно отличается от результатов поиска в ручном режиме (в разы, а то и в десятки раз!!!).
Вот можно видеть, что эта проблема повсеместна. Так что новый API использовать в целях каких-либо SEO-исследований крайне не рекомендую. Что касается старого метода, с использованием Google SOAP Search API, то тут все хорошо: результаты расходятся «в пределах разумного» (на разных серверах Google они также расходятся, так что все ОК). НО! Google больше не выдает пользователям эти самые «старые» API-шные ключи. А значит, переделать имеющийся скрипт, чтобы он при этом остался бесплатным и публично-доступным, попросту невозможно.
Кстати, манимейкеры довольно быстро поняли разницу между старыми и новыми ключами. И превратили старые еще в один товар ;-) Так что сейчас «старые» API-ключи на forums.digitalpoint.com продаются примерно по 25$ за штуку. С помощью одного такого ключа можно сделать только 1000 запросов в день — таков их официальный лимит. То есть, владея одним ключом и работающим с ним скриптом, на проверку базы из 10000 кейвордов нужно потратить 10 дней. Или купить 10 ключей, но тогда овчинка выделки не стоит. Бесплатный скрипт, который для работы требует дополнительных 250$ на собственные ключи — это несерьезно. Впрочем, тем, у кого есть запасы старых ключей, имеет смысл обратить внимание на такую возможность. Но это никак не для публичного доступа.
Вообще к покупке ключей я бы рекомендовал относиться крайне осторожно. Потому что одновременно с вами этот же самый ключ у того же самого продавца могли купить еще пара десятков покупателей. И тогда этот ключ становится вообще бесполезным. То есть покупать надо только у проверенных лиц, которые могут гарантировать уникальность продажи.
3. Сочетание первого варианта с работой через прокси. Можно создать несколько одновременных потоков (с разных прокси, т.е. с разных IP-адресов, будут приходить на Google поисковые запросы).
Каждый из потоков будет выдерживать разумные паузы и тогда скорость работы всего скрипта увеличится пропорционально количеству задействованных потоков. Здесь сложность заключается в поиске РАБОТАЮЩИХ и при этом действительно АНОНИМНЫХ прокси, которые бы точно не светили настоящий адрес компьютера перед Google.
Среди десятков, сотен, а то и тысяч бесплатно доступных списков прокси в интернете после проверки остаются рабочими доли процента. Вот, например, при последней проверке специальной программой «прокси-чекером» более 2000 прокси — работало только около сотни, а анонимными было штук 20. Это значит, что скрипт надо еще оборудовать и такой составляющей, как получение списков прокси-серверов с общедоступных ресурсов и их регулярную проверку на работоспособность.
А это уже отдельный монстр получается. Я такие работающие системы знаю, даже использую один платный скрипт, но вот интегрировать его в этот скрипт напрямую не удастся — только через импорт-экспорт.
Впрочем, эта проблема решается, но опять же, о массовости использования в этом случае можно забыть. К чему я это все? К тому, что сделать скрипт «для себя» вполне реально. Только нужен свой собственный прокси-чекер или купленные прокси. И то и другое стоит денег.
4. Вариант «для маньяков». Приобретается 5-6 хостингов с работающими открытыми соединениями для PHP-скриптов (не каждый хостинг это позволяет, т.е. сами скрипты на PHP сейчас повсеместно доступны, а вот чтобы этим скриптам была открыта «дорога» на установку соединений с внешними серверами, это далеко не у всех). Но найти таких провайдеров вполне реально. Затем пишется скрипт, который задание, скажем, из 1000 кейвордов разбивает на 5 порций по 200 слов и раскидывает на 5 хостингов, где они спокойно в обычном режиме без всяких переделок проверяются. Ведь по 200 слов обычно все работает и без особых пауз. А потом эти разнесенные по сети скрипты результаты возвращают обратно в «центральный» скрипт, который и выдает объединенную картинку.
Это как бы и прокси, и не прокси одновременно ;-) Но цена 5 хостингов — сами понимаете... причем ежемесячно... Проще купить прокси-чекер и с Denwer’а все запускать...
5. Использование данных от Wordtracker или другого подобного сервиса. У них обычно количество компетиторов довольно близки к данным Google по США. Также они выдают и количество поисков по кейвордам, но эти данные собираются и высчитываются довольно хитрым образом, который, к тому же, вообще не связан с данными от Google, так что эти сведения от них нам не интересны. Данные о количестве поисков по кейвордам нам даст обсуждаемый скрипт nTrendsMaster. То есть просто берем от такого платного сервиса данные о компетиторах, фильтруем их по своим требованиям (отбрасываем слишком уж высококонкурентные), а то, что осталось, отдаем нашему скрипту на проверку, при этом в нем выключаем проверку компетиторов и не боимся бана Google. Но, опять же, финансовая сторона вопроса остается.
На этом бесплатные (или близкие к бесплатным) варианты закончились. Теперь остались «платные» и «дорогие», причем это две разных категории, но об этом в следующем разделе мастер-класса.
Сначала о дорогих — это покупка готовых, собранных за вас, данных о кейвордах. Мне известны продавцы таких баз данных объемом по 40, 60 и 180 миллионов кейвордов.
Страшно представить! И стоит это тоже не мало. Впрочем, тем, кто эти базы покупает, они, видимо, действительно нужны. При соответствующем походе они должны себя многократно окупать. Но у нас речь идет о начинающих манимейкерах. Вот вы, к примеру, знаете, как окупить базу стоимостью в 400$ за следующий месяц? К тому же, эти данные имеют определенный срок жизни. Их могли собрать год назад, тогда к нынешнему положению вещей эти данные могут иметь весьма опосредованное отношение.
Что же касается платных, но не таких дорогих вариантов, то в ходе дискуссии по поводу этого вырисовались следующие возможности:
Плюс, для корректной работы этого подхода нужен определенным образом подготовленный хостинг (скомпилированный с нужными параметрами интерпретатор PHP), но это не является чем-то невозможным.
Так что среди платных лидерами становятся два варианта — номер 2 и номер 3. По цене третий предпочтительней, но надо еще проверить их на соотношение цена/производительность. Тут могут быть варианты, но для долгосрочной неторопливой работы ежемесячный платеж в 10$-20$ может вылиться в сами понимаете какие суммы.
Лично для себя я этот последний вариант на данный момент считаю безусловным лидером во всех трех категориях сразу. У меня есть еще и довольно много старых API-ключиков, но я им, пожалуй, найду другое применение ;-)
Теги: