Для сбора статистики по поисковым запросам в рунете используются в основном статистика Rambler-а и статистика Yandex (Google, к сожалению, не дает количественную оценку частотности запросов). Однако, статистика Yandex не дает точных данных о количестве запросов того или иного ключевика, она включает все запросы с его использованием. В то же время, Rambler, занимая весьма незначительную долю поискового рынка, позволяет получить как количество точных запросов, так и общее количество запросов со всеми вхождениями. Это позволяет расчитать примерное количество запросов в Яндексе с точным вхождением ключевика на основе статистика рамблера.

Ручная процедура составления семантического ядра сайта с анализом статистики двух систем и со сведением данных в Excel-евскую табличку, осуществляющую перерасчет статистика Яндекса – весьма утомительно занятие. Поэтому для автоматизации этой работы используется программа YAST Keywords.

Для работы программы потребуются нехитрая регистрация: при первом запуске, укажите ваш e-mail и на него будет отправлен пароль для активации программы.

Кроме того, рамблер весьма неохотно отдает свою статистику на сторону, требуя для ее получения, регистрации в своей системе Rambler ID. Поэтому, необходимо зарегистрироваться на рамблере и указать логин и пароль в настройках YAST Keywords (Проект -> Настройки…).

На этом настройка YAST Keywords завершена и можно переходить к практическому примеру составления семантического ядра сайта. Далее будет пошагово показан процесс составления семантического ядра для интернет-магазина электрооборудования stabiltech.ru.

Клиент хотел получить целевые запросы, связанные с ключевиком “стабилизатор напряжения” и обладающими наивысшим покупательским потенциалом. Отдельно отмечу, что продвижение по этому ключевику, считаю нецелесообразным, поскольку при высокой конкуренции (и, соотвественно, стоимости продвижения по нему) оно обладает низким покупательским потенциалом и высоким процентом уточнения (т.е. получив выдачу по этому запросу, люди в большинстве своем уточняют свой запрос).

Итак, отправная точка есть, можно начинать построение семантического ядра. Добавляем ключевик “стабилизатор напряжения” в YAST Keywords.

После добавления, делаем для этой фразы поиск ассоциаций (Фразы -> Найти ассоциации.. или по правой кнопки мыши или просто Enter). Статус ключевика переключается в состояние “Идет анализ” (иконка секундомера) и в список начинают добавляться связанные ключевые фразы, извлеченные из статистики яндекса и рамблера.

После окончания анализа (иконка ключевика заменится на синюю кнопку). Будет доступна полная статистика по частотности данной ключевой фразы (Яндекс-всего, Яндекс-точно, Рамблер-всего, Рамблер-точно) и список ключевиков будет дополнен всеми ассоциативными ключевиками (но, пока, без точной статистики).

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

Конкретно, в данном случае, я исключаю фразы с участием торговых марок конкурентов, запросов, явно не предполагающих покупку, информационных запросов и т.п. Для всех же подходящих ключевиков я провожу “поиск ассоциаций”.

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

После окончания этой процедуры, удалим из списка все фразы, которые мы посчитали лишними, для этого выделим все ключевики которые мы не анализировали (Фразы -> Выделить новые) и удалим их (Фразы -> Удалить или Del).

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

Полученное семантическое ядро сайта можно использовать при выборе ключевых фраз для продвижения сайта в поисковых системах, для показа объявлений в системах контекстной рекламы или даже для создания дорвеев.

Формат сохраняемых .yst-файлов, используемый в YAST Keywords, подходит для импорта в Excel, и полученные результаты могут быть легко использованы в отчетах.

Все началось с того, что захотелось организовать защищенный обмен между windows-приложением и web-сервером. Требовалось просто передать на сервер некоторые данные и получить ответ, исключив при этом возможность подмены сервера (путем правки файла hosts) и соотвественно избежать атаки подменой данных ответа от ложного сервера.

