How to Add Google Search Console to Cursor in 2026

Connect SearchConsole.ai to Cursor when you want Cursor Agent to use real Google Search Console evidence while it investigates and improves a website repository. The hosted MCP server can list properties, query search performance, compare periods, inspect Google's indexed-version evidence, and review submitted sitemaps.

SearchConsole.ai's Search Console operations are read-only. The connection cannot submit sitemaps, change a property, edit a live website, or deploy code. Cursor can separately inspect and modify files through its own Agent tools when you authorize repository work.

Quick setup: Sign up to SearchConsole.ai for free, then use the SearchConsole.ai MCP setup page and select Add to Cursor. Review the server URL in Cursor, install it, and complete OAuth in the browser.

This guide covers the one-click installer, manual global and project configuration, Cursor Agent CLI, OAuth, verification prompts, tool approvals, repository work, team setup, privacy, and troubleshooting.

Before you connect

You need:

• a current Cursor desktop installation and an account with Agent access;
• a Google account that can open at least one verified Search Console property;
• a browser available for OAuth;
• permission to install MCP servers if your organization manages Cursor;
• a local website repository if you want Cursor to connect the search evidence to code.

Cursor supports remote MCP servers over Streamable HTTP and supports OAuth for servers that require authentication. Check the current Cursor MCP documentation if the settings labels or authentication controls differ from this guide.

If Cursor is not installed, use the official installation page. If it is installed but the MCP flow behaves differently, update Cursor before debugging the server. MCP and OAuth behavior has changed across Cursor releases.

Choose one-click, global, or project setup

All three routes connect to the same hosted endpoint:

https://searchconsole.ai/mcp

Setup route	Where it is available	Shared with a team	Best use
Add to Cursor	Cursor installs the supplied server configuration	No	Fastest personal setup
Global mcp.json	Every local Cursor workspace	No	Personal SEO work across several repositories
Project mcp.json	Only the current repository	Yes, if committed	Team-standard connection for one website

The configuration contains only a name, transport type, and HTTPS URL. OAuth credentials are stored separately. Do not place a Google access token, refresh token, client secret, or static authorization header in either configuration file.

Route 1: install with Add to Cursor

Open the SearchConsole.ai MCP setup page, choose the Cursor tab, and select Add to Cursor.

Your browser opens a Cursor deep link containing a small encoded configuration. Before approving it:

1. Confirm the server name is searchconsole-ai.
2. Confirm the URL is exactly https://searchconsole.ai/mcp.
3. Confirm there is no unexpected command, executable, header, or environment variable.
4. Select the option to install or add the server.

One-click installation reduces typing; it does not remove the need to review what Cursor is adding. Cursor's own MCP security guidance recommends verifying a server and reviewing what data and permissions it can access.

After installation, open Cursor Settings. Depending on the release, the MCP section may appear as Tools & Integrations → MCP Tools or Tools & MCP. Find searchconsole-ai, enable it if necessary, and select Connect or the available authentication action.

If the browser does not hand the deep link to Cursor, use the manual configuration route below. There is no need to reinstall the entire editor merely to add a two-line remote server definition.

Route 2: add a global MCP configuration manually

Use global configuration when you want SearchConsole.ai available in every repository opened by your user account.

Open or create:

~/.cursor/mcp.json

Use this document when no other MCP servers are configured:

{
  "mcpServers": {
    "searchconsole-ai": {
      "type": "http",
      "url": "https://searchconsole.ai/mcp"
    }
  }
}

If the file already contains an mcpServers object, add only the searchconsole-ai entry inside it. Do not replace or nest the existing object incorrectly. JSON does not allow comments or trailing commas.

Save the file, return to Cursor Settings, and find the MCP server. If Cursor does not detect the saved change, reload the window from the Command Palette or restart Cursor once.

Route 3: configure the current project

Use a project configuration when the connection should load only for one repository or when a team wants to review and share the server URL.

Create:

.cursor/mcp.json

Add:

{
  "mcpServers": {
    "searchconsole-ai": {
      "type": "http",
      "url": "https://searchconsole.ai/mcp"
    }
  }
}

