Сопоставление ссылок и запросов в Search Console через отчет API

Что вы пытаетесь измерить (и чего не пытаетесь)

Сопоставление «ссылка→запрос» в Search Console объединяет три вещи в одном виде: конкретную страницу, запросы, по которым эта страница показывается, и ссылающиеся страницы, которые начали на неё ссылаться.

Цель не в том, чтобы доказать, что ссылка вызвала скачок в ранжировании. Google не помечает показы или клики меткой «это произошло из‑за ссылки X», и позиции меняются по множеству других причин (изменения контента, внутренняя перелинковка, сезонность, действия конкурентов и обновления Google). Временные рамки тоже запутаны: ссылка может появиться сегодня, а быть обнаружена через дни или недели.

Практическая цель проще: связать новые ссылающиеся страницы с изменениями показов и средней позиции для точного URL по каждому запросу. Это даёт удобный нарратив вроде: «У этой страницы появились новые ссылки, затем видимость улучшилась по этим запросам». Это корреляция с оговорками, а не доказательство в суде.

Что может сказать этот отчёт

При аккуратном использовании отчет API Search Console такого типа может ответить на несколько важных вопросов:

• По каким запросам у URL увеличились или уменьшились показы после появления новых ссылающихся страниц.
• Ухудшилась ли, улучшилась ли или осталась стабильной тенденция по средней позиции того же URL в тот же период.
• Каким новым ссылкам соответствует наибольшие изменения, чтобы знать, что проверять в первую очередь.

Что этот отчёт не скажет

Этот отчёт не сможет надёжно:

• Назначать кредит одной ссылке или вычислять точную «ценность ссылки» для запроса.
• Отделять влияние ссылок от других работ по SEO без дополнительных контролей.
• Гарантировать, что Google посчитал или доверил ссылке только потому, что она существует.

Пример: ваша страница с прайсами получает две новые ссылки из отраслевых статей. В течение следующих 14 дней показы растут по «product pricing» и «enterprise pricing», тогда как «free trial pricing» остаётся на месте. Это не доказывает, что ссылки вызвали рост, но показывает, что страница стала чаще показываться по определённым запросам после появления новых ссылающихся страниц.

Если вы используете сервис размещений, например SEOBoosty, для направления премиальных бэклинков на конкретную страницу, такое сопоставление служит здравым смыслом: оно фокусирует внимание на том, двигалась ли видимость именно этого URL, вместо опоры на средние по сайту.

Данные, которые вы будете комбинировать из Search Console

Вам нужны два разных представления из Search Console. Одно показывает, что происходило в поиске (показы, клики, позиция). Другое показывает, какие страницы в интернете ссылаются на вас.

1) Данные производительности (что изменилось в поиске)

Это получается из отчёта Performance в Search Console (через метод Search Analytics в API). Это самый понятный способ измерить результаты, такие как показы и средняя позиция.

Выгружайте метрики: клики, показы, CTR и среднюю позицию, группируя их по измерениям, которые объясняют движение. Для этого отчёта наиболее полезны измерения page, query и date. Страна и устройство помогают, если у вас смешанные рынки или сильные различия мобильный vs десктоп.

Практическое правило: всегда включайте page. Добавляйте query, когда хотите знать, какие поисковые запросы изменились, а не только изменилась ли страница.

2) Данные по ссылкам (что изменилось вне сайта)

Это получается из отчёта Links в Search Console (через соответствующие endpoints). Здесь вы находите ссылающиеся страницы, которые ссылаются на ваш сайт.

Для сопоставления «ссылка→запрос» важны поля:

• target page (на какой из ваших URL указывает ссылка)
• linking page (конкретная внешняя страница, которая ссылается)
• linking site (домен, удобно для агрегации)

Данные ссылок не говорят, какой запрос повлияла ссылка. Они лишь показывают, что ссылка существует для данного целевого URL. Любая «атрибуция» в отчёте базируется на тайминге и затронутом URL, а не на доказанной причине.

