Тендеры и лиды
Информация
Как я автоматизировала поиск SEO-точек роста: связала Google Search Console с ИИ-помощником
Этот материал будет полезен SEO-специалистам, небольшим агентствам и владельцам нескольких сайтов, которым приходится регулярно искать запросы и страницы с потенциалом роста.
Раньше для такого анализа я вручную открывала Google Search Console, задавала период, переключалась между запросами и страницами, сортировала данные, сопоставляла позиции с показами и CTR. Затем повторяла то же самое для другого сайта.
Данные были доступны, но путь от цифр до списка задач занимал слишком много действий.
Я решила автоматизировать не само принятие решений, а подготовительную часть: получение данных, первичную сегментацию и формирование гипотез. В результате мой ИИ-помощник научился запрашивать сведения из Google Search Console и превращать их в понятный список SEO-точек роста.
Ниже — схема решения, ошибка, которая появилась при подключении, и алгоритм, который можно повторить в другом проекте.
Для меня точка роста — не любой запрос с показами и не страница с низким CTR. Это ситуация, в которой уже есть поисковый сигнал, а небольшая и проверяемая доработка потенциально может улучшить результат.
Например:
страница показывается на позициях 5–10, но получает мало кликов относительно числа показов;
запрос находится на позициях 11–30, а посадочная страница соответствует его интенту и может быть усилена;
по одному запросу Google показывает не ту страницу, которую я считаю целевой;
тема имеет спрос, но сайт почти не виден по ней;
страница получает переходы из поиска, но поведение пользователей требует отдельной проверки.
Ключевое слово здесь — «потенциально». Ни одна строка отчёта не доказывает, что достаточно переписать Title или добавить абзац.
Автоматизация должна находить кандидатов для анализа, а не выдавать предположения за готовую стратегию.
До подключения Google Search Console мой помощник уже работал с Яндекс Wordstat, Яндекс Вебмастером и Метрикой.
Добавить ещё один источник было несложно технически. Гораздо важнее было не смешать смысл метрик.
Каждый источник отвечает на свой вопрос:
Яндекс Wordstat показывает, что и как часто ищут пользователи в Яндексе.
Яндекс Вебмастер показывает, по каким запросам конкретный сайт получает показы и клики в Яндексе.
Google Search Console помогает понять, по каким запросам и страницам конкретный сайт виден в Google.
Яндекс Метрика показывает, что пользователи делают после перехода на сайт.
Показы в Google Search Console — не частотность запроса. Они говорят только о том, сколько раз страницы конкретного сайта появились в результатах поиска в рамках выбранных условий.
Частотность из Wordstat и показы сайта нельзя складывать, сравнивать как одинаковые величины или подменять одной метрикой другую.
Именно разделение источников стало первым правилом системы. Сначала помощник определяет, какой вопрос я задаю, и только затем обращается к нужным данным.
Мне был нужен минимальный набор показателей:
поисковый запрос;
страница;
клики;
показы;
CTR;
средняя позиция;
анализируемый период;
сайт, к которому относится выгрузка.
Google возвращает эти показатели через Search Analytics API. Запрос можно группировать по поисковой фразе, странице, стране, устройству и другим параметрам.
При этом API не гарантирует выдачу абсолютно всех строк и в некоторых случаях возвращает верхнюю часть данных. Поэтому результат нельзя воспринимать как полный список поисковых фраз сайта.
Это ограничение указано в официальной документации Google Search Console API.
Оба моих сайта работают на WordPress, и на каждом уже был настроен официальный плагин Site Kit by Google. Он подключает Search Console и показывает её данные в панели WordPress.
Поэтому я решила не создавать ещё один OAuth-контур, а использовать существующее подключение.
Получилась такая цепочка:
Google Search Console
↓
Google Site Kit
↓
небольшой мост внутри WordPress
↓
SEO API Gateway
↓
ИИ-помощник
Мост получает запрос от шлюза, обращается к Site Kit в контексте авторизованного пользователя WordPress и возвращает только нужные показатели.
OAuth-токены Google остаются внутри Site Kit. ИИ-помощник не хранит Google Client ID, Client Secret и пользовательские OAuth-токены.
Для внешнего обращения к REST API WordPress я создала отдельный Application Password. WordPress поддерживает такие пароли для REST-запросов по HTTPS — это описано в официальном руководстве WordPress.
Сам пароль, разумеется, в команды помощника и публичные материалы не попадает.
На первом тесте система сообщила, что соединение установлено и свойство sc-domain:victoria-seo.ru найдено.
Однако реальный запрос к аналитике вернул ошибку:
403 missing_required_scopes
Это был полезный сбой. Он показал, что проверка статуса подключения ещё не доказывает возможность читать нужные данные.
Можно успешно подтвердить наличие плагина и свойства, но получить отказ на этапе запроса к Search Analytics.
Проблема возникала, когда REST-запрос выполнялся с Application Password, а Site Kit не видел ожидаемый контекст WordPress-пользователя для обращения к Google.
Я изменила работу моста: теперь он выполняет вызов Site Kit в корректном пользовательском контексте. После этого запросы, страницы, клики, показы, CTR и средняя позиция начали возвращаться.
Задачей моста было не обойти авторизацию Google, а связать внешний шлюз с уже настроенным и разрешённым подключением Site Kit.
Сам Site Kit действительно предназначен для подключения Search Console и вывода её данных в WordPress, что подтверждает документация плагина.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13752 тендера
проведено за восемь лет работы нашего сайта.
После теста на victoria-seo.ru я добавила второй проект — electric-24.ru.
Один помощник должен был работать с обоими сайтами, но не смешивать их доступы и данные.
В шлюзе появился параметр site:
site=victoria направляет запрос к свойству sc-domain:victoria-seo.ru;
site=electric24 направляет запрос к свойству sc-domain:electric-24.ru.
На каждом сайте остались собственные Site Kit, мост и Application Password. Общим стал только интерфейс помощника.
Такое разделение снижает риск случайно запросить не тот проект и упрощает отключение одного сайта без вмешательства в другой.
Для проверки я запросила данные electric-24.ru за период с 27 августа по 24 сентября 2026 года с группировкой по поисковым запросам.
В ответе, среди прочего, были такие строки:
«розетки не работают а свет есть» — 1 клик, 5 показов, CTR 20%, средняя позиция 5,6;
«свет работает а розетки нет» — 1 клик, 3 показа, CTR 33,3%, средняя позиция 2,3;
«верхний свет работает а розетки нет» — 0 кликов, 1 показ, CTR 0%, средняя позиция 3;
«выбивает автомат» — 0 кликов, 1 показ, CTR 0%, средняя позиция 10;
«вызвать электрика» — 0 кликов, 4 показа, CTR 0%, средняя позиция 15;
«вызвать электрика на дом» — 0 кликов, 2 показа, CTR 0%, средняя позиция 18,5.
Выборка небольшая, поэтому делать выводы о спросе или срочно переписывать страницы по этим числам нельзя. Но она хорошо показывает логику дальнейшего анализа.
Например, средняя позиция около 15 по запросу «вызвать электрика» означает, что Google уже показывал сайт по этой формулировке.
Это ещё не команда создавать новую страницу. Сначала нужно выяснить:
какой URL получал показы;
соответствует ли страница намерению пользователя;
нет ли другой страницы, которая должна ранжироваться вместо неё;
как оформлены Title и Description;
достаточно ли заметна услуга в структуре сайта;
есть ли у страницы внутренние ссылки;
что предлагают конкуренты в выдаче.
Так одна строка из API превращается не в автоматическую правку, а в проверяемую гипотезу.
Это кандидаты на проверку сниппета и соответствия интенту.
Я смотрю не только на Title и Description, но и на тип страницы, конкурентов, особенности выдачи и брендовый характер запроса.
Низкий CTR не всегда означает плохой сниппет: часть кликов могут забирать карты, расширенные ответы или известные бренды.
Здесь я ищу страницы, которые уже понятны поисковой системе, но пока не попали в верхнюю часть выдачи.
Возможные действия:
дополнить ответ на интент;
улучшить структуру страницы;
усилить внутренние ссылки;
убрать пересечение с другой страницей;
проверить полноту коммерческой информации.
Конкретное решение зависит от запроса, страницы и состава выдачи.
Если информационный материал показывается по коммерческому запросу или две страницы сменяют друг друга, помощник отмечает возможное несоответствие интенту или каннибализацию.
После этого я вручную проверяю выдачу и содержание обеих страниц.
Здесь я сопоставляю Wordstat с Вебмастером и Google Search Console.
Если спрос есть, а показов сайта почти нет, это сигнал изучить структуру и покрытие темы.
Но отсутствие строки в GSC ещё не является доказательством отсутствия показов: нужно учитывать ограничения API, выбранный период и объём данных.
Это уже вопрос не к Search Console, а к Метрике.
Помощник переключает источник и проверяет поведение пользователей после перехода. Так я не пытаюсь объяснить всё одной таблицей.
Вместо ручной сортировки я могу сформулировать задачу так:
Проанализируй данные Google Search Console для electric-24.ru за последние 90 дней. Найди запросы с показами на средних позициях от 5 до 30 и небольшим числом кликов. Для каждого запроса укажи посадочную страницу, возможную причину слабого результата, что нужно проверить и какое действие можно рассмотреть. Не предлагай новую страницу, пока не проверишь текущий URL и интент.
Важна последняя фраза. Без ограничений языковая модель легко превращает каждый запрос в предложение написать новую статью.
В SEO это приводит к дублированию, каннибализации и росту числа слабых страниц.
Поэтому ответ строится в формате карточек:
факт из данных;
связанный URL;
гипотеза;
способ проверки;
возможное действие;
приоритет;
уровень уверенности.
Факт и гипотеза всегда разделены.
«Средняя позиция 15» — факт из выгрузки. «Странице не хватает внутреннего веса» — гипотеза, которую ещё нужно подтвердить.
Помощник не меняет страницы и не публикует тексты.
Он не переписывает метатеги без просмотра выдачи, не создаёт новые URL по каждой фразе и не объединяет показатели разных систем в одну искусственную метрику.
Я также не подключала Google Analytics, Tag Manager и Google Ads только потому, что такая возможность существует. Они не были нужны для исходной задачи — анализа органической видимости в Google.
Чем точнее сформулирован вопрос, тем меньше лишних интеграций приходится поддерживать.
Полезное правило для любого подобного проекта:
Сформулируйте конкретный SEO-вопрос.
Определите, в каком источнике есть данные для ответа.
Подключите минимально необходимый набор показателей.
Не смешивайте частотность, видимость и поведение пользователей.
Отделяйте факты из выгрузки от гипотез модели.
Не создавайте новую страницу до проверки существующих URL.
Оставляйте специалисту решения с высоким риском.
Тестируйте сценарий на небольшом периоде и одном сайте.
Проверяйте, что помощник обращается именно к выбранному проекту.
Только после проверки масштабируйте решение на остальные сайты.
Теперь я могу из одного диалога выбрать сайт и период, получить данные по запросам или страницам и быстро сформировать список кандидатов для анализа.
Самое ценное здесь не генерация текста и не красивый отчёт. Помощник снимает повторяющуюся работу между выгрузкой и первым профессиональным выводом.
При этом автоматизация не заменила SEO-анализ. Она сделала его последовательнее:
данные → сегментация → гипотеза → ручная проверка → задача → оценка результата.
Если убрать этап ручной проверки, система начнёт масштабировать не решения, а ошибки.
Подробную техническую версию со схемой подключения и тестами я сохранила в разборе на сайте Victoria SEO.
Повторять именно мою архитектуру необязательно. Главный принцип переносится на любой стек: автоматизировать стоит не «SEO целиком», а конкретный повторяющийся участок, для которого есть понятный источник данных и критерии проверки.
Автор: Виктория, SEO-специалист Victoria SEO.
