Google Search Console MCP: Setup and SEO Analysis

A Google Search Console MCP connection lets a compatible AI assistant retrieve your property's search-performance data and help analyze it. The practical setup is to connect a trusted server, authorize the correct account, confirm the selected property, and request data with explicit dates and filters. You can then investigate clicks, impressions, query-to-page relationships, and performance changes without treating the assistant's guesses as measurements.

The server you choose determines the setup. A hosted service may manage the Google connection through its product, while a community implementation may require Google Cloud configuration and local credentials. Client compatibility and workspace access also vary.

This guide uses Screpy's remote MCP connection for the worked example and remains client-neutral. The recorded Search Console call was made through an authenticated MCP session; we did not reproduce every client's sign-in interface. The important outcome is a request you can verify, a result whose limits you understand, and a clear distinction between performance analysis, URL Inspection, and requesting indexing.

Choose a Google Search Console MCP connection

Before selecting a server, confirm that you can access the intended Search Console property. MCP does not bypass Google's property permissions, and a successful AI-client connection cannot reveal a competitor's private Search Console data. If the protocol is new to you, the SEO MCP server guide explains how the data source, server, and assistant work together.

If the service is new to you, start with how Google Search Console works. Connecting an assistant is a second step, after the correct website property and account access exist.

There are two common connection paths:

The mikusnuz GSC MCP repository documents one community implementation. Its setup and tool surface belong to that project; they are not universal requirements for every Search Console MCP server.

For Screpy, use a client that supports remote HTTP MCP and browser-based OAuth. You need a Screpy account with access to the relevant project and an available Search Console connection for that project.

Check data permissions and action permissions separately. A connector may expose only read operations, or it may bundle unrelated tools with different consequences. You should know what is available before issuing a broad request.

Finally, decide which property you mean. A Domain property such as sc-domain:example.com and a URL-prefix property such as https://www.example.com/ can have different scope. A mismatch here can make a correct request look wrong. Record the property identifier, not just the friendly website name.

Set up Search Console MCP in a compatible AI client

The Screpy path has two connections: your client authenticates with Screpy, and the selected Screpy project needs access to its Search Console property. Verify both rather than assuming that connecting one automatically completes the other.

1. Add the Screpy remote endpoint

Open the client's MCP, apps, tools, or connector settings and add:

https://mcp.screpy.com

Use the current Screpy MCP setup instructions for prerequisites and links to individual client guides. The shared endpoint works through compatible remote HTTP clients, but the configuration format and menus differ.

2. Complete Screpy OAuth

Authorize in the browser using the Screpy account that can access your website project. Do not paste a Screpy REST API token into this connection. If a workspace administrator controls custom connectors, complete that approval path before troubleshooting data requests.

3. Discover the project

Ask the assistant:

List my accessible Screpy projects and identify the project for [website]. Do not create or change any project.

Select the intended project from the result. Tools use its returned project UID; do not invent an identifier or copy one from another account.

4. Verify the Search Console connection

Ask:

For the selected project, check whether Search Console is available and show the exact selected property. Retrieve connection information only.

Our recorded check returned availability: available and site_url: sc-domain:screpy.com. That establishes the selected source for the worked example. It does not establish that every report has data.

If the source is unavailable, resolve the Google connection and property selection in Screpy. Inspecting the connection through MCP does not authorize new Google access or repair the underlying account setup by itself.

5. Run one small performance query

Use a known period and one query or page. Confirm that the response includes the intended property, dates, search type, and metrics. A small request is easier to compare against the Search Console interface than a generated report covering every query.

Screpy provides setup guides for Codex, ChatGPT, Claude, Cursor, VS Code, and Gemini CLI. Choose the client you already use; the SEO analysis should depend on the data and supported tools, rather than the assistant's brand.

Ask questions with explicit dates and filters

“Show last month's SEO performance” leaves several decisions to the assistant. It must choose a calendar period, search type, aggregation, filters, and comparison. A reproducible request states these choices.

For Screpy's query-and-page tool, this example preserves the parameters used in our recorded request. Replace the project placeholder with the UID returned by discovery:

{
  "project_uid": "YOUR_PROJECT_UID",
  "dimensions": ["query", "page"],
  "start_date": "2026-07-01",
  "end_date": "2026-09-28",
  "search_type": "web",
  "filters": [
    {
      "dimension": "query",
      "operator": "equals",
      "expression": "seo mcp"
    }
  ],
  "limit": 100
}

The selected dimensions answer “Which page appeared for this query?” A page-only request answers a different question. Country or device filters can also change the result, so retain them in the output even when no restriction is applied.

Screpy's custom dates are interpreted in Pacific time. Do not combine custom dates with a preset range in this tool. For a period comparison, name both windows and keep search type and filters identical. Decide explicitly whether you need equal lengths, matched weekdays, or calendar months.

An illustrative analysis prompt is:

Return web-search query-and-page rows for [website] between [start] and [end]. Apply [explicit filters]. Show clicks, impressions, CTR units, and average position. Follow available pagination without changing the request scope, preserve warnings, and do not infer zero traffic from missing rows.

If a cursor is returned, use it for the same project, dates, dimensions, filters, and limit. Changing the parameters mid-pagination creates a different dataset.

