Метка: Яндекс.XML

яндекс.XML+РСЯ: никого нет дома

Бля, еще вчера предупредили о проблемах – http://veterror.ya.ru/replies.xml?item_no=19065 – что лимит на хмл накапливается и не обнуляется.
Не почеслись, сегодня и у меня ничего не берется, лимит превышен, апометр не работает – http://tools.promosite.ru/updates/details.php?data=2009-09-16 (хорошо, апа не было 🙂 ) – письмо в техподдержку в 9 утра.
Ответа нет.
Но я сейчас позвонил в яндекс.

Мне ответили, что по вопросам XML Вася N1 в командировке до 17-го, Вася N2 в командировке до 18-го, и этих Вась никто не замещает.
Как это возможно для компании типа Яндекса?

С техническим народом меня не связали, в РСЯ оказалось, что запросы на увеличение лимита идут через тех же Вась.

Бля, подозреваю, что куча сайтов РСЯ с поиском от XML не работают – лимит превышен.
А ведь в нужное время столько мест для управдомов не найдется.
Яндексоиды! Пора заранее выходить на рынок труда.

нашел вид запроса, который “валит” Яндекс

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

В XML по такому запросу – выдает невалидный код для броузера, но если сохранить и посмотреть сорцы хмля, видно, что кусок запроса отрезается и происходят непредсказуемые переключения параметров группировки (с deep на flat, например).

Теперь думаю, чо с этим запросом делать. Жаль, я не кулхацкер, а то интересного наковырять можно было бы 🙂

Есть у кого знакомые, кто может посоветовать, как дальше ковырять? 🙂

Я.ХМЛ – то понос, то золотуха

Только я успел написать про тег doc id="" в ХМЛе (кстати, у быстроробота уже не 23, а 25 и у зарубежки не 24, а 26) – как опять все переколбасило… Под эти все изменения ХМЛ еще вроде бы не работал некоторое время.

1. doc id стал больше похож на айди. Теперь он выглядит примерно так: doc id="13-28-17-13613987", первое 13 – это как и было, последнее число – параметр d (типа айди документа?), что за два числа в середине – непонятно (у быстроробота – одно число).

2. отменили сортировку по tm (время модификации) – уже на Сёрче кто-то ругался. В докуметации описано – так и верните взад!

3. окончательно похерилась геовыдача… В прошлый раз удалили теги geo и geoa, но тег categ attr="geo" оставался в четверти случаев… А теперь и его нету. Геоданным полный ППЦ, похоже…

Когда ж у них там устаканится…

Яндекс.XML: теперь doc id=”13-” – сменился

в Я.хмле есть параметр найденного результата <doc id="". Это реально никакой не айди сейчас, но когда-то им был. Потом для всех обычных документов он стал что-то типа 8- или 9- (и эта цифра потихоньку растет), и только для быстроробота был похож на айди, так можно было отличить быстроробот. Потом и у БР он стал фиксированным, но отличным от обычной базы.
Раньше было так:
обычный робот: doc id="12-"
быстроробот: doc id="22-"
зарубежная база: doc id="23-"
(сперва я забыл и засомневался: то ли 24-23, то ли 22 у БР и запада, но поднял архивы в тулзе регионов – так получилось)
А теперь стало так:
обычный робот: doc id="13-"
быстроробот: doc id="23-"
зарубежная база: doc id="24-"

По времени – это произошло на днях, 6 июля doc id="12-" стал меняться на 13, позже – от 7 июля двенадцати вообще нет. И заодно сменились БР и буржунет.
Я кагбе не знаю, что оно означает, но вроде апдейт только сегодня 8-го, а 6 и 7 никаких изменений не было – ни у меня в апометре, ни в апометрах выдачи.
Так что это вряд ли айди алгоритма и формулы, как думали другие люди.
Апдейта по выкладыванию индекса тоже не было – так что это вряд ли айди базы-хранилища индексов, как я думал раньше.

Может, это айди хранилища кешей или типа того? Кто мониторит – посмотрите, на какие айпи показывал раньше и стал показывать теперь хайлайтер яндекса hghltd.yandex.net?
Еще какие-нибудь идеи, что это за айди?

Яндекс удалил гео-теги geo и geoa из XML…