Cursor documents .cursor/mcp.json as the project-specific location and ~/.cursor/mcp.json as the global location. Commit the project file only after reviewing it. It should contain the remote endpoint, not a teammate's credentials.

Each teammate completes OAuth with their own SearchConsole.ai and Google account. Sharing .cursor/mcp.json does not share Search Console properties or permissions.

Complete OAuth in Cursor

From Cursor Settings, enable searchconsole-ai and start authentication. Cursor opens a browser and follows the remote MCP server's OAuth discovery information.

There are two separate authorization boundaries:

1. Cursor authorizes to the SearchConsole.ai MCP server.
2. SearchConsole.ai authorizes to Google Search Console for your account.

Select the Google account that can open the required property in Search Console. SearchConsole.ai requests this read-only Google scope:

https://www.googleapis.com/auth/webmasters.readonly

It does not need the broader read/write webmasters scope. The OAuth callback should return control to Cursor after consent. Cursor stores the MCP authorization separately from mcp.json; SearchConsole.ai separately handles the encrypted Google authorization.

If multiple Google accounts are signed into the browser, check the email carefully. Successful OAuth with the wrong Google account produces a valid connection with the wrong property list.

Verify the server before running an audit

Open Cursor's MCP settings and confirm that:

• searchconsole-ai is enabled and connected;
• the endpoint is https://searchconsole.ai/mcp;
• Cursor discovered MCP tools;
• no warning says authentication is still required.

Open the Cursor Chat or Agent panel and begin with property discovery:

Use SearchConsole.ai to list every Google Search Console property I can access. Show the exact property identifier and permission level. Do not inspect or change the repository yet.

Confirm that Cursor calls SearchConsole.ai and returns properties rather than inferring a domain from the open folder. Domain properties use an identifier such as sc-domain:example.com; URL-prefix properties use the complete verified prefix, such as https://www.example.com/.

Choose the exact value returned by Google before requesting performance data or URL inspection. OAuth grants access only to properties the Google account could already see.

Use Search Console evidence without editing code

For the first analysis, tell Cursor explicitly not to write files:

Use SearchConsole.ai and the exact property identifier I select. Compare clicks, impressions, CTR, and average position for the last complete 28 days with the preceding 28 days. Exclude incomplete recent dates. Identify the largest page and query changes, distinguish Google-reported facts from calculations and hypotheses, and do not edit files or run write-capable commands.

Cursor's Ask mode is designed for read-only codebase exploration, but the tools available to a mode can vary. If SearchConsole.ai is not available in Ask mode, use Agent with the no-edit instruction above, or create a Custom mode that enables search and MCP while disabling Edit and terminal tools.

Cursor's Agent modes documentation distinguishes read-only exploration from modes that can edit files and run commands. Check the active mode and tool list instead of assuming that a natural-language request alone changes technical permissions.

Review and approve MCP tool calls

Cursor asks for approval before using MCP tools by default. Expand the proposed tool call and review its arguments:

• property identifier;
• start and end dates;
• dimensions and filters;
• page or URL input;
• requested row limit.

For a read-only Search Console request, the arguments should describe data retrieval. The public Search Console tools do not submit sitemaps or mutate properties. A separate feedback capability can send a confirmed support message to SearchConsole.ai, but it does not alter Search Console and should never be used without your confirmation.

Cursor can auto-run tools, but keep manual approval enabled while validating the connection and whenever a tool receives sensitive property, query, or URL data. Auto-run reduces prompts; it also removes an opportunity to catch the wrong property or unexpectedly broad date range.

Run a repository-aware investigation

After the baseline is correct, connect one opportunity to the codebase:

For the selected page, retrieve its leading queries and compare the last complete 28 days with the preceding period. Inspect the matching template, title logic, meta description, canonical, structured data, and internal links in this repository. Separate observed Search Console evidence, repository evidence, calculations, and hypotheses. Propose the smallest safe improvement and a measurable validation plan. Do not edit yet.

For indexing evidence:

