Connect Search Console to Your AI Assistant: 4 Ways

Google Search Console is the only record of how Google actually treats your site, and for most people it is a tab they never open. Getting it into Claude, Cursor, or ChatGPT is a solved problem - there are four ways to do it, and they differ in setup cost, not in the data they reach.

What you get, and how the four routes differ

Which route you want depends on how often you plan to ask. If you want an answer rather than a project, take the managed MCP server. If you want raw rows inside a script, take the API. If you have exactly one question and never want to configure anything, export a CSV - and accept that it is the only one of the four you cannot repeat without doing the whole thing again by hand.

Search Console is Google's own record of your site in search: which queries showed your pages, how often people clicked, and roughly where you ranked. That data is the half your assistant cannot get by crawling you from the outside: a crawl tells you whether Google can read your site, Search Console tells you what Google actually did with it.

What changes when the data is in the chat is the follow-up. A dashboard can tell you a page was shown 400 times and clicked 3 times, and then it stops. An assistant that can also see your repository can be asked rewrite the title and description for that page in the next message. The tools side of that is covered in running SEO checks in Claude and Cursor.

What “the one query you are closest to winning” cashes out to in practice is the whole subject of how game-scout got its first clicks from Google: one specific, thin-competition query beat every broad term it tried, and the same read is sitting in your own Search Console data right now - an assistant connected to it can just tell you.

The four routes, side by side

Each route below carries the same three facts: who it suits, what it costs to set up, and whether you can repeat it without touching Search Console again. That last one usually decides it.

• Managed MCP server - suits someone who wants an answer, not a setup. Setup cost: a free account, no Google Cloud project. Repeatable from the assistant: yes.
• Open-source MCP server - suits someone comfortable in a terminal. Setup cost: a local install and your own OAuth credentials. Repeatable from the assistant: yes.
• Search Console API - suits scripts and scheduled jobs. Setup cost: a Google Cloud project and a JSON key. Repeatable without a human present: yes.
• CSV export - suits one question, right now. Setup cost: none. Repeatable: no, you redo the export by hand every time.

The two MCP routes and the API all end up calling the same Search Console API with the same read-only scope. What you are really choosing is who runs the OAuth flow and where the credentials live: on someone else's server, on your laptop, or in your own deployment environment.

Route 1: the managed MCP server

This is the route with no Google Cloud project in it. You add one URL - https://traffictriage.com/mcp - to Claude, Cursor, ChatGPT, or any other client that accepts a remote MCP server, create a free TrafficTriage account when it asks you to sign in, and then approve read-only Search Console access once from your dashboard. The scope requested is webmasters.readonly, and you can revoke it from your Google account's security settings whenever you like.

The per-client steps differ more than you would expect. Claude wants a name and a URL. ChatGPT wants Developer mode switched on first, in a settings section most people never open, and it is the only client of the three that fails outright if your server does not advertise the openid scope. The ChatGPT setup, step by step walks that one through, including the scope failure and how to check for it.

The thing that trips people up is that signing in with Google is not the same as granting Search Console access. They are two separate consent screens. If you created your account with Google but never saw a read-only Search Console prompt, the connection is not made yet.

Once it is connected, run_gsc_report runs 6 checks over 90 days of your data and ends in one verdict rather than handing you a table to interpret, and query_search_analytics is there for when you want to ask something the 6 checks do not cover. Reports created over the server are private to your account. The step-by-step, including what each of the 6 checks answers, is in connecting Search Console to Claude with the MCP server, and the full tool list is on the MCP server page.

The trade-off is honest: you are trusting a third party with a read-only grant, and the free account is metered - a monthly allowance on each tool, with the Search Console tools not counted against any of them. If you would rather no one else hold the grant, take route 2 or 3.

Route 2: the open-source GSC MCP server

If you want an MCP server but want to hold your own credentials, AminForou/mcp-gsc is the open-source option. It is MIT-licensed and you run it yourself, and its README documents two ways to authenticate: OAuth using your own Google account, or a service account for automation and team use. It lists Claude Desktop, Cursor, Codex CLI, Gemini CLI, Antigravity, and any other MCP-compatible client.

The cost is setup and maintenance. You create the Cloud project, keep a credentials file on disk, and the server only exists while your machine is running it. It also hands your assistant the raw numbers and leaves the interpreting to you, which is the right shape if you already know what you are looking for and the wrong shape if your actual question is “is anything wrong.” How it compares to the other servers an indie developer might add is in our rundown of the servers worth adding at zero.

Route 3: the Search Console API with a service account