Почему нужны окна «до» и «после»

Ссылки и позиции не меняются в один и тот же день, а данные Search Console не идеально реального времени. Смотрение на одну дату создаёт шум.

Используйте два равных временных окна для данных производительности:

• окно «до» для установки базовой линии
• окно «после» для измерения изменения

Затем увяжите новые ссылающиеся страницы по дате первого обнаружения и сравните производительность до и после.

Если нужно запомнить одну модель: Performance объясняет движение; Links подсказывает, что могло его триггернуть. Совмещение по URL — вот в чём смысл.

Определите область, окна и правило для «новых ссылок»

Этот отчёт работает только если вы зафиксируете область до начала. Если вы меняете набор URL или временные окна по ходу, результаты поплывут по причинам, не связанным со ссылками.

Начните с набора целевых URL и придерживайтесь его: одна важная страница, папка или небольшой набор шаблонов (например страницы товаров). Чем уже набор, тем проще связать новые ссылающиеся страницы с изменениями показов и средней позиции.

Далее выберите два равных окна. Для многих сайтов 28 дней vs следующие 28 дней — хорошая настройка по умолчанию, она сглаживает ежедневные колебания.

Теперь определите «новую» ссылку. Простое правило: ссылающаяся страница считается «новой», если до окна сравнения у неё не было зафиксированных ссылок на целевой набор URL, а в окне сравнения появилась хотя бы одна зафиксированная ссылка. Если источник ссылок обновляется медленно, добавьте небольшой буфер, например исключите первые несколько дней окна сравнения из определения «новой ссылки».

Чтобы уменьшить шум, установите минимальные пороги перед вычислением изменений. Иначе один случайный показ может выглядеть как «скачок позиции». Например:

• Включайте только целевые URL с как минимум X показами в обоих окнах (пример: 100)
• Включайте только запросы с как минимум Y показами в обоих окнах (пример: 10)
• Требуйте как минимум Z активных дней с показами в каждом окне (пример: 10 дней)
• Игнорируйте изменения позиции при слишком низких показах, чтобы данные были нестабильны

Пример: в базовых 28 днях ваша страница с прайсами получила 1 200 показов со средней позицией 11.2. В следующих 28 днях — 1 650 показов со средней позицией 9.8. Ваши правила помогут считать это значимым, в то время как страницы с показами 3→9 будут проигнорированы.

Если вы отслеживаете размещения от провайдера (включая платные размещения), рассматривайте каждую ссылающуюся страницу как своё отдельное событие «новая ссылающаяся страница». Это позволит сравнивать результаты по источникам, не сваливая несколько изменений в одно.

Спроектируйте простую модель данных для отчёта

Держите модель данных простой. Три таблицы плюс общие правила по URL и датам — достаточно. Если ключи согласованы, отчёт становится обычными JOIN‑ами и сравнением.

1) Таблица целевых URL (страницы, которые вас интересуют)

Это ваш каталог страниц. Она предотвращает дублирование, когда одна и та же страница появляется с параметрами, разным регистром или со слэшем в конце.

Храните:

• target_url_canonical: канонический URL, по которому вы отчётите
• target_url_normalized: нормализованный ключ для объединения (см. правила ниже)
• page_type: категория, товар, блог, документация и т.д.
• notes: опционально, например «высокоценная страница» или «недавно обновлена»

2) Таблица ссылающихся страниц (новые ссылки)

Это «что изменилось» — каждая строка — ссылающаяся страница, указывающая на один из ваших целевых URL.

Храните:

• referring_url: точная страница, которая ссылается на вас
• referring_url_normalized: нормализованная для дедупа
• referring_domain: извлечённый домен (для группировок)
• target_url_normalized: связь обратно к целевому URL
• first_seen_date: дата первого наблюдения ссылки (или дата, когда её сообщил провайдер)