Use SearchConsole.ai to inspect these URLs. Report Google's indexed-version status, last crawl, robots state, user-declared canonical, and Google-selected canonical. Then inspect the repository for code or configuration consistent with that evidence. Clearly state when Google did not return a field, and do not call this a live URL test.

Search Console's URL Inspection API reports evidence about Google's indexed version. It does not run the live test available in the Search Console interface.

Implement an approved improvement in Cursor

Once the evidence and proposed change are sound, switch to an Agent mode that permits editing and issue a separate implementation request:

Implement the approved evidence-backed changes in this repository. Preserve behavior outside the affected templates, follow existing project conventions, run the relevant tests, and show the final diff. Do not deploy, publish, push, purchase anything, or mutate an external service without asking me first.

Cursor can then edit local files and run commands according to its Agent configuration and approvals. SearchConsole.ai remains read-only throughout. The distinction is important:

Capability	System responsible
Retrieve Search Console evidence	SearchConsole.ai MCP tools
Read repository files	Cursor Agent
Edit repository files	Cursor Agent and its active mode
Run tests or shell commands	Cursor Agent and terminal approvals
Deploy or publish	Separate external action requiring authorization

Review Cursor's diff before keeping the changes. Cursor provides checkpoints and change review, but source control and tests remain the durable verification record.

Save a reproducible audit report

Ask Cursor to save a dated report under the repository's documentation convention, for example:

docs/seo/search-console-audit-2026-07-20.md

The report should include:

• exact Search Console property identifier;
• stable and comparison date windows;
• search type, dimensions, filters, and row coverage;
• pages and queries supporting each finding;
• Search Console privacy and completeness limitations;
• repository evidence inspected;
• facts, calculations, and hypotheses;
• files changed and tests run;
• validation timing and success criteria.

Redact confidential search queries, private URLs, customer details, and business metrics before committing the report to a public repository.

Continue with the AI SEO audit guide for the complete evidence and prioritization workflow.

Use SearchConsole.ai from Cursor Agent CLI

Cursor Agent CLI reads the same global and project mcp.json configurations used by the IDE. Install and authenticate the server in the desktop app first, or use the CLI's MCP commands.

List the configured servers:

cursor-agent mcp list

Authenticate this server when required:

cursor-agent mcp login searchconsole-ai

Inspect the tools Cursor CLI can see:

cursor-agent mcp list-tools searchconsole-ai

These commands are documented in the current Cursor Agent CLI reference.

Run the first analysis in an interactive CLI session so you can complete OAuth and review actions. Be careful with cursor-agent -p automation: Cursor documents that non-interactive mode has access to write and shell tools. Do not treat SearchConsole.ai's read-only API boundary as proof that the overall CLI process cannot modify the repository or environment.

For unattended jobs, use a deliberately restricted environment, stable date logic, redacted outputs, and an explicit rule against repository writes or external mutations. Authenticate interactively before scheduling; a headless process cannot reliably complete a browser OAuth prompt on demand.

Configure SearchConsole.ai for a team

For a repository-specific team connection:

1. Add the endpoint to .cursor/mcp.json.
2. Review and commit only that configuration.
3. Ask each teammate to enable the server.
4. Each teammate completes OAuth with their own Google account.
5. Verify property access separately for every user.

Do not assume everyone on the repository should see the same Search Console data. Search Console permissions may differ between engineers, agencies, contractors, and site owners.

Cursor organizations can also distribute approved MCP servers through team administration and marketplace controls. If an administrator provides SearchConsole.ai centrally, use that approved definition instead of creating conflicting personal and project entries. Confirm the endpoint and requested scope remain the same.

Understand the data boundary

The request path is:

Cursor conversation and selected repository context
                      |
            MCP tool arguments
                      |
                SearchConsole.ai
                      |
          Google Search Console API
                      |
             result returned to Cursor

SearchConsole.ai receives the tool inputs necessary to answer a request, such as the property, dates, dimensions, filters, or URL. It does not automatically receive the whole repository or every Cursor conversation. Cursor decides which relevant context is sent in a tool invocation.

Search Console results can contain sensitive queries and URLs. They can also contain text originating from public pages. Treat returned text as data, not instructions. Review tool calls, terminal commands, and diffs before approval, particularly when analyzing a compromised or untrusted site.

