К основному содержанию

Как три месяца собирать данные Яндекса и не заметить, что это Google

Пересказ по материалу Habr SEO

Как три месяца собирать данные Яндекса и не заметить, что это Google

Задача простая: отслеживать позиции статей на чужих площадках. Search Console и Яндекс.Вебмастер тут бесполезны — они видят только домены, которые ты сам подтвердил. Поэтому схема стандартная: платный API возвращает органическую выдачу по запросу, скрипт ищет нужный URL и пишет место в базу.

С 7 июля по 13 октября 2026 года скрипт работал без сбоев. За это время в базе накопилось 42 477 строк замеров. В отчётах они значились как «позиции в Яндексе». 13 октября выяснилось: все эти строки — данные Google.

Один символ, три месяца ошибки

У провайдера выдачи два эндпоинта с идентичным форматом ответа. Один отдаёт Яндекс, другой — Google. Формат JSON одинаковый, поля те же, структура та же. Скрипт принимал ответ, парсил его и писал в базу — не проверяя, к какому адресу обращался.

Разница между двумя адресами — один символ в URL. Именно это и осталось незамеченным.

Это не баг API и не сбой на стороне провайдера. Скрипт делал ровно то, что ему сказали. Просто в конфиге стоял не тот адрес.

Почему это не заметили раньше

Данные выглядели правдоподобно. Позиции менялись, колебания были в разумных пределах, никаких аномалий на первый взгляд. Если не знаешь, чего ожидать от Яндекса по конкретным ключам, отличить его выдачу от Google по цифрам позиций невозможно — форматы идентичны.

Проверка «а правильный ли поисковик отвечает» просто не была заложена в скрипт. Запрос уходил, ответ приходил, URL находился — всё работало. Валидация источника отсутствовала.

Как проверять поисковик в ответе

После того как ошибка вскрылась, в скрипт добавили явную проверку: перед записью в базу смотреть, какой поисковик фактически ответил. Провайдер возвращает это в метаданных или в заголовках — зависит от конкретного API.

Минимум, который стоит добавить в любой подобный скрипт:

  • логировать фактический URL эндпоинта при каждом запросе;
  • сверять идентификатор поисковика из ответа с ожидаемым;
  • при несовпадении — не писать в базу, а бросать ошибку.

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

Что изменилось в выводах

Когда те же ключевые запросы сняли в Яндексе — уже правильно — картина оказалась другой. Позиции по части запросов расходились с Google существенно. Это логично: алгоритмы разные, аудитория разная, и выдача по одному и тому же запросу в двух поисковиках может отличаться кардинально.

Три месяца оптимизационных решений принимались на основе Google-данных, хотя целевой трафик для части площадок шёл из Яндекса. Насколько это повлияло на реальные результаты — отдельный вопрос, но сам факт говорит сам за себя.

Что взять из этого опыта

Если ты снимаешь позиции через сторонний API, особенно когда у провайдера несколько поисковиков с одинаковым форматом ответа, явная валидация источника — не паранойя, а базовая гигиена.

Формат ответа «выглядит правильно» не означает, что данные те, которые нужны. Скрипт не знает твоих намерений — он знает только то, что ему сказали сделать.

TG X Скопировано

Спонсоры проекта

Компании, которые помогают держать аналитику открытой