Клиентское приложение разрабатывалось на Delphi 2009, а в качестве сервера хотелось использовать связку Apache+PHP.

Интуитивно понятно, что данная задача решается при использовании инфраструктуры открытых/закрытых ключей для шифрования трафика, и выбор естественно пал на алгоритм RSA.

Говоря о самом алгоритме RSA, хочу отметить несколько неочевидных фактов, подтвержденных экспериментами:

1. Какие бы загадочные термины (ключ, сертификат, цифровая подпись и т.д.) не использовали при описании его работы, основан он всего лишь на 3-х числах: модуле, приватной и публичной экспоненте. Модуль и приватная экспонента, в отличии от экспоненты публичной, это очень большие числа, разрядность которых определяется в алгоритме и может варьироваться до 1024 бит (стандартное значение – 512). Публичная же экспонента, как правило, равна 65537. Этих 3-х чисел достаточно для реализации ассиметричного шифрования RSA.
2. Считается, что шифрование должно осуществляться открытым ключем, а дешифрование – закрытым. Это не так. На самом деле даже если зашифровать данные приватным ключем – они прекрасно расшифруются публичным.

Реализация RSA на PHP лишь одна – php-OpenSSL, тут выбирать не приходится. А вот в Delphi, выбор классов и компонент для шифрования значительно шире:

• TurboPower LockBox – Уже не поддерживаются, исходники выложены в публичный доступ, есть порт tbLockBox для Delphi 2009. Интуитивно понятная, хорошо документированная и достаточно простая библиотека.
• SecureBlackbox – Коммерческая библиотека без исходных кодов. Довольно громоздкая и не совсем удобная. Скачать бесплатно можно здесь, работоспособность кряка не проверялась, есть вероятность появления наг-скринов в самые неожиданные моменты.
• OpenSSL – Можно использовать и на клиенте. Для этого необходимо будет включить в проект библиотеку libeay32.dll. Заголовочный файл libeay32.pas на Delphi 2009 скорее всего не пойдет, он сделан без учета unicode.
• Windows CryptoAPI – Родная виндовая криптосистема, соотвественно, приложение не утяжеляется, и автоматически снимаются проблемы совместимости библиотеки с будущими версиями Delphi. Заголовочный файл Wcrypt2.pas прекрасно работает на Delphi 2009.

Все библиотеки позволяют генерировать пары ключей для работы.

• В OpenSSL для этого используется одноименная утилита openssl (необходимо установить OpenSSL for Windows).
  Генерация приватного 1024-битного ключа:
  openssl genrsa -out private.pem 1024
  Создание парного публичного ключа:
  openssl rsa -pubout -in private.pem -out public.pem
  Отображение содержимого ключа:
  openssl rsa -text -in private.pem
• В tbLockBox для генерации пары RSA-ключей используется функция TtbRSA.GenerateKeyPair()
• А в CryptoAPI функция CryptGenKey()

Однако при попытке использовать пару ключей в разных системах возникает проблема формата ключей:

• openssl-функции PHP работают лишь с ключами в формате PEM, который содержит base64 кодированную ASN.1 структуру, содержащую все данные ключа.
• tbLockBox сохраняет и читает ключи в двоичном ASN.1 формате, однако структура этих данных не соответствует структуре, используемой в PEM-файлах. Кроме того, для приватных ключей используется лишь модуль и приватная экспонента, в то время как PEM-файлы приватных ключей содержат и другие данные, необходимые для работы openssl.
• CryptoAPI для экспорта и импорта ключей использует структуры PRIVATEKEYBLOB и PUBLICKEYBLOB

В процессе решения проблемы конвертации и изучения структуры файлов ключей, была найдена замечательная утилита ASN.1 Editor (есть исходники), которая сильно помогла понять структуру RSA-ключей.

В результате долгих изысканий был найден единственный рабочий способ (натолкнулся здесь) – сконвертировать CryptoAPI структуру PRIVATEKEYBLOB в PEM-файл пригодный для использования в OpenSSL.

