Поздравляю!
Михаил, поздравляю от всей души! Здоровья, счастья и удачи :)
Так оно не то что возможно - оно вполне имеет место быть :) Сумма найденных сайтов по запросам url="a*", url="b*"... url="d*" - уже превышает число найденных по url="*". С host и rhost ситуация та же. Моя мысль состояла в том, что при поиске (хрень << url="*") из выдачи исчезают сайты, "обрезанные" на запросе url="*" (т.к. неранжирующее И очень похоже на буквальный "поиск в найденном"). И в этом смысле не важно, какой именно оператор используется.
Насчет алфавитной сортировки может и погорячился. Однако по url="*" первые 10 результатов начинаются либо с буквы "a", либо с цифры. Совпадение? Ковыряем дальше, перебирая запросы url="a*" << url="*", url="b*" << url="*" и далее по алфавиту. Кол-во найденных с каждым запросом сокращается, и на букве j равно нулю. С оператором host этот финт не проходит, так что тут я был неправ :)
Немного потупив, решил, что такие запросы ранжируются в каком-то полу-алфавитном порядке. Как ставится ограничение - непонятно, но он есть. Например:
url="www.bij.ru" << host="*" - так находит
url="www.bij.ru" << url="*" - а так нет
В первом случае идет алфавитная сортировка по хосту, и "b" проходит ограничение. Во втором - по урлу, и "w" отрезается. Как-то так :)
pro-maker, Виталий, а, собственно, чем в данном контексте URL принципиально отличается от хоста, учитывая, что мы используем wildcard и не используем &surl? :) Если заменить слово "хост" на слово "урл" в моем сообщении, смысл изменится?
Есть полумысль :)
Запрос url="*" показывает:
Результат поиска: страниц — 28 643 235, сайтов — не менее 24 647
24К - явно меньше, чем есть на самом деле, фиг знает, почему именно эти хосты отбираются и почему именно столько. Видимо, поиск слова "хрень" в приведенном запросе производится в этом фиг-знает-как отобранном наборе хостов, отчего и получается меньше результатов.
В подтверждение моей гипотезы: url="hrenius.ru" << url="*"
RedHat, плохо смотрели. Сравните Вашу выдачу с запросом "недвижимость" без поиска в найденном. Ну или так:
эдуард
лимонов -> в найденном -> эдуард
Разница видна?
Будьте внимательнее.
Утверждение громкое :)
Просто оптимизаторы от недвижимости спамят в полную силу.
Запрос с &holdreq (поиск в найденном) переколдовывался как-то так: новый запрос << старый запрос
Т.е. в Вашем случае: недвижимость << Белгород - вроде выдача совпадает.
Старый запрос в сниппетах не подсвечивается. Чтоб проверить, каким местом первый, к примеру, сайт релевантент старому запросу, используем то же неранжирующее И, но с урлом: Белгород << url="www.kvadroom.ru" - в сниппете видем "найден по ссылке". С остальными - та же история: надо думать, в анкор-листах сайтов по недвижимости есть весь географический атлас :)
Чтоб все-таки найти, то что Вы хотели, лучше использовать ранжирующее И, так: недвижимость && Белгород, тогда при расчете релевантности учитываются оба слова. Либо, использовать неранжирующее И, поменяв слова местами, так: Белгород << недвижимость - тогда берутся все документы, релевантные слову "недвижимость" и ранжируются по релевантности слову "Белгород".
Справедливости ради, отмечу, что при вводе обычного запроса "недвижимость Белгород" можно увидеть вполне сносную выдачу, запрос, если не ошибаюсь, колдуется с &, т.е. поиск в одном предложении. Хотя, безусловно, описанная Вами проблема имеет место быть.
upyrj, хм, а для уже существующего слова задать вес вручную - не айс, как считаешь?
Подсказка: результат работы вируса, вставляющего iframe, можно выловить при помощи grep, если есть ssh доступ. По крайней мере против разновидности, которая портит статические файлы, помогает.