Если одна ссылающаяся страница ссылается на два целевых URL, храните две строки. Сопоставление должно оставаться явным.

3) Таблица производительности (вывод Search Console)

Храните данные производительности на самом низком полезном уровне, чтобы потом можно было сворачивать.

Храните:

• date
• target_url_normalized
• query
• impressions
• clicks (опционально, но обычно стоит хранить)
• position (средняя позиция из Search Console)

Избегайте ранней агрегации. Вы всегда можете просуммировать показы позже, но не сможете восстановить детализацию по запросам, если её свернёте.

Стратегия ключей для JOIN (правила, которые всё держат в согласии)

Выберите правила один раз и применяйте везде:

• Нормализованный URL: приводите хост к нижнему регистру, убирайте фрагменты и стандартизируйте слэши в конце. Решите, как обрабатывать параметры (часто: удалять tracking‑параметры, сохранять смысловые).
• Извлечение домена: храните регистрируемый домен или хотя бы хост, чтобы можно было аккуратно группировать по домену.
• Корзины по датам: создайте поле date_bucket, например неделя (YYYY-WW) или месяц (YYYY-MM), чтобы сравнения были устойчивее, чем по сырым дням.

С этими тремя таблицами и согласованными ключами итоговый отчёт — это новые ссылающиеся страницы (по дате первого обнаружения), объединённые с изменениями производительности (по URL, запросу и date_bucket).

Пошагово: получение данных через Search Console API

Начните с надёжных данных производительности, затем добавьте новые ссылающиеся страницы из отдельного источника. Стандартный Search Console API рассчитан на отчёты по производительности, а не на полный экспорт Links.

1) Доступ к правильному свойству

Выгружайте данные из того же свойства, которым пользуется ваша команда в Search Console (Domain property vs URL‑prefix property). Неправильное свойство заставит ссылки или показатели «исчезнуть», хотя вы просто смотрите на другой набор данных.

Перед запуском убедитесь:

• ваша учётная запись Google имеет права на это свойство (Owner или Full user)
• API Search Console включён в проекте Google Cloud
• вы можете перечислить сайт в API (быстрая проверка на месте)

2) Выгрузка производительности по странице + запросу (желательно по дням)

Используйте метод Search Analytics. Выберите диапазон дат и запросите измерения, позволяющие привязать изменения к конкретному URL и поисковому запросу.

Практическая стартовая конфигурация:

• Измерения: date, page, query
• Метрики: clicks, impressions, position
• Дополнительно: фильтры по стране/устройству, если сайт сильно варьируется

Добавление измерений увеличивает число строк. Планируйте пагинацию с использованием startRow до конца.

Вот минимальная структура тела запроса, которую можно переиспользовать в скрипте:

{
  "startDate": "2026-01-01",
  "endDate": "2026-01-31",
  "dimensions": ["date", "page", "query"],
  "rowLimit": 25000,
  "startRow": 0
}

3) Получение данных «новых ссылающихся страниц» (что возможно)

Отчёт Links удобен в UI, но Google не даёт через стандартный API такой же выгрузки «top linking pages -> target page».

Если нужны URL ссылающихся страниц, обычно есть два варианта:

• Экспортировать отчёт Links из UI Search Console по расписанию и загружать этот файл.
• Использовать отдельный источник бэклинков и сопоставлять с целевыми URL.

В любом случае сохраняйте исходный URL ссылающейся страницы, целевой URL и дату первого обнаружения (или дату экспорта), чтобы позже классифицировать «новые» ссылки.

4) Храните необработанные ответы до трансформации

Сохраняйте каждый ответ API (и параметры запроса, которые его породили) как raw JSON‑файлы или строки в raw‑таблице. Повторы становятся проще, когда вы меняете правила сопоставления, окна дат или фильтры. Это также полезно, когда кто‑то спросит, почему у URL изменилась средняя позиция — вы сможете показать, что вернул API.

