Накопите побольше статистики. В течение пары дней допишем свой скрипт, а потом сравним результаты - посмотрим кто кого 🚬
Во-первых, я думаю, Яндексу все равно, правильно написано слово или с ошибкой - он подсчитает вес "ошибочного" термина и отранжирует его по тому же алгоритму (только вес "ошибочного" термина, естественно, будет меньше).
Во-вторых, в данном примере в обоих запросах употреблялся один и тот же термин.
В-третих, по моему опыту спец. обработки запросов с ошибками нет (за исключением того, что Я предлагает "исправить ошибку").
Тема эта поднималась, но обычно в контексте невразумительного "наверное, там какой-то другой алгоритм". Даже предположений, чем и как он может отличаться, я не помню.
Спасибо, моя знать русская языка🚬
Если время сегодня будет, опишу один интересный эксперимент, в ходе которого я и наткнулся на данный пример. Может, это подстегнет обсуждение...
Цель исследования - понять, можно ли сейчас использовать оператор "|" для изучения алгоритмов ранжирования Я.
и результат затем будет отранжирован по релевантности. ИМХО Вы не невнимательно читали о методике Миныча - именно на такого рода запросах она и была построена. За исключением того, что у него запросы были ортогональными, а у меня, как видите, нет, потому что в данном примере я не сравниваю выдачу по методике Миныча, а пытаюсь выявить особенности оператора "|".
Не думаю. Я такого рода примеры замечал и до Родео. Хотя, конечно, интересно, считается ли "запрос1 | запрос2" многословником :) Но думаю, что нет.
По поводу «стелажи» и «стелажи | стелажи» тоже не совсем все чисто...
Если взять два запроса:
1*. ( стелажи | стелажи) << (url="www.forma-com.ru" | url="www.nasklad.ru")
2*. ( стелажи << url="www.forma-com.ru") | ( стелажи << url="www.nasklad.ru")
Результат одинаков - на первом месте www.nasklad.ru. Но если начнем понижать вес слова стелажи, то увидим, что и там, и там будет ступенька (такое значение веса слова "стелажи", при котором сайты в выдаче поменяются местами), причем это значение веса различно для запросов 1* и 2* - то есть алгоритмы при ранжировании по запросам 1* и 2* тоже различаются! Меня, собсна, больше интересует 2*, а не 1* :)
Будем думать :)
Чтоб такой "чистый" пример найти, нужно много сайтов проанализировать. Но я, собсна, специально и не искал его, он сам вылез при другом эксперименте...
Неужели никому не интересно?
Или добавить нечего? Не верю!) Делитесь своими соображениями и примерами, давайте обсуждать их!
Так не интересно, в исходниках выкладывай! ;)
Такой вариант подходит только для тех случае, когда заранее известно, что беков по запросу много (настолько много, что найдется и запрашиваемый таким образом вариант:)), то есть, скорее всего, для популярных, высокочастотоных, однословных запросов. Но и так понятно, что вероятность найти уникальный бек с такого рода анкором близка к нулю.
Таким образом, на текщий момент алгоритм определения уникальности ссылки с помощью Я выглядит так:
1. Получить от Я выдачу по интересующему запросу (тому, который содержится в анкоре проверяемой ссылки).
2. Искать в полученном списке документов страницу, которая не является исходной страницей-донором, ссылается на акцептор, и анкор ссылки с которой идентичен анкору ссылки донора.
3. Если результат поиска равен нулю, то ссылка уникальна. Больше нуля - ссылка не уникальна.
Вообще-то по сниппету видно упоминание поискового запроса в тексте страницы, поэтому на основании полученных таким запросом данных говорить, учлась она или нет - неверно.
По теме:
палю тему ;) по непоту
думаю, алгоритм проверки ссылки на непот должен быть такой:
1. проверяем проиндексенность ссылки на доноре и акцепторе (как именно, уточнять не буду - не суть важно)
2. если есть подозрение, что ссылка не в непоте или, наоборот, в непоте, в соответствии со старой методикой определения непота в таком случае необходимо проверять ссылку на уникальность
3. для проверки на уникальность собираем как можно больше беков акцептора по всем доступным источникам (другие п.с.), отбираем из них только те, которые проиндексены в Я
4. производим анализ полученного массива беков с целью определить, является ли проверяемая ссылка уникальной
Самое интересное, что если все оптимизаторы начнут пользоваться данным методом, то нагрузка на сервера Я возрастет многократно. Так что, если одной из целей сокрытия операторов link и anchor было снизить нагрузку на сервера, то результат может быть прямо противоположный.
Я придумал способ, но он уж больно трудоемкий...
ИНтересно, мы об одном и том же говорим или нет? :)
Не понял, к чему ссылка на те посты - решения проблемы там не предлагалось...
Я в курсе, что яндекс непот не показывал, но определять-то мы его могли как раз используя отключенные нынче операторы. Или эта проблема нонче уже решена? ;)
И в третьих (имхо в самых главных), полученные проиндексированные в Я беки могут быть под непотом, который теперь сложно определить (бек на уникальность теперь не проверишь с помощью яндекса...).
