Яндекс.Вебмастер API и мониторинг: автоматизация проверок и уведомлений
1. Архитектура и принцип работы
Вы регистрируете приложение в OAuth-сервисе Яндекса, получаете client_id и секрет, обмениваете код авторизации на access_token с правом webmaster:hostinfo и webmaster:verify. Дальше скрипт по расписанию (cron или очередь) дергает методы: /v4/user, /v4/hosts, /v4/host/{host_id}/summary, /v4/host/{host_id}/indexing/history, /v4/host/{host_id}/search-queries/popular, /v4/host/{host_id}/diagnostics. Ответы складываются в таблицу с датой среза — так появляется временной ряд. Отдельный слой правил сравнивает свежий срез с предыдущим и с порогом: упало число страниц в индексе, выросло число ошибок 4xx, появилось предупреждение о санкциях, просел показ по ключевой группе. Сработал порог — уходит сообщение в Telegram или почту с ссылкой на конкретный хост и diff. Для B2B это критично: каталоги и разделы решений меняются редко, но дорого, и тихое выпадение сотни страниц из индекса замечают только по лидам через месяц.
2. Математическая механика и триггеры ранжирования
Токен живёт ограниченное время, поэтому нужен refresh-flow: храните refresh_token в секрете, обновляйте access_token до истечения. Лимиты запросов считаются по user_id, а не по приложению — при нескольких проектах разносите опрос по времени и кэшируйте ответы на 6–12 часов. Ключевые поля для алертов: indexing.history[].pages_verdict — доля страниц, исключённых из поиска (норма < 5%, тревога > 15%); diagnostics — список критичных ошибок с codes; search_queries — показы и клики по запросам, из них считаем CTR = clicks / shows и позицию как средневзвешенную. Для тренда стройте z-score: z = (x_t - μ) / σ по скользящему окну 28 дней, алерт при |z| > 2.5. Для санкций отдельный флаг: наличие сообщения в diagnostics с типом санкции = мгновенный алерт без порога. Храните сырой JSON — потом пересчитаете метрики без повторных вызовов API.
3. Специфика в Яндекс (YATI) vs Google
В Google аналог — Search Console API, но модели данных расходятся. У Яндекса есть ИКС и история индексации по дням через API, у Google — свои отчёты Coverage с задержкой и иным набором статусов. Яндекс отдаёт популярные поисковые запросы агрегированно (без точных позиций по каждому URL), Google — через Search Analytics с фильтрами по страницам и странам. Авторизация: у Яндекса OAuth с refresh_token, у Google — сервисный аккаунт или OAuth, лимиты жёстче по квоте на проект. Санкции Яндекс показывает текстом в диагностике, Google — через отчёт о ручных мерах. Для B2B с RU-трафиком Яндекс.Вебмастер API — основной источник, Search Console держите как второй контур для англоязычных лендингов и проверки hreflang.
4. Нормативы SLA и диагностическая матрица
| Параметр / Метрика | Эталон по SLA | Критическая ошибка |
|---|---|---|
| Доля исключённых из поиска страниц | < 5% | > 15% |
| Критичные ошибки обхода (4xx/5xx) | < 1% URL | > 5% URL |
| z-score показов по кластеру (окно 28 дней) | |z| < 2 | |z| > 2.5 |
5. Пошаговый инженерный протокол внедрения
- Зарегистрируйте OAuth-приложение, получите refresh_token и положите его в секрет-хранилище; напишите функцию обновления access_token с обработкой 401.
- Соберите cron-задачу: раз в сутки снимайте summary, indexing/history, diagnostics и search-queries по каждому host_id, пишите срез в таблицу с датой.
- Настройте правила алертов: падение страниц в индексе > 10% за 7 дней, рост критичных ошибок обхода, появление санкций, падение показов по группе B2B-запросов > 20%.
- Сделайте дашборд с трендом ИКС, долей исключённых страниц и CTR по кластерам; алерты шлите в Telegram с diff и ссылкой на раздел панели.
// псевдокод ежедневного снимка и алерта
const snap = await api.get(`/v4/host/${hostId}/indexing/history`, {token});
const excluded = snap.pages_verdict.excluded / snap.pages_verdict.total;
const prev = db.lastSnapshot(hostId);
const drop = (prev.indexed - snap.indexed) / prev.indexed;
if (excluded > 0.15 || drop > 0.10) {
notify(`host ${hostId}: excluded=${(excluded*100).toFixed(1)}%, drop=${(drop*100).toFixed(1)}%`);
}
db.save({hostId, date: today(), raw: snap});6. Типичные ошибки при оптимизации
- Хранить только агрегаты без сырого JSON — при смене логики метрик приходится заново дергать API и терять историю.
- Опрашивать API каждые 15 минут и упираться в лимиты по user_id; данные индексации обновляются раз в сутки, чаще нет смысла.
- Ставить алерты на абсолютные числа без сезонной нормализации — B2B-спрос падает в январе и августе, и вы получите ложные тревоги.