Пошагово: очистка, сопоставление и вычисление изменений

Отчёт живёт и умирает по тому, насколько хорошо вы сопоставляете одинаковые URL в разных наборах данных. Если URL не соединяются, «вклад» превращается в случайность.

1) Нормализуйте URL, чтобы строки действительно объединялись

Выберите каноническую форму для каждого целевого URL и применяйте одни и те же правила везде (страницы Search Console, список бэклинков и итоговый отчёт).

Типичные исправления:

• Один протокол и хост-стиль (например всегда https и предпочтительный хост).
• Стандартизация слэшей в конце, чтобы /page и /page/ не дробили сигнал.
• Удаление tracking‑параметров (utm_*, gclid, fbclid) и сохранение только значимых параметров.
• Обработка очевидных дубликатов вроде index.html.

После нормализации создайте стабильный ключ (normalized_url) и объедините таблицу ссылающихся страниц и данные производительности Search Console по этому ключу.

2) Группируйте запросы, но не превращайте это в проект по таксономии

Группировка запросов должна отвечать на вопрос: выросла ли видимость в основном по брендовым запросам, по небрендовым или по тому и другому?

Держите это лёгким. Две метки на запрос обычно достаточно: бренд vs небренд, плюс простая разметка по намерению (информационный, коммерческий, навигационный). Используйте краткие редактируемые правила. Например, бренд — это «запрос содержит имя бренда или товара», навигационный включает «login» или «pricing», а всё остальное помечайте как информационное или коммерческое на основе небольшого списка ключевых слов.

3) Вычисляйте дельты и привязывайте к дате «первого обнаружения»

Для каждой ссылающейся страницы храните link_first_seen как самую раннюю дату, когда вы заметили ссылку на целевой URL. Затем привязывайте её к вашим окнам.

Простое правило:

• before_window = 28 дней, заканчивающихся на день перед link_first_seen
• after_window = 28 дней, начиная с link_first_seen

Вычисляйте изменения на уровне (target URL, группа запросов), затем сворачивайте до уровня URL. Держите метрики простыми и понятными:

• Impressions delta = impressions_after - impressions_before
• Position delta = avg_position_after - avg_position_before (отрицательное — лучше)
• Visibility score = impressions * (1 / avg_position) или другая простая взвешенная метрика, которую вы используете последовательно
• Contribution share = дельта URL разделённая на общую дельту по сайту за тот же период

Пример: у поста в блоге появилась новая ссылающаяся страница с датой первого обнаружения 10 мая. За 28 дней до он имел 1 000 показов со средней позицией 14. За 28 дней после — 1 450 показов со средней позицией 11. В отчёте: +450 показов и −3 позиции; вы увидите, пришёл ли рост по небрендовым информационным запросам или по брендовым.

Если вы отслеживаете размещения от провайдера, фиксируйте такое же поле link_first_seen, чтобы окна были сопоставимы между разными источниками.

Соберите представления отчёта, которые люди действительно читают

Хороший отчёт «ссылка→запрос» — это не таблица Excel с десятками вкладок. Это небольшой набор представлений, который быстро отвечает на вопрос: «Что изменилось после того, как этой странице появились новые ссылки, и можно ли доверять сигналу?»

Вид 1: Сводка по URL (тот вид, который вы открываете первым)

Начинайте с одной строки на целевой URL. Делайте её удобочитаемой и делайте понятными «новые ссылающиеся страницы».

Включите:

• Целевой URL
• Количество новых ссылающихся страниц (в окне ссылок)
• Дата первого обнаружения (самая ранняя дата новой ссылки)
• Дельта по показам (до vs после)
• Дельта по средней позиции (до vs после)

Добавьте компактную ячейку «Новые ссылающиеся страницы» с 2–3 примерами (домен + дата первого обнаружения), а полный список доступен через drilldown или фильтр. Здесь читатели быстро проверяют, выглядят ли ссылки реальными или шумом.

