Мониторинг поисковой выдачи: архитектура и лимиты

Для мониторинга выдачи используйте официальный API или разрешённого поставщика данных. HTML-страницы поисковых сервисов меняются часто, а техническая возможность загрузить страницу не означает разрешение на массовый сбор.

Сначала зафиксируйте единицу измерения

Позиция существует только в контексте:

• запроса;
• региона и языка;
• устройства;
• даты и времени;
• типа результата;
• глубины выдачи.

Без этих полей сравнение «позиция была 8, стала 12» не воспроизводимо.

CREATE TABLE search_positions (
    query_id BIGINT NOT NULL,
    observed_at TIMESTAMP NOT NULL,
    region VARCHAR(50) NOT NULL,
    device VARCHAR(20) NOT NULL,
    result_type VARCHAR(30) NOT NULL,
    rank INTEGER,
    target_url TEXT,
    source VARCHAR(50) NOT NULL,
    PRIMARY KEY (query_id, observed_at, region, device, result_type)
);

Отсутствие URL в первых N результатах храните отдельно от ошибки API.

Почему API предпочтительнее HTML

Официальный API даёт документированный формат, лимиты и условия использования. Это снижает риск, что изменение DOM превратится в ложное падение позиций.

При выборе источника проверьте:

1. Разрешено ли хранение результатов.
2. Как задаются регион и язык.
3. Есть ли лимит запросов в минуту и сутки.
4. Как API сообщает исчерпание квоты.
5. Какие типы результата входят в позицию.

Очередь запросов

Не запускайте весь список ключей одновременно. Разделите очередь по региону и источнику, установите лимит параллельности и бюджет повторов.

import asyncio
import random

async def run_with_backoff(call, attempts=3):
    for attempt in range(attempts):
        result = await call()
        if result.status != 429:
            return result
        await asyncio.sleep((2 ** attempt) + random.uniform(0, 0.5))
    raise RuntimeError("Лимит повторов исчерпан")

Если API возвращает Retry-After, он должен иметь приоритет над локальным backoff. Не распределяйте запросы по IP ради обхода квоты ключа.

Контроль качества

Сохраняйте отдельно:

• число запланированных запросов;
• число корректных ответов;
• 429, 5xx и timeout;
• ответы без органических результатов;
• долю URL, которые удалось нормализовать;
• стоимость одного корректного снимка.

Резкое падение числа найденных URL может означать изменение формата ответа, а не изменение поисковой видимости.

Каннибализация на собственном сайте

Для SEO-аудита выгрузите из GSC и Яндекс.Вебмастера пары «запрос → URL». Если по одному интенту показываются две статьи, сравните:

• какой URL получает клики;
• совпадает ли интент;
• есть ли уникальная полезность у каждой страницы;
• можно ли объединить содержание без потери ответа.

301 уместен, когда старый URL имеет близкий новый аналог. Если аналога нет, не перенаправляйте пользователя на нерелевантную страницу.

Этичность и ограничения

Используйте официальный API, если он доступен. Соблюдайте условия хранения и перепубликации данных. Не обходите авторизацию и квоты, не собирайте персональные профили и не создавайте лишнюю нагрузку на HTML-интерфейс. Кэшируйте неизменяемые справочники и используйте честную идентификацию клиента.

Для диагностики сетевой части прочитайте разбор 403, 429 и timeout. Условия прокси-инфраструктуры собраны на странице продукта.

Ключевые выводы

• Позиция без региона, устройства и времени не воспроизводима.
• Ошибка API и отсутствие URL в выдаче — разные состояния.
• Retry-After и квоты нельзя заменять ротацией IP.
• Решение о каннибализации требует пары «запрос → URL».

Краткий ответ: мониторьте выдачу через разрешённый API, храните полный контекст позиции и отделяйте изменения формата данных от реального движения URL.