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

Поэтому следующим этапом я подключила к SEO-помощнику Google Search Console.

При этом я сознательно не стала включать Google Analytics, Google Tag Manager, рекламные теги и другие сервисы только потому, что они доступны в Google Site Kit. Причина была не только технической, но и правовой.

Какие данные мне были нужны от Google

Задача была конкретной: SEO Автор должен видеть фактическую органическую видимость сайта в Google.

Мне нужны были:

• поисковые запросы;
• страницы;
• клики;
• показы;
• CTR;
• средняя позиция.

В результате источники в SEO Авторе разделяются так:

Wordstat
→ поисковый спрос в Яндексе
Яндекс Вебмастер
→ видимость сайта в Яндексе
Google Search Console
→ видимость сайта в Google
Яндекс Метрика
→ визиты и поведение пользователей
Яндекс Директ
→ рекламные данные

Это важное разделение.

Например, показы в Search Console нельзя считать частотностью запроса. GSC показывает, сколько раз конкретный сайт появился в результатах Google за выбранный период.

Так же и TOTAL_SHOWS в Яндекс Вебмастере — это не частотность Wordstat.

Почему я не стала делать отдельную авторизацию Google Cloud

Один из вариантов — создать собственный проект Google Cloud, настроить OAuth, Client ID, Client Secret и обращаться к Search Console API напрямую.

Но для моей задачи это добавляло лишний уровень настройки.

На сайтах WordPress уже можно использовать официальный Site Kit by Google, через который подключается Search Console.

Поэтому схема получилась такой:

Google Search Console
        ↓
Google Site Kit
        ↓
Victoria GSC Bridge
        ↓
SEO API Gateway
        ↓
SEO Автор — Victoria

Google OAuth остаётся внутри Site Kit.

SEO Автору не нужно хранить Google Client ID, Client Secret или OAuth-токен пользователя.

Для программного доступа к WordPress я создала отдельный Application Password.

Первый тест: свойство Search Console видно, а данные не возвращаются

На первом этапе шлюз успешно определял подключение:

connected: true
property: sc-domain:victoria-seo.ru

Но при запросе реальной статистики Search Console я получила:

403
missing_required_scopes

При этом в самой административной панели WordPress Search Console отображалась как подключённая.

То есть сам факт подключения свойства был подтверждён, а проблема проявлялась именно при программном REST-запросе.

Здесь важно не делать более сильный вывод, чем позволяют результаты теста.

В моей интеграции ошибка проявлялась при REST-запросе с Application Password. После того как Bridge стал выполнять обращение к Site Kit в контексте нужного WordPress-пользователя, запросы Search Console начали возвращать данные.

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

Зачем понадобился собственный GSC Bridge

Чтобы не передавать Google-токен наружу и не вмешиваться в OAuth Site Kit, я сделала небольшой WordPress-плагин Victoria SEO — GSC Bridge.

Схема стала такой:

SEO API Gateway
        ↓
Application Password WordPress
        ↓
авторизованный WordPress-пользователь
        ↓
GSC Bridge
        ↓
Site Kit
        ↓
Google Search Console

После доработки проверка уже показывала:

owner_id: 1
request_user_id: 1

А следующий запрос вернул реальные строки Search Console.

Таким образом, Bridge нужен не для обхода Google API, а для корректной работы моего внешнего шлюза с уже существующим подключением Site Kit.

Затем я подключила второй сайт

После того как схема заработала на victoria-seo.ru, создавать отдельный SEO-помощник для каждого проекта не имело смысла.

Поэтому общий API Gateway я расширила до работы с несколькими сайтами.

Сейчас используются два источника:

site=victoria
→ sc-domain:victoria-seo.ru

и:

site=electric24
→ sc-domain:electric-24.ru

На каждом сайте установлен свой Site Kit и GSC Bridge, а для доступа используется отдельный Application Password.

При этом сам SEO Автор — Victoria остаётся один.

Что вернул Google Search Console для electric-24.ru

Для теста я запросила данные за период:

27 августа — 24 сентября 2026 года.

В качестве измерения использовался поисковый запрос.

Search Console вернул, в частности:

Это уже позволяет искать конкретные точки роста.

Например, по запросу «вызвать электрика» средняя позиция за этот период была около 15.

Это означает, что Google уже показывал сайт по запросу, а средняя позиция за выбранный период составляла около 15.

Вместо автоматического решения «создать новую страницу» сначала имеет смысл проверить:

какой URL ранжируется
→ соответствует ли он интенту
→ какие у него Title и Description
→ достаточно ли раскрыта услуга
→ есть ли внутренняя перелинковка
→ не конкурирует ли с ним другая страница

Так данные GSC становятся основой для on-page SEO, а не просто ещё одним отчётом.

Почему я не стала подключать Google Analytics

Технически Google Analytics подключить можно.

Но для моей задачи он не требовался.

Search Console нужен для анализа органической видимости Google. Для его использования в моей схеме не понадобилось устанавливать дополнительный аналитический счётчик на страницы сайта.

С Google Analytics ситуация другая: при установке аналитического тега появляется новый клиентский сбор данных о посетителях.

Схема уже выглядит так:

посетитель
→ браузер
→ Google Analytics / Google tag
→ внешний сервис

И здесь возникает отдельный вопрос обработки персональных данных.

Почему это важно для российского сайта

С 1 июля 2025 года часть 5 статьи 18 Федерального закона № 152-ФЗ устанавливает требования к использованию баз данных при сборе через интернет персональных данных граждан РФ.