Способ этот заключается в использовании утилиты openssl и указания формата исходного файла “MS PRIVATEKEYBLOB” (именно так, с пробелом):
openssl rsa -inform MS\ PRIVATEKEYBLOB -in private.dat -outform PEM -out private.pem
Обратите внимание на обратную косую черту, она экранирует символ пробела в командной строке!

И здесь же следует одна очень важная оговорка: формат “MS PRIVATEKEYBLOB” поддерживается openssl лишь начиная с версии 1.0.0 beta. На Windows данная версия на момент написания статьи еще не портирована и для конвертации ключей необходимо взять *nix или cygwin и поставить на него openssl v1.0.0beta.

Исходя из всего выше сказанного следует, что на клиенте должно использоваться CryptoAPI. В нем же необходимо сгенерировать ключи и сохранить их в формате PRIVATEKEYBLOB, а затем сконвертировать в PEM-формат, пригодный для использования в PHP.

Небольшое пояснение: PRIVATEKEYBLOB равно как и PEM-файл, содержат данные не только приватного, но и публичного ключа. И сконвертировав лишь PRIVATEKEYBLOB можно получить затем из PEM и открытый ключ (openssl rsa -pubout -in private.pem -out public.pem).

До этого момента я не имел опыта работы с CryptoAPI и в его освоении мне очень помогли статьи “Delphi и Windows API для защиты секретов” и “Использование инструментов криптографии в Delphi-приложениях“, а так же небольшая демо программа наглядно демонстрирующая использование CryptoAPI. Именно в ней и были сгенерены ключи.

Вот кусок delphi программы, демонстрирующий работу по чтению публичного ключа и шифровки текста (строки в php имеют ANSI представление, поэтому перед шифрованием преобразуем Unicode в ANSI):

var
Stream: TMemoryStream;
res: boolean;
RSA: HCRYPTPROV;
PublicKey: HCRYPTKEY;
str: ANSIString;
strlen: DWORD;
begin
// Читаем ключ из файла
Stream := TMemoryStream.Create;
Stream.LoadFromFile('public.key');

// Освобождаем занятые ресурсы
Stream.Free;
CryptDestroyKey(PublicKey);
CryptReleaseContext(RSA, 0);


Для передачи зашифрованных данных серверу, удобнее использовать кодировку base64, в которой бинарные данные имеют текстовое представление. Для этой цели отлично подошел модуль DCPbase64.pas из библотеки DCPcrypt:
...
SetLength(str, ((Stream.Size + 2) div 3) * 4);
Base64Encode(pointer(Stream.Memory), pointer(str), Stream.Size);
Edit1.Text := str;
...

Переходя к рассмотрению серверной части, сразу отмечу, что есть одна неучтенная мною особенность связки CryptoAPI и OpenSSL, из-за которой сразу все не заработало. А именно – порядок следования байтов в зашифрованном сообщении. Дело в том, что в CryptoAPI используется little-endian порядок, а в OpenSSL – big-endian (наткнулся здесь, спасибо). Поэтому потребуется перестановка (проще сделать в php).

Ну и собственно серверный пример:

<?php

?>

Надеюсь, кому нибудь поможет.

Отдельное спасибо Jareth-у за то,
что грохнул рабочую станцию офиса продаж,
установив на нее федору 11,
чтоб потестить openssl 1.0 beta3

Вот так, например, выглядит статистика онлайн посетителей:

А вот статистика переходов с поисковых систем:

Как можно видеть, количество переходов с Яндекса, Google и Rambler возросло почти в 2 раза, с mail.ru – в 4 раза, и т.д. И это скачкообразно, в течении дня.

Привожу еще график переходов с сайтов:

Как можно видеть, количество переходов с закладок, соц.сетей и пр. практически не изменилось. А вот трафик с поисковых систем одночасно вырос. Что за анамалия?