For website totals, request the appropriate overview separately. Adding displayed query rows is not a reliable substitute for aggregate performance. Screpy Search Console provides both overview and filtered analysis, but the assistant still needs to choose the right one for the question.

A real query-and-page analysis from Screpy

We retrieved the following result through an authenticated Screpy MCP call on October 1, 2026. It covers web search from July 1 through September 28, grouped by query and page, with an exact filter for “seo mcp.”

This is an excerpt of the observed response; the project context and some surrounding fields are omitted:

{
  "site_url": "sc-domain:screpy.com",
  "rows": [
    {
      "dimensions": {
        "query": "seo mcp",
        "page": "https://screpy.com/feature/seo-mcp/"
      },
      "clicks": 0,
      "impressions": 188,
      "ctr_percent": 0,
      "average_position": 27.1383
    }
  ],
  "data_state": "final",
  "rows_may_be_incomplete": true
}

The result is useful because it ties a real query to a real page. The feature page already has recorded visibility for the term, so an editor should inspect that page before treating the keyword as an entirely new topic with no existing destination.

The row's CTR is zero: zero clicks divided by 188 impressions, multiplied by 100. It does not show that a title rewrite would create clicks. That decision requires reviewing search intent, the current result, the page's value, and a sufficiently useful comparison window.

Average position 27.1383 is not a live rank check. It summarizes recorded appearances across this row's scope. Country, device, date, and result variation can affect its interpretation.

The sample also cannot measure total searches for “seo mcp.” Search Console reports our property's exposure, while a licensed keyword provider supplies a different kind of market estimate. Neither number should be silently substituted for the other.

This is a data-retrieval example, not a ranking-improvement experiment. The Screpy MCP integration supplies the evidence; whether to update a product page, create an informational guide, or leave the page alone remains an editorial decision.

Turn performance evidence into SEO decisions

Once setup is working, ask for a specific decision supported by comparable data. A useful report connects a pattern to the next verification step, rather than presenting every metric change as a diagnosis.

Compare traffic declines without inventing the cause

Retrieve page-level performance for two explicit periods with matching filters. Sort by absolute click loss and review the pages that matter commercially. Percentage loss alone can exaggerate small changes on pages with very little traffic.

For illustration, a page falling from 120 to 84 clicks loses 36 clicks, or 30%. A page falling from 4 to 1 loses 75%, but only three clicks. These are hypothetical values that explain the arithmetic, not Screpy results.

For each candidate, inspect query mix, impressions, position, seasonality, recent page changes, and available crawl evidence. If clicks and impressions fall together while position remains similar, demand or exposure deserves investigation. If position worsens for important queries, examine the page and its competitors. Neither pattern alone proves a specific cause.

Review low CTR in context

Ask for query-page pairs with enough impressions to justify review and a defined position range appropriate to your site. Do not apply a universal CTR benchmark to unrelated queries and result layouts.

Check whether the title and page answer the query, whether the URL is the intended destination, and whether impressions are concentrated in a particular country or device. The recommendation should say what to verify before changing the snippet.

Investigate multiple pages appearing for one query

Group by query and page, then inspect cases where several URLs appear. This identifies possible intent overlap; it does not establish cannibalization on its own.

Two pages can legitimately serve different tasks. A product page and a tutorial may both appear for a broad term. Before proposing a merge or redirect, compare their intent, historical performance, and content. Use the existing guide to finding and fixing keyword cannibalization for that broader review.

Turn the output into a reviewable action list

Keep the first pass read-only. Drafting a recommended change is useful; applying it to a CMS or repository is a separate authorized operation.

Fix missing rows and mismatched totals

When an assistant's report disagrees with Search Console, reproduce the request before blaming the model or changing the website.

Check the following in order:

Google's Search Analytics reference explains that internal limitations mean the API returns top rows and does not guarantee all data rows. Pagination can retrieve the rows available for the request; it cannot restore data that was not returned.

For a manual cross-check, open the same property in Search Console and set the same dates, search type, country, device, and query or page filter. Compare the matching report view. Save the request parameters alongside the response so another person can reproduce the comparison.

Do not average CTR percentages across rows to obtain a total. When combining compatible complete groups, calculate clicks divided by impressions. An unweighted average treats a row with ten impressions like one with ten thousand. Summing a limited query table still does not reproduce the property's aggregate.

Screpy responses expose retrieval and cache context where applicable. An available response can therefore be slightly older than the latest dashboard view. Keep the source's collection time separate from the time the assistant writes its answer.

If setup itself fails, use Screpy MCP troubleshooting. If setup succeeds and data is unavailable, investigate the source connection and scope. Rephrasing the prompt is not a reliable fix for incorrect permissions or missing evidence.

Use URL Inspection for the right question

Search-performance reports and URL Inspection answer different questions. A performance request shows recorded search appearances and clicks for a period. Inspection asks about Google's indexed view of one URL.

The URL Inspection API does not test the current live page. Screpy's inspection tool uses that indexed view; it is not a “Request indexing” action.

For an exact page, choose the source that matches the question:

Screpy Index Status adds context from existing index-status work. Reading the latest stored audit does not start a new audit or refresh every URL.

A Google Search Console MCP workflow is successful when the assistant retrieves the intended evidence, reports its limits, and helps you make a reviewable decision. Start with a verified connection and an explicit request. Expand into comparisons and page diagnosis only when the underlying data supports the next step.