SEO-аналитика многоязычного сайта через GSC API и BigQuery

SEO-аналитика многоязычного сайта означает сбор поисковых данных по языкам, странам, URL и запросам в единое хранилище. Ее используют, чтобы видеть органический трафик не только в интерфейсе GSC, но и в собственных отчетах, где можно сравнивать локали, страницы, каннибализацию и long-tail запросы. В реальных сценариях учитывайте лимиты API, задержку данных, нормализацию URL и то, что Search Console возвращает ограниченный набор агрегированных данных, а не полный сырой лог всех поисковых событий.

Для небольшого сайта достаточно открыть Search Console и посмотреть запросы вручную. Для проекта с десятью языками, сотнями шаблонов и тысячами страниц этого уже мало. Вам нужно сравнивать /uk/, /en/, /de/, страны, устройства, страницы и запросы в одном месте. Именно здесь помогает собственный pipeline через GSC API, BigQuery и регулярные загрузки. Для более широкой SEO-инфраструктуры полезно держать рядом материал про SEO для AI Search и резидентные прокси, потому что региональные проверки выдачи и аналитика часто идут вместе.

Главная ошибка в такой системе состоит в том, чтобы собирать слишком агрегированные данные. Если на этапе экспорта смешать страны, устройства или страницы, потом невозможно восстановить детализацию. Лучше хранить сырые срезы в BigQuery, а финальные метрики считать в отчетах. Для локальных направлений это особенно заметно: страница может хорошо работать в одной стране и проваливаться в другой, как в задачах локального SEO для Google Maps.

В многоязычном SEO данные быстро становятся похожими на задачи мониторинга цен или каталогов: много URL, много повторяющихся шаблонов, много мелких изменений. Поэтому архитектура должна быть ближе к data pipeline, чем к ручному экспорту CSV. Похожий подход к регулярному сбору и нормализации описан в материале о мониторинге цен в масштабе.

Какие показатели и срезы нужны многоязычному сайту

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

Минимальный набор метрик из GSC API: clicks, impressions, ctr, position. Минимальный набор измерений: date, page, query, country, device. Для Discover, Google News или видео нужен отдельный type, но для большинства SEO-отчетов базовым остается web.

Отдельно создайте поле language. Не полагайтесь на то, что аналитик всегда распознает язык по URL. Для сайтов с папками это может быть регулярное выражение с /uk/, /en/, /fr/. Для субдоменов нужна таблица соответствия host -> language. Для отдельных доменов, например example.de и example.fr, нужен еще и market.

После определения нужных срезов можно переходить к запросам API и правилам сегментации.

Как получать данные через Google Search Console API

GSC API возвращает данные за заданный диапазон дат, измерениями и фильтрами. Запрос к searchAnalytics.query должен содержать startDate, endDate, набор dimensions, опциональные фильтры, rowLimit, startRow и параметр dataState.

Согласно официальной документации, rowLimit имеет диапазон до 25 000 строк, а startRow используется для пагинации. Но на больших сайтах простая пагинация не решает проблему полностью: API может не отдать все возможные комбинации, если количество уникальных комбинаций измерений слишком велико. Поэтому экспорт нужно сегментировать. Например, отдельно запрашивать /uk/, /en/, /de/, а внутри больших локалей дополнительно разделять блог, категории, товары или шаблоны URL.

Базовый процесс экспорта:

1. сформируйте список языковых сегментов и ресурсов GSC
2. для каждой даты запросите данные с измерениями page, query, country, device
3. используйте фильтр page contains /uk/ или другой паттерн сегмента
4. заберите страницы пакетами через rowLimit и startRow
5. запишите сырой JSON или нормализованные строки в staging-таблицу
6. обработайте дубликаты и загрузите данные в production-таблицу

С параметром dataState есть отдельная тонкость. final дает финализированные данные, но последние дни могут быть еще недоступны. all позволяет получать свежие данные, но они могут измениться после обработки Google. Хорошая практика: ежедневно загружать свежие данные для оперативного дашборда и параллельно перезаписывать данные за предыдущие даты после их финализации.

