Это никто не знает точно, кроме Яндекса.
ИМХО, 10-15% сходство вполне допустимо.
Чистые это "ноутбуки одесса" с кавычками (без уточняющих слов, но в любой словоформе).
Hkey добавил 06.03.2011 в 22:42
Новая версия
В скринах синий текст этот то что я вручную дописал для сравнения.
Теперь есть дополнительные подсказки какие ключи можно также посмотреть.
(По этому ключу хинтов вордстата нет)
Для однословных запросов у него более релевантная выдача, чем у вордстата
Добавилось автосоставление запроса для WordStat или Яндекс.Директа
Программа может "просматривать" дальше выдачи. Добавлять кеи которые она не видит по вордстату, но косвенные факторы говорят об их присутствии. К ним дописывается "(*)".
Запрос "секс", с ограничения 5 страниц выдачи (демо версия)
Hkey добавил 06.03.2011 в 22:49
P.S по многочисленным просьбам сделал часть графиков многоцветными.
На мыло. Сайт и доступы
Дефолтная Гугла.
Смотрится клево.
Многоцветная может вызвать проблемы у дальтоников (их около 5%).
На мыло.
Импорт ключей из гугл аналитикс я не убирал. Он идет в отдельном файле, как и раньше. Вы может просто перепутали.
Поставьте кодировку базы UTF-8 и в браузере, когда добавляете ключи должна стоять кодировка UTF-8.
Ну если вы в вордстате наберете запрос в кавычках, то вордстат покажет чистые вхождения ключа (без уточняющих слов). Это число будет меньше либо равно числу показанному программой.
Программа используя отпарсеные результаты строит что-то вроде дерева наследования. В отличии от обычного дерева один элемент может иметь несколько родитетельских. Например "купить ноутбуки недорого" имеет два родителя "ноутбуки купить" и "ноутбуки недорого".
Начиная с самых длинных запросов, программа вычитает из родительских дочерние. Так мы лишний раз не беспокоя вордстат оцениваем максимум чистых показов кея. Вы можете проверить, то что сумма чистых равна "все" для основного кея.
Hkey добавил 04.03.2011 в 15:24
Да иногда он не правильно определяет словоформы. Первая версия, что вы хотите :)
Hkey добавил 05.03.2011 в 00:36
Исправил глюки, чуть улучшил интерфейс (юзабилити)
Добавил новую диаграму
1. 1-3 месяца (Яндекс что-то апы редко стал делать в последнее время)
2. Если сайт планирует получать основной траф на внутряк, то использование скрипта оправдано.
Но если сайт старый, но не особо посещаемый по каким-либо причинам, то сам по себе HTracer его не вытянет. Получше будет с трафиком, чем раньше, но не на порядок.
Если посещалки у вас пока нет то вам придется забить для большинства предполагаемых основных посадочных страниц ее основные запросы, вариации скрипт подберет полуавтоматически. На каждую страницу потратите по 1-2 минуты.
Счас пишу ап который ядро будет полуавтоматом строить.
Hkey добавил 04.03.2011 в 00:22
У вас ошибок много в тексте. Ставьте себе фаирфокс, он исправляет их как MS Word.
1. Будет
2. Если вы хотите использовать данные другим скриптом, то почему бы не считывать их с БД.
3. Апдейты бесплатные
4. Неа сейчас распространяется версия с открытым исходным кодом
Галку можно ввести и в этой версии (не совсем галку а настройку в конфиге)
По поводу того, чтобы не учитывать переходы с первой страницы, то это слишком грубое правило имхо. Можно например, будет снизить их вес в 5 раз. Эти переходы тоже несут информацию.
Я поставлю небольшое API в следующем апе. Регулярку, имхо, знает намного меньше людей чем PHP. Я лично редко его использую.
Яху и МСН наверное включу, только нужна ваша консультация (может есть какие-то подводные камни). Если вы шарите в буржунете, то можно обсудить продвижение HTracer буржуям.
Hkey добавил 03.03.2011 в 16:14
Первая заповедь дизайна "содержание определяет форму".Например у вас белый фон и строки, которые могут не вмещаться в дизайн. Берете фотошоп делаете градиент от прозрачного к белому (20x1 рx) и справа поверх накладываете его. Получается, что текст затухает и плавненько исчезает (Естествено оферфлоу хайден). Фишку стырил у сами знаете кого.
Сделаю фильтр по числу символов.
Да действительно благодаря своему алгоритму Htracer, когда расставляет контекстные ссылки не тупо ищет чистые вхождения. Он ищет слова во всех словоформах, частично игнорируя контекстные стоп-слова и общие стоп-слова.
Например, у вас сайт про Одессу и вы указали стоп-слова сайта "одесса,одессы,одессе".
Скрипт находит кусок "одна из лучших гостиниц нашего города", и ставит ссылку по ключу "гостиницы в одессе" на слово "гостиниц" получается "одна из лучших <a title="гостиницы в одессе">гостиниц</a> нашего города"
Мы итак имеем хороший титл релевантный запросу и анкор релевантный в человеческом смысле.
Однако если вам этого мало, то зная, что алгоритм старается сделать как можно длинную ссылку вы можете переписать текст в админке своего движка "одна из лучших гостиниц Одессы". Тогда в анкоре будет "гостиниц Одессы".
Но стоит ли овчинка выделки? Вопрос спорный. Титлы внутренних ссылок учитываются поисковиками, в первом случае титл был использован правильно (он уточняет анкор), во втором не особо (титл там по сути словоформа анкора, хотя и в более общем, именительном падеже).
У каждой категории есть поле описание, но не все темы позволяют его выводить.
"Записи"->"категории" и редактируйте одну. Там есть ее описание.
В базе будет три уровня вложенности объектов страница, ключ, словоформы ключа
Если два запроса совпадают с точностью до окончаний, порядка слов, знаков препинания, стоп-слов и регистра букв, то они считаются одним ключом в разных словоформах. Например, "одесса, гостиницы"=="гостиницы в Одессе".
На любой странице можно будет отключить работу Htracer.
Любую страницу можно будет исключить из списка доноров или акцепторов для контекстных ссылок или блочных.
Любой ключевик либо его словоформу можно будет игнорировать (переходы по нему будут запоминаться, но он не будет принимать участие в формировании облак, альтов и прочего).
Более точнее "придать большую значимость".
Актуально для обоих версий:
В первой версии значимость ключа зависела только от числа переходов по нему. В новой версии будет более продвинутая формула. И при этом вы можете выделить более полезные ключи, с помощью коэффициента.
Я рассматриваю некоторую абилити по отслеживанию конверсий, например вы задаете в скрипте страницы конверсии и запросы по которым приходит пользователь. Если конверсия произошла скрипт увеличивает вес кея по которому пришел пользователь. Таким образом можно отследить js события (например, клики по мылу), вызывая через AJAX целевую страницу.
Управление будет ключами из которых формируются оба вида ссылок.
Вы перепутали омоним. "автоматизированное" синоним слова "полуавтоматическое", человек + машина. Вы имели ввиду автоматическое (чисто машина).
И сейчас он используется при ручном добавлении кеев. Чтобы значительно ускорить процесс. Сейчас админка, в которой есть все необходимые функции.
Идея интересная.
Проблема в производительности, и в том что вордстат генерирует много несвязных ключей. Намного больше чем генерируют пользователи. Например, "гостиницы отели". Вордстат выводит не число показов чистого ключа, а сумму показов чистого ключа и всех его уточнений. Поэтому, придется вычитать ключи одни из других, а для НЧ и СЧ этот алгоритм будет давать сильную погрешность. Если проверять через оператор кавычки, то придется парсить много страниц, да и еще нужно проверять на пару стоп слов, вроде "и".
Есть еще одна проблема в том, что под уточняющие запросы могут продвигаться другие страницы. Но определить это можно только после того, как по этим уточняющим запросам уже были переходы. Можно эту проблему решить, но нужно протестить, что по скорости будет.
Можно другой алгоритм, если на страницу совершен переход, допустим по запросу "ноутбуки", и до этого было переходы по "ноутбуки купить", причем последний из них был не с первой страницы выдачи, то можно немного подтянуть запрос "ноутбуки купить".
Hkey добавил 02.03.2011 в 21:57
Зачем это нужно?
Для этого есть гугл аналитикс и другие системы статистики
Будет аналог get_keys_cloud(). Как называться будет я еще не придумал :) По параметрам такая-же, только будет стараться выводить похожие страницы.