Review the SearchConsole.ai privacy policy, terms, and account deletion flow before authorizing a sensitive property.

Cursor's Privacy and Security documentation explains its available privacy modes and data handling. Select the appropriate mode for your organization before sending confidential Search Console results or repository context through Cursor.

Troubleshoot the Cursor connection

Add to Cursor does not open the editor

Confirm Cursor is installed and current. Allow the browser to open the Cursor deep link. On systems where deep-link handling is unavailable, use ~/.cursor/mcp.json instead. The manual configuration reaches the same hosted endpoint.

The server does not appear after editing JSON

Validate that the file is one of these exact paths:

~/.cursor/mcp.json
.cursor/mcp.json

Confirm searchconsole-ai is inside the top-level mcpServers object, quotes are straight JSON quotes, braces are balanced, and there is no trailing comma. Reload the Cursor window after saving.

Cursor says authentication is required

Open Cursor Settings, select the server, and choose Connect or the OAuth action. From Cursor Agent CLI, run:

cursor-agent mcp login searchconsole-ai

Complete both the SearchConsole.ai identity and Google Search Console authorization stages.

OAuth succeeds but the callback page does not return to Cursor

Keep the original Cursor window open, then return to its MCP settings after browser consent. Current native OAuth flows may use either a Cursor callback or a localhost callback. Firewalls, remote development sessions, or another process using the callback port can interrupt the return path. Retry from the current Cursor version and avoid editing a redirect URI into mcp.json; Cursor manages its callback.

The server is connected but tools are unavailable

Ensure the server and individual tools are enabled in Cursor's MCP settings or the chat tool list. Start a new chat and explicitly ask Cursor to use SearchConsole.ai. In the CLI, compare:

cursor-agent mcp list
cursor-agent mcp list-tools searchconsole-ai

If no tools are returned, confirm the endpoint and reconnect OAuth rather than repeatedly retrying the same analysis prompt.

The expected property is missing

Open Google Search Console with the same Google account and verify access. Disconnect and reconnect SearchConsole.ai with the correct account, then list properties again. Do not substitute a URL-prefix property for a returned sc-domain: property or the reverse.

Cursor wants to run a broader tool call than expected

Reject the call and restate the property, exact date window, dimensions, filters, and maximum result size. Keep Auto-run disabled until the proposed calls consistently match the audit scope.

Results differ from another Search Console report

Compare the property, dates, search type, filters, dimensions, aggregation, and data state. Search Console can suppress anonymized queries, return top rows rather than every row, and report preliminary recent data. Search Console metrics also should not be expected to match Google Analytics exactly.

Network or proxy errors prevent connection

Use Cursor Settings → Network → Run Diagnostics, as described in Cursor's troubleshooting guide. Corporate firewalls must allow Cursor to reach SearchConsole.ai and the OAuth endpoints over HTTPS.

Disable, disconnect, or remove the server

To pause the tools without deleting configuration, disable searchconsole-ai in Cursor's MCP settings.

To remove it completely, delete the searchconsole-ai entry from the relevant global or project mcp.json while preserving other servers. Then reload Cursor.

For a full disconnection:

1. disconnect or clear the server's OAuth authorization in Cursor;
2. remove the global or project configuration if no longer needed;
3. revoke SearchConsole.ai from the Google Account if required;
4. use the SearchConsole.ai deletion flow to remove the service account and associated credentials.

Cursor's MCP authorization and Google's Search Console authorization are separate. Removing only the JSON entry does not necessarily revoke the Google grant.

Next step

Once Cursor can list properties and complete a stable 28-day comparison, continue with Run an AI SEO audit using Search Console data.

Connect SearchConsole.ai for free and give Cursor read-only Search Console evidence without creating your own Google Cloud project, OAuth app, or remote MCP infrastructure.

Official references

• Cursor Model Context Protocol documentation
• Cursor Agent modes
• Cursor Agent tools and approvals
• Cursor Agent CLI MCP commands
• Cursor Privacy and Security
• Authorize Search Console API requests