Кроме того, в письме Минцифры России от 12 мая 2025 года № П25-44929 отдельно рассматривалось использование метрических программ, в том числе Google Analytics.

Ведомство указало, что если функциональность такой системы предполагает обработку персональных данных, использование Google Analytics может рассматриваться как трансграничная передача персональных данных, регулируемая статьёй 12 Федерального закона № 152-ФЗ.

При этом само письмо носит разъяснительный характер и не является самостоятельным нормативным запретом на использование Google Analytics.

Поэтому корректный вывод не такой:

«Google Analytics в России запрещён».

А такой:

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

Почему одного cookie-баннера недостаточно

Наличие кнопки «Согласен» само по себе не решает все вопросы обработки данных.

Если новый сервис предполагает обработку персональных данных, необходимо отдельно проверить:

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

Требования о локализации и трансграничной передаче не исчезают только потому, что пользователь нажал кнопку в cookie-баннере.

На сайте уже была своя логика согласия

У меня Яндекс Метрика уже запускалась только после согласия пользователя.

Если бы я добавила Google Analytics, пришлось бы заново проверить всю цепочку:

баннер
→ согласие
→ Яндекс Метрика
→ Google Analytics
→ отказ
→ отзыв согласия
→ повторный визит

Особенно важно исключить ситуацию, когда один аналитический сервис ждёт согласия, а другой начинает работать раньше.

Поэтому подключать GA «заодно» только потому, что он предлагается в Site Kit, я не стала.

Почему я не подключила Google Tag Manager

Google Tag Manager сам по себе решает другую задачу — управляет тегами.

Через него можно запускать:

• Analytics;
• рекламные пиксели;
• ремаркетинг;
• стороннюю аналитику;
• другие маркетинговые скрипты.

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

Для получения данных Search Console GTM не нужен.

Добавлять ещё один слой:

сайт
→ GTM
→ сторонние теги
→ разные получатели данных

без конкретной задачи не имело смысла.

Почему не подключила Google Ads и рекламные теги

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

• измерения конверсий;
• создания рекламных аудиторий;
• ремаркетинга;
• рекламной персонализации.

Это уже не та же самая задача, что анализ органического поиска.

Для моего SEO-помощника требовалось понять:

по каким запросам сайт показывается в Google и где есть точки роста.

Search Console это решает.

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

А PageSpeed Insights почему остался

PageSpeed Insights относится к другому типу инструментов.

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

Поэтому наличие PageSpeed Insights в Site Kit не означало необходимость автоматически включать Analytics, Tag Manager или рекламные сервисы.

В дальнейшем данные PageSpeed тоже можно подключить к SEO Автору — например, чтобы сопоставлять видимость страниц с техническими проблемами.

Но на этом этапе такой задачи не было.

Почему я выбрала минимальный набор интеграций

Я не стала строить систему по принципу:

есть API
→ подключаем

Для меня правильнее другая последовательность:

есть SEO-задача
        ↓
определяем, каких данных не хватает
        ↓
выбираем источник
        ↓
подключаем только необходимое

В данном случае не хватало данных об органической видимости сайта в Google.

Поэтому нужен был Google Search Console.

Google Analytics, Tag Manager, Ads и другие дополнительные теги эту задачу не решали.

Зато могли бы добавить:

• новый сбор данных посетителей;
• дополнительные внешние запросы;
• новые цели обработки;
• дополнительные требования к consent-логике;
• вопросы локализации и трансграничной передачи.

Для SEO-помощника это было избыточно.

Что теперь умеет SEO Автор

После подключения GSC можно дать ему, например, такую задачу:

Проанализируй electric-24.ru по Google Search Console за последние 90 дней. Найди запросы с позициями от 5 до 30, по которым есть показы, но мало кликов. Для существующих страниц предложи изменения Title, Description, структуры, текста и FAQ.

Или:

Сопоставь Wordstat, Яндекс Вебмастер и Google Search Console. Найди темы, где есть поисковый спрос, но сайт пока имеет слабую видимость.

Здесь используются принципиально разные данные:

Wordstat
→ что ищут пользователи
Яндекс Вебмастер
→ как сайт представлен в Яндексе
Google Search Console
→ как сайт представлен в Google
Метрика
→ что происходит после перехода на сайт

Именно это разделение делает анализ полезным.

Итог

Целью этого этапа было не просто «подключить ещё один API».

Мне нужно было дать SEO-помощнику реальные данные Google и при этом не устанавливать на сайт лишние tracking-технологии без конкретной необходимости.

В итоге я:

• подключила Search Console через Site Kit;
• создала собственный GSC Bridge;
• сохранила Google OAuth внутри Site Kit;
• настроила доступ через отдельные Application Passwords;
• добавила поддержку сразу двух сайтов;
• передала данные GSC в единый SEO API Gateway;
• научила SEO Автор различать Google и Яндекс.

А Google Analytics, Tag Manager и рекламные сервисы оставила неподключёнными.

Не потому, что их невозможно использовать.

А потому, что для их подключения появилась бы отдельная задача по правовой и технической настройке обработки данных, тогда как для SEO мне требовалась только Search Console.

В данном случае минимальная архитектура оказалась и проще, и понятнее:

Google Search Console
        ↓
Site Kit
        ↓
GSC Bridge
        ↓
SEO Gateway
        ↓
SEO Автор

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