ггггг
доходит до них, как до жирафа, не очень быстро… 🙂
Меня тут просили в сервисе определения региона обновлять данные, а там накопилось 210 тыс. сайтов, из них 170 тыс – саподоноры, ну и мне лениво же все обновлять.
Я тогда сделал кнопочку для горячо любимых сайтов – если данные взяты не сегодня, то можно нажать на кнопочку "обновить" и они перезапросятся.
Сейчас понажимал – смотрю, конечные регионы по тегам geo и geoa пропадают. Проверил в ХМЛ – действительно, этих тегов нет, остаются только вложенные теги categ attr=geo, но они очень редко где есть.
Например – зайдите во Владикавказ, Универсальное, Россию, выберите сайтики снизу, у которых дата несегодняшняя и есть регионы по тегам geo и geoa, понажимайте обновить – они пропадут. И в исходном ХМЛе их, конечно, нет.
А хрен ли – недокументированная фича 🙂
Себе я базу-то скопировал, конечно… 🙂
Так что кому нужны выборки по регионам для сапы – регистрируйтесь и качайте геосписки – а то понажимают на обновление, все данные-то и пропадут. А я буду базой приторговывать. 🙂
Надо будет в яплатон регионы интегрировать.

PS
Посчитал –
тег geo был у 39507 доменов
тег geoa у 127925 (предположительно автоматическое определение)
тег categ attr=geo был у 39584 доменов

Так что если categ attr остался, то три четверти геобазы теперь недоступно…

“еще с сайта” без цифирок теперь?

url="www.yandex.ru/*"
Рядом со ссылкой "еще с сайта" цифирок нет.
Какой смысл, юзеру понравится не знать количество страниц, что ли…
И парсить объем сайта тяжелее, хотя в ХМЛ, вероятно, есть – там же отдельный тег под это выделен, пойду смотреть.

Хотя это может быть связано чисто с проблемами нагрузки. Типа, считать число релевантных запросу страниц внутри каждого сайта – мощностей не хватает?

Яндекс: определение региона сайта в XML

Они не анонсируют проекты, они ждут, пока за них проанонсируют 🙂
Я, кажется, нашел способ смореть гео-привязку сайта http://tools.promosite.ru/region/ в яндексе.

Релиз Яндекса “Арзамас” – прикрутили влияние регионов сайтов на выдачу для региональных айпи. Пока что есть несколько “регионов” с разной выдачей (в сервисе сравнения выдачи по регионам их шесть).

Региональная привязка сайта, конечно, влияет на его положение в выдачах. Влияет ли региональная привязка доноров – это интересно всем, будем смотреть.

Но как смотреть? Как вообще определить регион сайта, чтобы на основе этого думать и делать эксперименты? По яндекс-каталогу? А если сайта в нем нет?

Недавно я полез в Яндекс.ХМЛ пошариться и неожиданно увидел там во всех результатах выдачи гео-теги, такого вида:

Вложенные теги с ID регионов в тегах categ:

<categ attr="geo" id="0" name="">
<categ attr="geo" id="225" name="">
<categ attr="geo" id="17" name="-">
<categ attr="geo" id="10174" name="- ?">
<categ attr="geo" id="2" name="-?" />
</categ>
</categ>
</categ>
</categ>

Конечный список тегов geo и geoa:

<properties>
<_IsFake>0</_IsFake>
<_MimeType>2 0&d=3675913&sh=1&sg=-1</_MimeType>
<_PassagesType>0</_PassagesType>
<geo>2</geo>
<geo>35</geo>
<geo>39</geo>
<geo>51</geo>
<geo>213</geo>
<geoa>2</geoa>
<geoa>35</geoa>
<geoa>39</geoa>
<geoa>51</geoa>
<geoa>213</geoa>

Конечно, все айдишники регионов соотвествуют списку кодов регионов.
Причем теги geo и geoa часто повторяют друг друга, содержат похожие данные. Подозреваю, что geoa – автоматическая привязка…

Сейчас я пробиваю биржевые ссылки, саподоноры на геопривязку. Пробито ~60 тыс. доноров, которые по моей оценке накрывают ~90% свободных ссылкомест. Сейчас есть возможность (после регистрации) скачать полные списки доменов для блек и вайт-листов, кому это интересно. Пробивать домены клиентов можно уже сейчас.

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