Вид 2: Влияние по запросам для одного URL (вид «почему»)

Когда кто‑то кликает на URL, покажите запросы, которые сдвинулись. Ограничьте вывод лучшими двигателями.

Практическая раскладка:

Сортируйте по наибольшему приросту показов, добавьте фильтр для падений. Держите колонку «Note» для быстрого контекста: «брендовый запрос» или «появился SERP‑блок».

Контекстные колонки, которые предотвращают неверные выводы

Если вы дробите по устройству, стране или типу поиска, явно указывайте это в UI, чтобы читатели не смешивали яблоки и апельсины. Простой заголовок вроде «Device: Mobile» подойдёт.

Добавьте короткое поле «уверенность» на URL: «High» (чёткий рост по нескольким запросам), «Medium» (рост, но в основном по одному запросу), «Low» (тайминг пересекается с изменениями на сайте).

Реалистичный пример (без сложной математики)

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

Сценарий

Вы публикуете пост в блоге: /blog/on-page-checklist. На неделе 6–12 мая ваш лог источников ссылок показывает три новые ссылающиеся страницы, указывающие на этот URL. Две — релевантные статьи и одна — общий ресурс.

Задайте два окна:

• Before: 29 апр — 5 мая
• After: 6 мая — 12 мая

Теперь выгрузите метрики по запросам для этого URL из Search Console для обоих окон и посчитайте дельты.

Какие могут быть цифры

По запросу «on page checklist» показы подпрыгивают с 1 200 до 2 100 (+900), но средняя позиция почти не меняется (8.4 → 8.3). Это обычно значит, что вас стали показывать чаще, но позиция ещё не подросла. Частые причины: расширение охвата (длиннохвостые варианты) или рост спроса.

По запросу «on page seo steps» показы остаются примерно на месте (300 → 310), но позиция улучшается (14.2 → 10.8). Это может означать, что доверие к странице выросло для узкого набора запросов, даже если спрос не изменился.

Смысл: отчёт связывает дату первого обнаружения каждой новой ссылающейся страницы с окном сравнения и держит результаты по URL, а не агрегированными по всему сайту.

Как кратко подвести итоги в еженедельном апдейте

Коротко и по делу:

• Что изменилось: 3 новые ссылающиеся страницы к /blog/on-page-checklist (6–12 мая)
• Что двинулось: +900 показов по основному запросу; рост позиций по вторичному запросу
• Что это, вероятно, значит: сначала выросла видимость; позиции могут начать меняться через некоторое время
• Что смотреть дальше: повторить сравнение через неделю, чтобы увидеть, подтянется ли позиция

Если вы отслеживаете платные размещения через провайдера, этот еженедельный формат хорошо подходит для отчётов по каждой пакетной раздаче, не утверждая, что ссылки вызвали каждое изменение.

Общие ловушки, которые вводят в заблуждение

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

Ловушка 1: «Ссылка появилась, позиции двинулись, значит ссылка это сделала»

Совпадение дат — не доказательство. Данные Search Console могут приходить с задержкой, ссылки обнаруживаются медленно, и Google может повторно обработать сигналы позже. Ссылка может быть найдена в понедельник, показана в интерфейсе в четверг, а эффект — позже.

Рассматривайте ссылку как кандидат‑объяснение. Отчёт должен показывать, что изменилось, а не причину.

Ловушка 2: Разделение одной страницы на множество URL

Если вы смешиваете варианты URL, вы дробите сигнал и ваши сравнения «до» vs «после» становятся шумными. Частые виновники: http vs https, www vs non‑www, слэш в конце, параметры, регистр и канонизация.

Выберите одно правило нормализации и придерживайтесь его. Иначе вы можете обвинить «новые ссылки» в падении позиции, когда половина показов сидит на параметрическом URL.

