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

Один из читателей Хабра рассказал, как три месяца снимал позиции через API и только спустя 42 477 строк обнаружил, что все замеры были сделаны в Google, хотя в отчётах значились как «позиции в Яндексе». Причина — провайдер выдачи предоставлял два адреса с одинаковым форматом ответа, и скрипт обращался не к тому. Эта история — хороший повод разобрать, как выстроить проверку позиций через API так, чтобы данные вызывали доверие.

Почему позиции на чужих площадках — отдельная задача

Когда статья выходит на стороннем ресурсе, вы не можете добавить его в панели вебмастера. Значит, остаётся только внешний сбор: отправлять запросы к поисковой выдаче, получать топ-10 или топ-50 результатов и проверять, на каком месте стоит нужный URL. Это касается и ссылочного продвижения, и гостевых публикаций, и работы с PR-статьями. Без автоматизации такой мониторинг быстро превращается в рутину, поэтому API — разумный выбор. Но у него есть особенность: вы получаете «сырые» данные и сами отвечаете за их корректность.

Типичная ошибка — доверять названию метода или конечной точки. Провайдеры часто делают универсальные эндпоинты, где поисковик задаётся параметром. Если перепутать значение или использовать устаревший адрес, ответ придёт в том же формате, и скрипт не заметит подмены. В итоге отчёт будет красивым, но бесполезным.

Как проверить, какой поисковик отвечает

Первое, что стоит сделать перед запуском регулярного сбора, — добавить в скрипт явную валидацию источника. Не полагайтесь на то, что провайдер вернёт ожидаемое. Вот несколько практических шагов.

  • Сверяйте контрольные запросы. Возьмите 3–5 запросов, по которым вы точно знаете выдачу вручную. Сравните первые 10 результатов из API с тем, что видите в браузере. Если расхождения системные — скорее всего, вы получаете данные из другого поисковика или региона.
  • Проверяйте домены в ответе. У Яндекса и Google разная структура выдачи. Например, Яндекс часто показывает больше своих сервисов и ссылок на Маркет, а Google — блоки с вопросами и видео. Но это косвенный признак, поэтому используйте его только в паре с другими проверками.
  • Смотрите на параметры запроса. В документации API обычно указано, как передаётся поисковик. Если параметр необязательный, задайте его явно и залогируйте в ответе. Пусть скрипт сохраняет не только позицию, но и фактический источник.
  • Ведите журнал вызовов. Записывайте дату, запрос, URL, позицию и идентификатор поисковика. Это поможет при разборе инцидентов и не потребует перезапускать сбор.

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

Что делать с уже собранными данными

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

Полезно сравнить, как те же ключи вели себя в Яндексе и Google. Часто результаты отличаются: одни статьи лучше ранжируются в Google, другие — в Яндексе. Это нормально и даже полезно. Главное — не делать выводов на основе перепутанных данных. Например, если вы три месяца смотрели Google, а думали, что это Яндекс, вы могли неверно оценить эффективность площадки и зря отказаться от размещения.

Как выстроить регулярную проверку

Чтобы история не повторилась, включите в процесс несколько простых правил.

  • Автоматический алерт на аномалии. Если доля статей в топ-10 резко меняется или позиции становятся подозрительно стабильными, скрипт должен сигнализировать. Это может указывать на смену источника или сбой в API.
  • Ручная сверка раз в месяц. Выберите 5 случайных запросов и проверьте выдачу вручную. Это занимает 10–15 минут, но даёт уверенность в данных.
  • Документируйте настройки. Храните в репозитории конфиг с указанием поисковика, региона и параметров запроса. Если коллега или вы сами вернётесь к проекту через полгода, не придётся гадать, что было настроено.
  • Разделяйте отчёты по поисковикам. Не сводите Яндекс и Google в одну таблицу без явной маркировки. Лучше сделать два листа или два отчёта.

И последнее: не гонитесь за количеством строк. 42 тысячи замеров не имеют ценности, если они не отвечают на ваш вопрос. Лучше меньше данных, но с проверенным источником и понятной методикой.