В документации на ХМЛ этого нету, конечно, 🙂 авось когда-нибудь появится.

Опять зарубежный индекс Яндекса?

Как в прошлый раз, выложили зарубежный индекс Яндекса – 400-500 тыс сайтов с датами за 11-15 февраля.

Точно так же, если проверить запросы вида date="yyyymmdd" domain="com" /(1 1) domain="root" – много сайтов в Я.XML, а date="yyyymmdd" domain="ru" /(1 1) domain="root" – порядка 10 сайтов…

Опять на Серче возмущаются, что Маул ничего не показал 🙂

Может, уже пора делать отдельную анализировалку сделать для зарубежа? 🙂
Это ж просто.

Правильные апдейты Яндекса

Сделал более правильную пробивалку текстовых апдейтов Яндекса: http://tools.promosite.ru/, которая показывает апы и даты, за которые страницы были выложены.

Почему это – правильные апдейты?

Сейчас все пользуются апометром Иванова и SergoZD. Он работает так: берет выдачу Яндекса по максимально широкому запросу (ru|com|info…) с абракадаброй для пробивки кеша, отсортированную по дате. Возможно, еще rd=0 добавляют и еще что-нибудь. Когда в этой выдаче появляется сайт с “новой” датой, считают это апдейтом.

Проблемки возникают следующие. Во-первых, частенько возникают мифические “доапы” (или “перед-апы”). Во-вторых, “Cамая поздняя дата в БД” слишком уж большая бывает – ну нет таких новых документов в обычной базе! Ну нет и все. Вот например: “ап” 25.03.2008 марта, а поздняя дата 22.03.2008.

Отчего это все происходит?

Сначала палю тему. 🙂

В хелпе Яндекса есть оператор date=”YYYYMMDD”, причем есть очень давно. Описан так: “Поиск производится только по страницам, дата которых удовлетворяет заданному условию.”  Дата в данном случае есть HTTP-заголовок Last-modified, убедимся в этом дальше.

Но многие документы отдают неправильный Last-modified, например, если поискать дату в будущем (сейчас 26 марта): date=”20080425″, найдем несколько сайтов. Например, страница на afisha.webrostov.ru – сохраненка не быстророботная. Проверим ее http-хедеры через какой-нибудь сервис – и легко увидим искомую строчку Last-Modified: Mon, 24 Apr 2008 23:00:00 GMT… Ну, дата идет следующим днем – ладно.

Итак, last-modified может неправильно отдаваться. И как раз поэтому в выдаче Яндекса могут быть документы, которые проиндексированы во время Х, а Яндексу кажется, что дата у них позже. В общем, если поискать этим оператором по ближайшему прошлому – быстророботные страницы там будут, но и страницы основного робота – тоже.

Я все думал – откуда в апометре Иванова и SergoZD такая точность даты? Я так думаю, что либо скриптом лезется на “новую” страницу и дергается Last-Modified, либо Яндекс.ХМЛ такую информацию дает, но берет он ее оттуда же. Логично?

Поэтому в алгорим с сортировкой по дате могут закрадываться ошибки именно в виде “случайных” попаданий сайтов, которые кажутся новыми, а проиндексированы давно. Может, подкрутили что-нибудь, и релевантность по запросу “ru” у сайта увеличилась. 🙂 Ну и, конечно, дополнительные обновления есть – число найденных документов по дате колеблется во времени. Не важно, почему.

Только выплыл дополнительно, может, один сайтик, который и попался скрипту, а делается вывод о мегаапдейте. Которого 99% юзеров не заметят, зато заметят 99% сеошников. Вот например: “замечен” апдейт 25.03.2008 04:01:06, которого не было, несколько доапов от 19.03.2008, которых тоже не было (разница в несколько минут = это один и тот же апдейт).

К счастью, большинство сайтов с датой настроены правильно. Итак, как работает мой апометр.

Он перебирает запросы вида date=”YYYYMMDD” от сегодня в прошлое. Пока индексированное в эту дату не выложено – находится порядка 100 говносайтов. А когда при следующей пробивке число сайтов возрастает до 30-50 тысяч, значит, выложили – апдейт, типа. Текстовый апдейт. Заодно бонус: можно точно знать, документы за какие даты выложены, а какие – нет.

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

Подписка на RSS