Ловушка 3: Неровные окна сравнения

Сравнение 7 дней до с 28 днями после (или смешивание будних и выходных) создаёт фейковые подъемы и падения. У многих сайтов сильные паттерны по дням недели.

Если окна короткие, держите их симметричными и выравнивайте по дню недели. Для сезонных тем добавляйте заметки (запуски, праздники, PR), рядом с числами.

Ловушка 4: Рассматривать среднюю позицию как единую истину

Средняя позиция может сдвинуться только потому, что изменилась смесь показов. Если страница начала показываться по новому запросу на позиции 35 с большим числом показов, средняя позиция ухудшится, даже если основной запрос подтянулся.

Проверяйте распределение показов: в какую сторону сместились показы? Не доминировал ли один новый запрос в «после» периоде?

Ловушка 5: Игнорировать индексацию и изменения на странице

Отчёт «влияние ссылок» рушится, если сама страница изменилась. Переписывание заголовков, внутренние ссылки, обновления шаблона, правки контента и проблемы индексации — всё это влияет на показы и позиции.

Прежде чем приписывать эффект новой ссылке, убедитесь, что страница была стабильна и индексируема.

Ограждения, которые сохраняют честность отчёта:

• Используйте окна одинаковой длины (и выравнивайте по дням недели) для каждого сравнения.
• Нормализуйте URL и группируйте варианты запросов, где это имеет смысл.
• Отмечайте периоды с изменениями контента, редиректами или проблемами индексации.
• Анализируйте movers по запросам, а не только средние по странице.
• Рассматривайте «новые ссылающиеся страницы» как отправную точку, затем проверяйте другими сигналами.

Быстрые проверки и следующие шаги

Прежде чем доверять любому графику, проверьте входные данные. Сопоставление «ссылка→запрос» может выглядеть убедительно, даже когда URL, ссылка или данные по запросам не совпадают.

Быстрые проверки (5 минут)

• Подтвердите, что целевой URL последовательный: канонизирован так, как вы ожидаете, индексируем и не заблокирован директивами noindex, robots или неверной каноникой.
• Проверьте, что «новые ссылающиеся страницы» реальны: страница существует, не за логином и действительно ссылается на вашу страницу (а не просто на домен).
• Убедитесь, что ссылка указывает на правильную версию URL: http vs https, www vs non‑www, слэш, параметры и редиректы могут дробить сигнал.
• Проверьте объём выборки перед доверием к смещению позиции. При малых показах средняя позиция очень нестабильна.
• Просмотрите то же окно на предмет других изменений: правки заголовка, обновления шаблонов, редиректы, внутренние перелинковки, PR‑кампании или сезонный спрос.

Пример: вы видите новую ссылающуюся страницу и средняя позиция по запросу улучшилась с 14 до 9. Если у страницы было 30 показов до и 40 после — скачок может быть шумом. Если было 5 000 и 6 000 — сигнал более надёжный.

Следующие шаги, которые сохраняют полезность отчёта

Последовательность важнее сложных формул.

• Мониторьте еженедельно по тем же окнам и правилам.
• Добавляйте аннотации для падений ссылок и крупных изменений на сайте.
• Помечайте «высокоуверенные» страницы: стабильный URL, большой объём показов и явная новая ссылающаяся страница, которая ссылается прямо.
• Перепроверяйте через 2–4 недели. Ссылки и ранжирования редко двигаются синхронно, а данные Search Console могут запаздывать.

Если вы хотите более чистые тесты «до‑и‑после» для конкретных URL, контролируемые размещения помогают, поскольку вы можете фиксировать точные цели и даты. Например, SEOBoosty предлагает подписку на кураторские размещения, что упрощает сравнение результатов между похожими событиями размещений.

Держите проверки лёгкими и регулярными. Тогда отчёт останется читаемым, и вы будете тратить меньше времени на споры о крайних случаях.