Перейти к содержимому

Google Search Console MCP: как я подключил GSC к Claude

В сентябре 2026 года я подключил Google Search Console своего сайта к Claude через MCP-сервер. Повод был приземлённый: в индексе висели мусорные адреса, и выяснять их происхождение вручную не хотелось. Ниже весь путь — от выбора способа авторизации до двух багов, которые пришлось чинить по дороге, и того, что нашлось на живом сайте.

Это не подборка «лучших MCP-серверов». Один сервер, одна рабочая машина на Windows, сайт на четырёх языках — и честные впечатления после первых дней работы.


Search Console, MCP-сервер и ИИ-ассистент, соединённые в цепочку на экране рабочего компьютера

MCP-сервер простыми словами

MCP (Model Context Protocol) — открытый протокол, через который ИИ-ассистент вызывает внешние инструменты. MCP-сервер — программа-посредник: с одной стороны она говорит на языке ассистента, с другой — ходит в API нужного сервиса. В случае Search Console это значит, что Claude сам запрашивает отчёт по запросам, проверяет URL или сравнивает периоды, а не просит меня выгрузить CSV и вставить его в чат.

Сервер запускается локально, на том же компьютере, где работает Claude Desktop или Claude Code, и общается с ассистентом через стандартный ввод-вывод. Отдельный хостинг для этого не нужен.

Какой сервер я выбрал и что проверил до установки

Я взял Google Search Console MCP — Python-пакет gsc-mcp-tools. Решили три вещи:

  • Охват. 61 инструмент: отчёты Search Analytics, проверка URL, карты сайта, Indexing API, а сверху — GA4, данные CrUX, PageSpeed и аудиты разметки, hreflang, заголовков и внутренних ссылок.
  • Сервисный аккаунт. Можно обойтись без входа через браузер — для локального сервера, который работает неделями, это удобнее.
  • Консольный клиент в комплекте. Каждый инструмент доступен ещё и как команда gsc-cli. Это пригодилось, когда Claude ещё не видел новый сервер.

Перед установкой я прошёлся по тому, что проверяю у любого MCP-сервера: открыт ли код, какая лицензия, какие зависимости и куда программа ходит в сеть. Лицензия MIT, запросы уходят только в API Google, в IndexNow и на страницы проверяемого сайта, токены хранятся в локальных файлах. Почему к такой проверке стоит относиться серьёзно, я разбирал в статье о безопасности ИИ-инструментов.

Шаг 1. Авторизация: сервисный аккаунт вместо OAuth

У пакета два режима. OAuth — классический вход через браузер под своим аккаунтом Google. Сервисный аккаунт — технический пользователь проекта Google Cloud с JSON-ключом: входить никуда не нужно, и сервер не зависит от срока жизни OAuth-токенов. Для локального сервера я выбрал второе.

  1. В проекте Google Cloud включить Google Search Console API. Для отправки URL и данных GA4 — ещё Web Search Indexing API и Google Analytics Data API.
  2. Создать сервисный аккаунт и скачать JSON-ключ.
  3. Выдать доступ в самой Search Console: Настройки → Пользователи и разрешения → Добавить пользователя, указать адрес сервисного аккаунта.

Главная неочевидность — третий пункт. Роли в Google Cloud на Search Console не влияют: пока адрес не добавлен в пользователи ресурса, любой вызов возвращает 403 при идеально правильном ключе. API для этого шага нет — только форма в интерфейсе, руками владельца сайта.

Уровень доступа я дал «Полный»: его хватает на чтение отчётов и проверку URL. «Владелец» нужен только для Indexing API, и выдавать его без необходимости не стоит.

Сэкономило время то, что сервисный аккаунт у меня уже был — создавал его раньше для Google Analytics. Один аккаунт можно использовать в нескольких продуктах Google, доступ в каждом выдаётся отдельно. Ключ я держу вне синхронизируемых облачных папок: по сути это пароль к данным.

Шаг 2. Установка — и первая яма: закончилось место

Ставлю через pipx, чтобы пакет жил в изолированном окружении:

python -m pipx install gsc-mcp-tools

Установка упала с No space left on device. Системный диск C: оказался забит почти полностью — свободно около 200 МБ, а pipx по умолчанию создаёт окружение именно там. Лечится переносом каталогов pipx на другой диск перед установкой:

$env:PIPX_HOME = "D:\pipx"
$env:PIPX_BIN_DIR = "D:\pipx\bin"
python -m pipx install gsc-mcp-tools

Окружение заняло около 270 МБ. В каталоге bin появились три программы: gsc-mcp — сам сервер, gsc-mcp-tools — он же под именем пакета и gsc-cli — консольный клиент.

Шаг 3. Регистрация в Claude Code

Ключ передаётся через переменные окружения. В PowerShell:

$k = "C:\keys\gsc.json"
claude mcp add gsc -s user `
  -e GSC_SKIP_OAUTH=true `
  -e "GSC_SERVICE_ACCOUNT_PATH=$k" `
  -- D:\pipx\bin\gsc-mcp.exe

Флаг -s user кладёт запись в пользовательский конфиг, а не в файл проекта. Для меня это важно: папка проекта синхронизируется с облаком, и путь к ключу там светить незачем. Для инструментов GA4 в тот же ряд добавляется -e GA4_PROPERTY_ID=….

claude mcp list

Напротив gsc появилось «Connected». И вторая неочевидность: в уже открытой сессии новых инструментов нет. Список подхватывается при запуске сессии, поэтому после добавления сервера её нужно открыть заново. К тому же «Connected» означает лишь, что процесс стартует и отвечает на рукопожатие, — а не то, что права в Search Console выданы.

Шаг 4. Проверка без Claude — и баг в клиенте

Чтобы не ждать новой сессии, я решил проверить доступ консольным клиентом из того же пакета:

gsc-cli list

Он упал ещё до обращения к Google: ValueError: badly formed help string. Трассировка показала, что клиент берёт первую строку описания каждого инструмента и передаёт её в argparse как текст справки. В одном из описаний есть знак %, а свежий argparse (у меня Python 3.14) проверяет такие строки сразу при создании команд и принимает процент за начало шаблона форматирования.

Помогла одна правка в gsc_mcp/cli.py — экранировать процент перед передачей:

help=help_text.replace("%", "%%")

На сам MCP-сервер это не влияет, ломался только клиент. Но правка живёт в установленном пакете и пропадёт при обновлении — такое лучше отправлять автору.

Ещё деталь: параметры-списки передаются повтором флага, а не через запятую. Строка через запятую ошибку не вызывает — она молча превращается в один «адрес»:

gsc-cli batch-url-inspection `
  --site https://example.com/ `
  --urls https://example.com/a `
  --urls https://example.com/b

После правки команда gsc-cli list-properties вернула мой сайт с уровнем siteFullUser — доступ работает.

Что нашлось на живом сайте

Мусорные адреса. Google всё ещё держал восемь лишних URL: /ru?Itemid=232 и соседние — хвосты давно удалённых пунктов меню, и два легаси-адреса вида /ru/component/content/article/2-…?catid=14 у двух давно снятых с публикации статей 2019 и 2021 годов. Все восемь теперь отдают 410 Gone.

С легаси-адресами вышла поучительная история. Правило редиректа на исходный адрес не срабатывало вообще. Оказалось, Joomla сама перехватывает старый формат /component/content/article/… и отдаёт 301 на промежуточный ?view=article&id=… — и только этот второй адрес по-настоящему отвечает 404. Правило пришлось вешать на него. Заодно нашёлся баг в MCP-коннекторе для Joomla: инструмент создания редиректов записывал код ответа не в то поле.

Проверка URL. Для таких параметризованных адресов инструмент проверки вернул NEUTRAL и пустые поля. Это не ошибка вызова: у Google просто нет отдельных данных проверки по этим URL. Пакет же ставит им категорию fetch_error — ярлык вводит в заблуждение, смотреть стоит на сами поля. Для обычной страницы тот же инструмент отдал «PASS», дату последнего обхода и канонический адрес.

Быстрые победы. Инструмент quick_wins показал, что главная страница в среднем на 8-й позиции, но за четыре недели при 295 показах получила один клик. Ожидаемая кликабельность для такой позиции — около 3 %, фактическая — 0,3 %. Ближайшая задача очевидна: заголовок и описание в выдаче.

Что оказалось полезным, а что нет

  • Работает сразу: сравнение периодов, поиск просевших запросов, «быстрые победы», пакетная проверка URL, аудит карты сайта, технический аудит страницы. Ответ приходит за секунды, и Claude сам выбирает, какой инструмент вызвать под вопрос.
  • Требует подготовки: инструментам GA4 нужен доступ сервисного аккаунта в Google Analytics, данным CrUX — отдельный API-ключ и достаточный трафик.
  • С оговорками: Indexing API официально предназначен только для страниц с вакансиями и трансляциями, а квота — 200 запросов в сутки. Для обычных страниц рассчитывать на него не стоит.
  • Помнить всегда: данные Search Console отстают на 2–3 дня, а у небольшого сайта их просто мало.

Короткий чек-лист

  1. Включить Google Search Console API в проекте Google Cloud.
  2. Создать сервисный аккаунт, скачать JSON-ключ и хранить его вне облачных папок.
  3. Добавить адрес аккаунта в Search Console с уровнем «Полный».
  4. Поставить gsc-mcp-tools через pipx; при нехватке места перенести PIPX_HOME.
  5. Зарегистрировать сервер через claude mcp add в пользовательской области.
  6. Проверить доступ командой gsc-cli list-properties и открыть новую сессию Claude.

Если проходить этот путь самому не хочется, мы можем подключить Google Search Console к ИИ-ассистенту за вас — на вашем компьютере или в вашем облаке.

Виктор Пархимчик, основатель веб-студии IT Deweloper