Решение выглядит весьма логичным в свете респределения долей по поиску между Google, Microsoft и Yahoo! в 65%, 19% и 8% соответственно, а так же с учетом недавнего желания Microsoft приобрести полный акционерный контроль над Yahoo! Однако, напомню, что, после отмены Яндексом и Google оператора link, Yahoo! оставался единственным приемлемым сервисом для анализа обратных ссылок.

Наиболее вероятно, что после закрытия поиска Yahoo!, для анализа бэклинков, станет набирать популярность малоиспользуемая поисковая система altavista.com, которая по сей день поддерживает оператор link.

Кроме того, не стоит забывать, что Yahoo!, являлась основным инструментом для ручного анализа ссылочного спама и, соотвественно, индикатором, который использовался для того, чтобы “капать” на не чистых на руку конкурентов. С упразднением этих возможностей, ручная проверка честности продвижения становится невозможной и следует ожидать роста нелегального продвижения сайтов (а также сателитов, доров и пр.) за счет ссылочного спама, который не попадает под действие автоматических фильтров.

По сути, эта сделка напоминает деградацию Rambler-а, и лишний раз доказывает несостоятельность крупных интернет-порталов в области поиска.

Тем временем, рынок оперативно отреагировал на информацию о сделке – по итогам сегодняшних торгов, ценные бумаги Yahoo! потеряли в цене более 12%. В самой же Yahoo! говорят, что сделка принесет им около 500-1000 млн. долларов в год дополнительной прибыли, однако по расчетам акционеров, реальный доход от сделки не превысит 275 млн. долларов в год и это при том, что Yahoo! оставили без ее ключевого актива – поисковика.

Этот отчет показывает, какая доля поискового трафика по данным запросам приходится на ваш сайт.

Иными словами, можно оценить процент людей, которые набрав некоторый поисковый запрос перешли по нему на ваш сайт, учитывая при этом позицию вашего сайта в выдаче. Т.е. оценивается привлекательность ваших TITLE и DESCRIPTION (или снипетов) с учетом ваших позиций по данному запросу, а так же, неявно, качество конкурирующих сайтов, которые стоят в выдаче выше вас (ведь если в выдаче есть выше вас стоят более качественные сайты – на вас никто и не перейдет).

Судя по моей статистики, запрос с именем домена (с www и без него) дает порядка 93-99% посещений. Однако, при этом, мои самые топовые запросы, по которым сайт находится на первых позициях в выдаче и которые дают максимум трафика, привлекают, тем не менее, лишь чуть более половины посетителей (55-63%), что заставляет задуматься о привлекательности снипетов и заголовков…

Кроме того, данная статистика неявно выдает РЕАЛЬНЫЕ данные о количестве поисковых запросов (в отличии от статистик ПС, которые непреднамеренно накручены различными анализаторами поисковых запросов и позиций сайтов).

Как оказалось, на проекте в одном из подкаталогов используется WordPress , в настройках которого “Адрес блога (URL)” установлен без www (поскольку все внешние ссылки, которые ставлю на проект, идут именно на домен без www).

Но, после очередного своего апдейта, яндекс увидел какую-то естественную внешнюю ссылку с www и почему то решил, что основной домен проекта должен быть с www-префиксом. Затем он попробовал проиндексировать WordPress-овский каталог по адресу www.xxxx.ru/blog/ и получил 302 редирект от WordPress-а, пересылающий его по адресу xxxx.ru/blog/.

В результате, страницы блога наглухо выпали из индекса и трафик упал. Причем, в goggle все осталось как прежде и менять настройки адреса блога добавлением www жутко не хочется, дабы не поиметь подобным проблем с google. Лучше бы поменять 302 редирект на 301.

Выход был найден достаточно быстро – плагин Permalink Redirect. Который судя по описанию делает именно то, что нужно.

Ставим, активируем и проверяем через Redirect Checker. Вот теперь WordPress при обращении с www дает 301 редирект на URL без www.

Теперь ждем повторной переиндексации яндексом, чтобы все встало на свои места.