How to connect Google Search Console to Claude or ChatGPT

Nikita Delyukin — Wed, 30 Sep 2026 13:19:03 +0000

Search Console holds the only record of what people actually typed before they landed on your site. Reading it through the web interface means picking a date range, picking a dimension, waiting for the table, exporting it, and doing the comparison yourself in a spreadsheet. The Model Context Protocol removes that loop: your AI client talks to the Search Console API directly, and you ask in words.

This guide covers what you can ask, the two ways to connect, how to set one up, and the three things that quietly change the answer once you are connected.

Key takeaways

An MCP server gives Claude, ChatGPT, Cursor and Claude Code direct read access to your Search Console data.
You can run one locally with your own Google Cloud credentials, or connect a hosted one and skip the console work.
The most recent day of Search Console data is incomplete. Comparisons that include it read worse than reality, and nothing in the answer warns you.
A read-only grant (webmasters.readonly) cannot submit sitemaps, request indexing or change a property, whatever the prompt says.

What it looks like when it works

Connected, these are single questions rather than sessions:

"What dropped on askwatch.ai in the last 28 days compared with the 28 before?"
"Which queries rank between 5 and 20 with plenty of impressions but a click-through rate below what is normal at that position?"
"Which of my pages compete for the same search?"
"Is this URL indexed, and which canonical did Google pick?"

The answer comes back as rows the model can reason about, so the follow-up ("why did that page lose clicks and not impressions?") runs against the same data without another export.

A real investigation, in four questions

The value is not one answer, it is that the second question costs nothing. A typical fifteen minutes:

"How did the site do over the last 28 days?" Clicks down 9 percent, impressions flat, average position down half a place. Impressions holding while clicks fall means you are still being shown and less often chosen. That rules out a visibility collapse and points at titles, snippets or something above you in the results.

"What lost the most clicks, by query?" Three queries account for most of it, all of them variations on the same head term, all still ranking in the top five.

"What does the page ranking for those queries look like?" One page, position steady at 3.2, click-through rate down from 6.1 percent to 3.4 percent. The ranking did not move. The share of clicks did.

"Which other queries on this site sit at a similar position with a similar drop?" None. It is one page, one cluster, and the ranking is intact, which narrows it to what the result looks like on the page: a new AI Overview above it, a competitor rewriting their title, or your own title change three weeks ago.

None of those four questions is hard on its own. Doing them in the Search Console interface means four date ranges, four filters and three exports, which is why most people do the first one and guess the rest.

Why shaped tools beat one raw query

A server can expose Search Console two ways. It can pass the API through and let the model write the query, or it can carry a set of tools that each answer a whole question.

The difference shows up on the second run. "What dropped" has a right method: compare two windows of equal length, drop rows with too few impressions to mean anything, sort by absolute loss rather than percentage so a query going from 2 clicks to 1 does not top the list. A model assembling that from raw rows picks a method each time, and the methods differ. Ask on Monday and Thursday and you get two answers that disagree for reasons neither answer mentions.

Shaped tools also fail more usefully. A tool that owns the comparison can say which windows it used and which rows it dropped. A raw query returns rows, and whatever the model then says about them arrives with no working shown.

The raw query is still worth having for the questions nobody anticipated. It should be the fallback, not the interface.

Two ways to connect

Run one yourself. mcp-gsc is open source and runs on your machine. It exposes 20 tools, including writes: submitting and deleting sitemaps, adding and removing properties. Destructive operations are off until you set GSC_ALLOW_DESTRUCTIVE to true.

Setup is the part people underestimate. You create a Google Cloud project, enable the Search Console API in it, choose between OAuth and a service account, download the credentials file, keep it somewhere permanent, install Python 3.11 or newer, and point your client config at both the server and the file. None of it is hard. It is about twenty minutes of console work in an interface built for developers, and it is where most people stop.

Use a hosted one. A hosted server holds the Google grant for you. You sign in with Google once, and the server answers on an address tied to your account. No Cloud project, no credentials file on disk, nothing running locally.

The trade is real and worth stating: a hosted server means somebody else holds a token that reads your Search Console. Ask what scope it requests, how the grant is stored, and how to end it. If the answer is vague, run your own.

AskWatch GSC MCP is the hosted option we build. It is free, it asks for webmasters.readonly, and it exposes 11 read tools.

Setting up the hosted path

Connect your Google account at the tool page. The consent screen asks for read access to Search Console and nothing else.
Copy your personal link.
Paste it into your client.

In Claude and ChatGPT it goes in the connector settings as a custom MCP server. In Claude Code it is one command:

claude mcp add --transport http askwatch-gsc https://mcp.askwatch.ai/gsc/YOUR_KEY

Cursor, VS Code, Codex, Windsurf and Gemini CLI each take the same address in their own config file. The exact shape for each is on the tool page, which is the copy we keep current.

