How to connect Claude in your browser to Search Console and GA4

Why do most Search Console MCP guides fail in the browser?

Because they describe a local server, which Claude in a browser has no way to reach.

A local setup asks you to clone a repository, install Python or Node, and point a config file at a script on your hard drive. Claude Desktop then launches that script as a subprocess on your machine. That architecture cannot work in a browser: claude.ai runs on Anthropic's servers, not on your laptop, so there is no path from the web app to a process on your desktop.

One widely used Search Console MCP repository states the limitation directly: the server runs locally and works in the Claude Desktop app, not in the claude.ai browser interface.

So if you followed a guide, got it working on your desktop, then wondered why the tools vanish when you open Claude on your phone, nothing is broken. You installed the wrong shape of server for where you want to use it.

A remote MCP server fixes this. It lives at a public HTTPS URL, holds the Google credentials itself, and authenticates Claude over OAuth. Because it is a URL rather than a process, every Claude surface can reach it: browser, desktop app, mobile and Claude Code.

Local, self-hosted remote, or a vendor connector: which do you need?

Three options exist, and they differ in where the server runs and who holds your credentials.

Pick a vendor connector if you want data in Claude this afternoon and are comfortable with a third party holding read access to your analytics. Several exist for GA4.

Pick a local server if you work only in Claude Desktop or Cursor and never need this on a phone.

Pick a self-hosted remote server, which is what this guide builds, if you want browser and mobile access, credentials that stay in infrastructure you own, and control over exactly which reports exist as tools. The trade-off is the longest setup of the three.

Why use a service account instead of OAuth?

Because a service account is configured once, where an unverified OAuth app has to be re-authorised every week.

Most local Search Console guides use an OAuth desktop client. You create OAuth credentials, download a client secrets file, and sign in through a browser window the first time you run a tool. It works, and it carries baggage. Your Google Cloud app sits in testing status unless you push it through verification, and refresh tokens issued by an unverified app expire after seven days. You also have to add yourself as a test user before Google will let you past the consent screen, which is the cause of the access blocked error people hit constantly.

A service account avoids all of it. It is a separate Google identity that authenticates with a private key instead of a human sign-in. There is no consent screen, no test-user list, no seven-day expiry and no browser window. You generate a key once, store it as an environment variable, and the server authenticates silently.

The mental model worth holding: a service account starts with access to nothing. Creating it grants no visibility into your data at all. You then invite that identity into your Search Console property and your GA4 property, exactly as you would invite a colleague. That invitation is what grants access, and revoking it later is one click with no effect on your own account.

What do you need before you start?

Five accounts, all of which you probably already have, and one paid Claude plan.

You do not need a terminal, a credit card, or any knowledge of Python or Node. Every step below happens in a browser. Budget 40 minutes for a first run, roughly ten of which is waiting for Google to propagate permissions.

• A verified Search Console property for your site, with you as an owner or full user
• A GA4 property collecting data on the same site
• A Google account that can create a Google Cloud project, whose free tier covers both APIs used here
• A GitHub account and a Vercel account, both free, for hosting the server
• A paid Claude plan, since custom connectors are a Pro, Max, Team or Enterprise feature

Step 1: Create the Google Cloud project and service account

This step produces one JSON file holding the identity your server will use.

Go to console.cloud.google.com and create a project, named something you will recognise later. Check it is selected in the project dropdown before continuing, because configuring the wrong project is a common early mistake.

Open APIs and Services, then Library, and enable the Google Search Console API. Return to the Library and enable the Google Analytics Data API. Both must be enabled in the same project.

Open APIs and Services, then Credentials, then Create Credentials, then Service account. Give it a name and click through the optional role and user steps without filling them in. The service account needs no IAM roles, because its access comes from the invitations in Step 2 rather than from Google Cloud permissions.

Click into the new service account, open the Keys tab, and choose Add Key, then Create new key, then JSON. A file downloads. Two values in it matter: client_email, an address ending in .iam.gserviceaccount.com, which is the identity you invite to your properties; and private_key, a long block beginning BEGIN PRIVATE KEY, which is a credential. Treat the key like a password: never commit it to a repository and never paste it into a public issue.

Step 2: Invite the service account to your data

Two invitations turn an identity with no access into one that can read both properties.

In Search Console, open your property, then Settings, then Users and permissions, then Add user. Paste the client_email address and set permission to Full. Restricted access works for reporting, and URL Inspection requires owner-level access, so Full avoids a later surprise.

In GA4, open Admin, then Property access management, click the plus button, and add the same address with the Viewer role. Untick the notification email, since a service account has no inbox.