Pick this when the consumer is a script or a scheduled job rather than a person in a chat window. A service account is a Google account that belongs to your code instead of to you, so nothing has to open a browser at 3am. You create a Google Cloud project, enable the Search Console API, download the service account's JSON key, and then - the step people miss - grant that service account's own email address permission on the property from Search Console's users and permissions screen. Google's prerequisites are explicit that “your account must have the appropriate Search Console permission on a given property in order to call that method on that property,” and the service account is a different account from yours.

The request itself is one POST. As of August 2026 the Search Analytics query reference documents the endpoint and the request body as:

POST https://www.googleapis.com/webmasters/v3/sites/{siteUrl}/searchAnalytics/query

{
  "startDate": "2026-05-15",
  "endDate":   "2026-08-13",
  "dimensions": ["query", "page"],
  "rowLimit":   1000
}

Authentication is not on that page. You send an OAuth access token, minted from the service-account key, in an Authorization: Bearer header - which is the step a Google auth library exists to do for you.

startDate and endDate are required and use YYYY-MM-DD. rowLimit accepts 1 to 25,000 and defaults to 1,000, so a query with more rows than that silently gives you the top slice unless you raise it. siteUrl is the property exactly as Search Console spells it - https://example.com/ for a URL-prefix property or sc-domain:example.com for a domain property. Request the webmasters.readonly scope unless you have a specific reason to want write access.

Note what this route is not: it is not an assistant integration by itself. It gets you rows. Your assistant reads them only once something puts those rows in front of it - a file you paste, a database it can query, or an MCP server you write around this call, which is how routes 1 and 2 came to exist.

Route 4: a CSV export, with no setup at all

For a single question, this is still the fastest answer, and it is the one nobody writing about MCP wants to admit. Open Search Console, pick your property, open the Performance report, set the date filter to the last 3 months, and use the Export button to download a CSV. You get a small .zip, and you can drop it straight into a chat.

The catch is the one the four-routes list above already names: it is not repeatable. Every time you want current numbers you redo the whole thing by hand, which is fine monthly and unbearable weekly. If you want the same 6 checks the MCP server runs but without connecting anything, our browser-based Search Console report takes that export and analyses it in your browser - the file is never uploaded.

Which one to pick

• You want an answer, not a setup - the managed MCP server. One URL, one read-only consent, no Cloud project, and the output is a verdict rather than a table.
• You do not want a third party holding the grant - the open-source server. Same tools in your assistant, your credentials on your disk, your Cloud project to maintain.
• The consumer is a cron job, not a person - the API with a service account. Nothing to authorise interactively, and the output goes wherever you send it.
• You have one question and will not have another for a month - export the CSV. Setting up a server for a question you ask twice a year is the more expensive mistake.
• You have no Search Console data worth reading yet - none of the four. A site Google has barely crawled has nothing to report, and the useful check is whether Google can read the site at all.

FAQ

Is it safe to give an AI assistant my Search Console data?

It is read-only if you keep it read-only. The scope to grant is webmasters.readonly, which lets whatever you connected read your search data and nothing else - it cannot change your site, your Search Console settings, or your Google account. With the TrafficTriage MCP server that is the only scope requested, and you can revoke it any time from your Google account's security settings. On the self-hosted and API routes you choose the scope yourself, so ask for the read-only one; a key file with write access sitting on your laptop is the risk, not the assistant.

Do I need a Google Cloud project?

Only for two of the four routes. The open-source MCP server and the Search Console API both need you to create a Google Cloud project, enable the Search Console API, and download a credentials file. The managed MCP server does not - you approve read-only access once from your dashboard. A CSV export needs nothing at all.

Can ChatGPT read Search Console, or only Claude?

ChatGPT works. I connected the TrafficTriage MCP server to ChatGPT myself and it reads Search Console data the same way Claude and Cursor do. What you need is a client that can add a remote MCP server by URL, a TrafficTriage account, and Search Console connected to that account - the server is the same URL for every client. The current per-client setup steps live on the /mcp-server page, because each vendor moves its connector settings around.

What can I actually ask once it's connected?

Plain-English questions, not tool names. Ask run a Search Console report for example.com and the TrafficTriage server runs 6 checks on 90 days of your real data: whether your visibility is growing, the one query you are closest to winning, pages Google shows people who then don't click, how much of your traffic is just people typing your name, queries stuck on page 3, and whether your clicks are split across two versions of your site. The value is the follow-up question - because the assistant can also see your code, fix the title on that page is the next message rather than a separate task.