Then ask it something. "List my Search Console properties" is a good first question: it proves the grant works and tells you the exact property strings the other tools expect.

Three things that change the answer

The freshest day is not a day, it is a fragment

Search Console data arrives late and settles over about two days. The API can return finalized rows or everything it has so far, and "everything so far" includes a day that is still filling up.

This is not a rounding problem. We measured it on a live site: including the incomplete day reported clicks down 11.7 percent when the actual fall was 1.1 percent. The trend was real, the number was fiction, and nothing in the answer says which.

It matters more here than in a dashboard, because the reader is a model that will pass the number to you as a fact and then build advice on top of it. Ask your server which it returns. If it returns fresh rows by default, say "use finalized data only" in your question, or expect every comparison that touches today to lean negative.

The window you did not name

"Last month" means the previous calendar month to one person and the last 30 days to another. Models pick one and do not tell you. Name the window, or check which one came back: a good answer states the dates it used and the dates it compared against.

This matters most in the comparison, not the period. Twenty-eight days against the previous twenty-eight is a like-for-like week structure. Thirty days against the previous thirty is not, because one window holds five Mondays and the other four, and a B2B site lives and dies on weekdays.

Property strings are not domains

Search Console has two property types and they are different objects. sc-domain:example.com covers every subdomain and both protocols. https://example.com/ covers exactly that prefix. A site verified both ways will answer twice with different numbers, and neither is wrong. List your properties first and use the string the API gave you.

Agencies hit a version of this with permissions. The grant carries whatever the signed-in Google account can read, so a freelancer added to one property sees one property, and the tool cannot tell the difference between "no data" and "no access". List first, every time you wonder.

Search Console cannot see AI answers It records Google search. It says nothing about what ChatGPT, Perplexity or Gemini tell buyers about you. Check that in a minute, with your domain. Check your brand on AskWatch

What a read-only connection will not do

If the grant asks for webmasters.readonly, the scope itself refuses to submit a sitemap, request indexing, remove a URL or change a property. That is a limit, not a safety feature we added: Google enforces it, so no phrasing of a prompt gets past it.

For most work this is the right shape. Search Console is where you find out what happened; the fixing happens in your CMS. If you want an agent that submits sitemaps, you want the local server with write scopes, and you want to know what it will do before you give it that.

It is also worth knowing what Search Console itself will not tell you. Anonymised queries are left out of the reports, and some views can be truncated, so query-level clicks can be lower than the site total. No MCP server changes that, and an answer that sums queries and calls it traffic is wrong before the model gets involved.

Quota, and what to do about it

The Search Console API has quotas, and URL Inspection has its own, metered far more tightly than the rest. An agent walking a sitemap through URL Inspection will exhaust a day of it quickly.

Two habits help. Ask for a list before you ask for detail: find the twelve pages worth inspecting, then inspect those twelve. And prefer tools that cache: the same question asked twice in an afternoon should cost one call to Google, not two.

A hosted server can cache for you, which is one thing it can do that a local one usually does not. Ask how long: a day of search data that Google has finalized will not change again, and a server re-fetching it every time is spending your quota on a number it already has.

FAQ

Do I need a Google Cloud project to use Search Console with Claude?

Only if you run the server yourself. A local MCP server authenticates as you, which means your own Cloud project, your own OAuth client and a credentials file on disk. A hosted server holds the grant, so signing in with Google is the whole setup.

Does this work with ChatGPT, or only Claude?

Both, plus Cursor, VS Code, Claude Code, Codex, Windsurf and Gemini CLI. They differ in which config file the address goes in and what the field is called, not in what the server does.

Can an AI client change something in Search Console by mistake?

Not through a read-only grant. webmasters.readonly cannot submit a sitemap, request indexing or remove a URL, and the refusal comes from Google rather than from the server's own rules. A server with write scopes can, which is a reason to know which one you connected.

Is the data the same as the Search Console interface?

It is the same API the interface reads, so the numbers match when the date range and the property match. Two things commonly make them look different: the freshest day being incomplete, and query-level rows leaving out anonymised queries that the site total includes.

How many properties can I query?

As many as the signed-in Google account can read. Each question names one property, so start by listing them and use the exact strings the API returns.

Where to start

If you are checking whether this is useful at all, use a hosted server, ask it the four questions at the top of this page, and see whether the answers change what you do next. If they do and you want writes, or you would rather hold your own credentials, run the open source server. Both read the same API. The difference is who holds the token and how much of a Tuesday you spend in the Google Cloud console.

And once you can ask Google what it did, the obvious next question is what the answer engines are doing, which Search Console does not record at all. That is a different measurement, and it starts with who gets cited.

DEV Community: Nikita Delyukin