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-команді не лише дашборд, а й конкретний список завдань для оптимізації.

Скачати