На практике загрузчик лучше делать небольшим и предсказуемым. Рядом с каждой партией данных сохраняйте параметры запроса: ресурс GSC, языковой сегмент, диапазон дат, измерения, фильтры, rowLimit, startRow, время загрузки и версию правила сегментации. Тогда при изменении отчета команда сможет понять, это реальный сдвиг в выдаче, повторная загрузка, изменение фильтра или ошибка нормализации URL.

Для больших проектов полезно разделять ежедневную и историческую загрузку. Ежедневная задача забирает последние даты с dataState=all и помечает их как предварительные. Отдельная задача раз в несколько дней перезаписывает финализированные даты с dataState=final. Такой подход уменьшает шум в отчетах: SEO-специалист видит свежую динамику, но финальные таблицы не накапливают противоречивые версии одних и тех же строк.

Еще один практический момент - контроль пустых сегментов. Если локаль, каталог или страна внезапно вернули ноль строк, не стоит сразу считать это падением спроса. Лог загрузки должен показать, был ли доступен ресурс GSC, не изменился ли фильтр URL, не исчерпан ли лимит строк и не вернул ли API ошибку. Только после такой проверки данные можно передавать в отчет как бизнес-сигнал.

Как хранить и нормализовать данные в BigQuery

BigQuery лучше использовать не как одну большую таблицу «на все», а как несколько слоев: raw, staging и marts. Слой raw хранит ответ API или максимально близкую к нему структуру. Staging приводит типы, URL и язык к единому формату. Marts содержит готовые таблицы для Looker Studio, BI или внутренних отчетов.

Практическая схема может быть такой:

Для нормализации URL создайте отдельные поля: host, path, language, canonical_group, template_type. Не пытайтесь каждый раз парсить URL в BI-отчете. Это медленно, нестабильно и повышает риск разных правил в разных дашбордах.

Для работы со свежими и финализированными данными используйте MERGE, а не простое добавление строк. Ключом может быть комбинация date, page, query, country, device, search_type. Если строка уже существует, обновите метрики и data_state. Если не существует, вставьте новую. Так история не раздувается дублями после повторных загрузок.

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

Как сравнивать языковые версии и искать каннибализацию

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

Для этого в предложенной модели данных используется внутреннее поле canonical_group: условная группа страниц одного типа. Например, /uk/blog/proxy-guide, /en/blog/proxy-guide, /de/blog/proxy-guide могут относиться к одной группе, если это локализации одного материала. Тогда в отчете видно, какой язык имеет показы, где CTR ниже, где позиция просела после обновления и где нужна работа с title или интентом.

Каннибализацию и связанные проблемы локализации стоит проверять отдельно:

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

Отдельный полезный отчет query_gap показывает пробелы в запросах, где страница имеет много показов, позицию 5-20 и низкий CTR. Именно эти запросы часто стоит добавлять в H2, FAQ или обновления абзацев. Для многоязычного сайта такой отчет нужно строить отдельно по языкам, потому что украинский long-tail не переводится механически на английский.

После этого техническая автоматизация уже работает с приоритетами, а не с разрозненными URL без контекста.

Как автоматизировать проверку hreflang и отчеты

SEO-аналитика многоязычного сайта должна сочетать GSC-данные с технической проверкой hreflang. Search Console покажет клики и показы, но не объяснит все причины, почему пользователи видят неправильную локаль. Для этого нужен отдельный краулер или регулярный аудит по логике API Afina.

Минимальная проверка hreflang должна находить:

• отсутствующие reciprocal ссылки между языковыми версиями
• URL, которые возвращают 3xx, 4xx или canonical на другую страницу
• языковые коды, которых нет в карте локалей
• страницы без self-referencing hreflang
• разные canonical_group для локализаций одного материала

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

Afina может дополнять такую систему во время региональных ручных проверок выдачи, работы с контролируемыми браузерными профилями и автоматизированными QA-сценариями, когда команде нужно проверить SERP в определенной среде. Ядром SEO-аналитики при этом остаются GSC API, BigQuery и четкая модель данных.

Для рабочего процесса достаточно простого расписания: ежедневный экспорт GSC, перезапись финализированных данных с задержкой, еженедельный hreflang-аудит и отчет по запросам с позициями 5-20. Такой подход дает SEO-команде не только дашборд, но и конкретный список задач для оптимизации.

Скачать