Клуб API Вебмастера

Скрипты PHP, грабли в документации, посыл к разработчикам

isocorp
6 июня 2012, 00:03

Добрый день!

Увидев в один прекрасный день возможность подключиться к вебмастеру через апи мы очень вдохновились: у нас много сайтов (своих и клиентских) за которыми в самом вебмастере не всегда удобно следить:

* на первой странице непонятно, когда робот посещал сайт (а очень надо для кол-ва сайтов от 30ти)

* по некоторым данным нереально построить графики

* на крупных сайтах (>100тыс страниц) некоторые события можно и нужно обрабатывать автоматически.

 Возможности классического вебмастера решали нас всего этого и новость об апи в наших головах звучала как "УРА!!! Сбылась наша мечта".

 

Ну а дальше начались приключения. К слову сказать они не кончились до сих пор и пост пишется лишь в процессе работы.

Первым делом мы узнали, что для работы нашего приложения его надо зарегистрировать. Форма была заполнена и мы стали ждать. Плохо что прошел месяц, хорошо что нас активировали.

Получив доступ начался процесс написания кода.

Следующей проблемой стала авторизация. В данном случае нам очень помогли записи в клубе, за что всем большое спасибо. Однако механизм авторизации через запрос пользователю и выдачи токена на определенное время в нашем случае хоть и работоспособен, но крайне неудобен как нам так и пользователю.

1. Если пользователь дает нам свой логин/пароль, то зачем еще и подтверждение? Зная логин/пароль мы вручную сделаем подтверждение.

2. Наш сервис работает 24/7, чтобудет при истечении токена? Опять продлять? Брррр. Радуемся, что токен выдается на полгода. Не радуемся "утяжелению" интерфейса и усложнением процесса для нашего любимого пользователя.

В защиту сервиса, как большое спасибо скажу, что совершенно идеально работают:

* запрос UID

* запрос сервисного 

* запрос списка сайтов

* запрос информации по хосту

* получение статистики по хосту

Дальше увидели проблему с тем, что указанный в доках адрес /api/<uid>/hosts/<host_id>/errors не работает, вместо него надо использовать  /api/<uid>/hosts/<host_id>/excluded.

Кроме того, по указанному адресу не выводятся "битые" страницы - а без этого смысл теряется.

Дальше есть проблема, которую мы не откапали в документации: в доках про severity написано "от 0 до 100", а нам выдает "WARNING", и непонятно что это значит.

Очень просим устранить данный недостаток документации и добавить вывод "битых" урлов, т.к. в них вся "соль".

Следующим этапом идет /api/<uid>/hosts/<host_id>/indexed.

1. Данных за последнюю неделю мало! Просто не понятно, где их вообще можно применять?

2. Эти данные не выводятся))) Проверено на сайте с ID 6771092: ряд страниц было создано в конце прошлой недели, а в поиске (и в вебмастере) по факту появились сегодня. В апи не выдаются.

Тоже просим добавить и починить функционал!

/api/<uid>/hosts/<host_id>/tops порадовал, большое спасибо, лучше и представить сложно!

С /api/<uid>/hosts/<host_id>/links ситуация аналогичная indexed - выводятся только последние ссылки, но у нас не вывелось на примере того же сайта.

 

Подведу итог. В целом новое апи это здоровский шаг вебмастера на встречу крупным вебстудиям, в том числе и нам. Но я верю, что это только первый шаг: в таком виде целесообразность встраивания АПИ в нашу систему практически равна нулю, т.к. ничего нового/интересного мы пользователям не покажем. Думаю найдется много людей искренне симпатизирующих вебмастеру (в т.ч. наша команда), которые желают сервису всего наилучшего. В этом ключе я хочу пожелать скорее сделать следующий шаг, чтобы мы могли на базе апишки делать готовые и реально полезные решения.

 

Ну и как обещал прилагаю скрипт на PHP, который демонстрирует всю работу с апишкой:

 http://actual-media.ru/seo.php.txt  

2 комментария
Подписаться на комментарии к посту
Большое спасибо за развернутый отзыв!

Документацию проверим ещё раз и поправим в ближайшее время.

Выдавать все проиндексированные страницы и все ссылки не планируем.
Выдавать исключённые страницы будем.

Что касается авторизации, то позволю себе не согласиться: передача логина и пароля - совершенно неадекватный вариант. Пользователь не должен давать полный доступ к аккаунту Яндекса для того, чтобы сторонний сервис мог пользоваться API.

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

Ещё раз спасибо!

Да, поправлюсь: месяц прошел с момента регистрации приложения до момента, когда мы реально смогли пользоваться. Спустя две недели мы отправили запрос в саппорт и нам через неделю прислали заявку, которую как оказалось надо заполнить. Спустя еще неделю нам сказали куда ее отправить). Ну а после отправки активировали в тот же день.

Думаю если форму заявки и соответствующий текст поместить в регистрацию, то другие не столкнутся с этой проблемой.

С чем связана политика компании в отношении проиндексированных страниц и ссылок? Защита от пресловутых сеошников? Просто у нас этому есть ряд, вполне "вменяемых" применений:

* если появилась новая ссылка: это повод для менеджеров связаться с администрацией ресурса, поблагодарить и попросить чтобы не удаляли. если ссылка на некачественном ресурсе/обрамлена в плохой отзыв - написать попросить удалить/написать вменяемый ответ

* если появились новые страницы в индексе: повод перепроверить их еще раз, просмотреть их сниппет в поиске и возможно поправить description для большей вменяемости выдачи. кроме того нам например важен анализ по страницам: чтобы не было одинаковых титлов, чтобы контент не дублировался и т.п. Это важно. Пока в вебмастере этого функционала нет, люди по-прежнему будут получать эти данные из xml.yandex.ru по запросам вида site:test.ru... Не лучше ли легализовать данную операцию?

* про исключенные страницы вообще понятно: если это технический косяк - исправляем, нетехнический - смотрим откуда такая ссылка вообще взялась...

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

Насчет доступа ко всему яндексу: пожалуй да, такой момент присутствует, однако пусть пользователь лучше сам скажет: вот этому приложению я даю доступ туда и туда на таких правах на такой срок. Если ему это станет ненужно: нажимает удалить и все, проблема снята. При этом приложению выдается стабильный единый токен или связка UID:token.

В любом случае спасибо и за сервис и за ответ.

Хотел узнать: проблема с выдачей последних данных по ссылкам/проиндексированным будет разобрана и исправлена? 

И второй насущный вопрос, который нигде не озвучен: не так давно вебмастер проводил опрос. Он конечно вызвал нарекания у нашей команды, т.к. возможности ответить то, что мы хотели практически не было. Но все же: какие данные опроса и какие выводы команды на его основании. Если секретно), то хотя бы: какие фишки ждут нас в ближайшем будущем, куда направлены взоры разработчиков?