Now collect two identifiers. The Search Console site URL must match your property type exactly: a domain property is sc-domain:example.com, and a URL-prefix property is the full URL with its trailing slash. A mismatch produces an invalid-argument error that gives no hint about the cause.

The GA4 property ID is the nine-digit number at the top right of Admin, then Property details. It is not the G-XXXXXXXX measurement ID from your tracking code, and confusing the two is the single most frequent reason a GA4 connection returns zero rows.

Permission changes can take several minutes to propagate. If a query fails immediately after this step, wait ten minutes before changing anything.

Step 3: Deploy the remote server

Your server has four jobs: authenticate to Google with the service account, expose Search Console and GA4 queries as MCP tools, speak the MCP protocol over HTTPS, and act as its own OAuth provider so Claude can authenticate to it.

That last requirement surprises people. Claude's custom connector dialog accepts an MCP server URL and optional OAuth credentials, and there is no field for custom headers, so an API key in a header is not an option. Your server either implements OAuth or sits open on the public internet. Implement OAuth.

Deploying without a terminal: create a private GitHub repository and use the uploading an existing file link to drag your server's files in, dragging the contents of the project folder rather than the folder itself, or the host will not find the project at the repository root. Import that repository at vercel.com/new and leave the build settings untouched.

Before deploying, expand Environment Variables and add the service account email and private key, your Search Console site URL, your GA4 property ID, a long random signing secret and an access passphrase. Paste the private key without the surrounding quotation marks. Deploy, then copy your production domain.

Verify it worked by opening your domain followed by /.well-known/oauth-protected-resource in a browser tab. A small block of JSON means the server is live and discoverable. An error page means the deployment failed, so check the build logs before continuing.

Step 4: Add the custom connector in Claude

Four clicks in claude.ai, and the one thing to get right is leaving the OAuth fields empty.

Open Settings, then Connectors, then Add custom connector. Give it a name, then paste your server's MCP endpoint, which is your domain followed by /mcp. Leave OAuth Client ID and OAuth Client Secret blank: a server implementing dynamic client registration issues these itself, and filling them in with invented values breaks the connection. Click Add, then Connect, then enter your access passphrase on your server's consent screen and authorise.

On Team and Enterprise plans an organisation owner has to add the connector URL first, after which members click Connect individually.

The same URL works everywhere Claude supports custom connectors, including the desktop app, Claude Code and the mobile apps, from one deployment and one set of credentials.

If the connector will not connect, confirm that the discovery endpoint from Step 3 still returns JSON and that every environment variable is set in the production environment specifically. Variables scoped only to preview deployments are a frequent cause.

What should you ask once it is connected?

The value sits in the questions that span both data sources, or that involve enough rows that you would normally not bother.

Find your striking-distance pages. Ask for page and query pairs ranking between positions 5 and 25 with meaningful impressions and poor click-through. These are pages one optimisation pass from page-one traffic. It is the highest-return report in SEO and almost nobody runs it, because building it by hand means exporting a page-query pivot and filtering it. Claude can produce and interpret it in a single turn.

Join rankings to behaviour. Search Console tells you what earns clicks and GA4 tells you what happens next. A page ranking well with a high bounce rate is a different problem from a page ranking badly, and it needs a different fix. One connector holding both datasets lets you ask the combined question directly.

Diagnose a drop properly. Traffic fell last month is not actionable. Ask which queries lost clicks against the prior period, whether average position moved or impressions fell, and whether the losses cluster on particular pages or templates. Position loss and impression loss have different causes.

Audit what exists and earns nothing. Ask for pages with impressions but near-zero clicks, and for pages receiving no organic sessions at all. The first group has a title and meta description problem. The second may have an indexing problem. Whatever the answer gives you, read it against a reference point rather than in isolation: our marketing benchmarks page carries the figures we use for that.

One caution worth internalising: an assistant with your analytics data will still produce confident narratives from thin numbers. Twelve sessions is not a trend. Ask for absolute figures alongside any percentage change, and treat small-sample conclusions with the scepticism you would apply to any other report.

Troubleshooting: five errors that account for most failed setups

Each of these has one cause and one fix, and four of the five are configuration rather than code.

One more worth knowing: URL Inspection requires owner-level Search Console access, so it can return a permission error even when every reporting tool works. Reporting and inspection are governed by different permission tiers.

If the problem turns out to be that pages are not indexed rather than that the connector is broken, the fix is on the page rather than in the server. Our answer engine optimization checklist covers what makes a page retrievable and quotable in the first place.