SEO analytics for AI agents

AI coding agents need SEO data they can call, not a screenshot: Search Console queries and pages plus on-site analytics, over MCP, with lag and non-summing rows attached. Without that, an agent will happily rewrite your title tags from vibes. It cannot open search.google.com, cannot click through a GA4 Exploration, and cannot paste a CSV into itself without you doing the work. The missing product is not “an SEO plugin for ChatGPT.” It is analytics the agent can call: queries, pages, clicks, on-site paths, goals — with the same caveats a careful human uses.

SiteLine is that product for one job: cookieless on-site analytics plus Google Search Console, both on MCP. It is not Mixpanel. It is not session replay. It is not a rank tracker. If the agent needs Ads attribution or a cross-day person id, keep the other tool.

This is the pillar for the AI agents cluster. Setup, including the config file for each client, lives in SiteLine MCP setup for agents. Why GA4 fails this job: why GA4 is a bad fit for agent workflows.

What an agent actually needs

The agent is about to edit a file. The question is whether that edit is attached to a query, a URL, and a date range that has actually landed. These are the calls that answer that, and the dataset each one belongs to.

Search Console and on-site analytics are two clocks. Clicks are Google-reported search clicks, about two days late. Pageviews are first-party events from browsers that ran the tracker. Visitor-days are a daily hash of those browsers, and they reset. An agent that subtracts visitors from clicks invents a leakage number. Teach it to ask both servers and keep the units. How humans do the same join: combine GSC with cookieless analytics. The unit mismatch, in longer form, is Search Console clicks vs analytics sessions.

A rank-tracker MCP still cannot tell you whether /pricing got pageviews. SiteLine still cannot tell you domain rating. Use both if you must. They are not the same column, and neither one is a substitute for the other’s clock.

Why a screenshot of Search Console is the wrong interface

The Performance report is a chart plus a table. The table is not the property. Google’s write-up, A deep dive into Search Console performance data filtering and limits, states the limit people hit when they export from the product interface: at most 1,000 rows. The same post explains the rest of the trap. Anonymized queries — those issued by only a small number of users over a couple of months — are omitted from the table and still included in the chart totals, unless you filter by query. Sum the visible rows and you will not match the chart. The Search Analytics API can return more than the UI (the post describes paging toward a 50,000-row daily ceiling per site per search type), but the default response is still a short page, and the privacy filter remains.

That is why “paste the CSV into the agent” fails three ways at once. The file is the UI cap, not the site. The model sums it and calls the sum organic traffic. Tomorrow the file is stale, and it has no data_through field to say which dates Google has not published yet. A browsing plugin that opens search.google.com fails login. A custom GPT pointed at the GA4 Data API still does not have queries.

SiteLine’s import is a warehouse the agent pages with tools. Totals still come only from get-site-overview. Breakdown tools are the visible rows. They are capped in our import (25,000 rows per day per report), and they still will not add up to the site, because Google withholds rare queries and because a filtered table is not the chart. The 1,000-row UI cap is Google’s. The “do not sum the table” rule is Google’s too, and it survives the move to MCP. Read data_through before anyone rewrites a title because yesterday looked empty.

What SiteLine MCP will and will not do

Two HTTP servers, one subscription. They stay two servers after you connect them. One token or one OAuth grant can authorise both. It does not merge the units.

• https://siteline.tools/mcp/search-console — imported Search Console performance. Read-only webmasters.readonly. 16-month backfill, kept while you subscribe, refresh every 4 hours of the last 7 days, including fresh rows, 25k rows/day/report. Tools and the rules for reading them are in Google Search Console MCP.
• https://siteline.tools/mcp/analytics — pageviews, daily visitor hashes, events, goals, ~30-minute realtime. No impressions. No SERP position.

Auth is OAuth (Claude.ai, ChatGPT, and other connector UIs) or a team-scoped bearer token (Cursor, Claude Code, Codex, Copilot, Windsurf, Continue, Gemini CLI, Cline). The token binds a team, not whichever site you last clicked in the browser. The agent cannot submit sitemaps, request indexing, or change Search Console users. It cannot push a CMS. If you also give the agent a GitHub or CMS server, that write access is a different product and a different blast radius.

Every Search Console response includes data_from, data_through, import_status, and a notes line. Dates after data_through are unpublished, not zero. Position is impression-weighted; CTR is clicks ÷ impressions (a fraction of 1: 0.0412 is 4.12%). Breakdown rows never sum to site totals. Discover and Google News have no queries and no position: the fields come back null, not 0. Ignore those notes and the model will ship a panic rewrite.

Soft event caps on Starter and Growth hide newer analytics rows in charts until you upgrade. Ingest continues. The tool response says so. That is a visibility cap, not a cue to invent the missing pageviews from Search Console clicks.

What “best” means for this job

“Best SEO analytics tool for an agent” is not a dashboard beauty contest. It is whether the model can list queries, respect lag, and — when the client can edit — open the file that maps to the losing URL.

Plausible, Fathom, and the other cookieless counters are honest pageview tools. They do not become the wrong product because an agent is in the loop. They become the wrong only tool when the agent is rewriting titles and cannot ask for the query. GA4 remains the wrong organic API for the same reason: the queries live in Search Console, and the Data API is a project you operate, not a connector the agent already knows how to call.

Best SEO analytics tool for each agent

The product does not change between clients. The config file does. Each link is a section of SiteLine MCP setup for agents, not a separate product review.

Chat clients (Claude.ai, ChatGPT, Grok on the web) are briefing surfaces. They can name the query and the URL. They should not be the thing that commits. Coding clients (Cursor, Claude Code, Codex, Copilot, Windsurf, Continue, Cline, Gemini CLI, and Aider when MCP is actually present) can open the file after the tool call. Grok or Claude or GPT inside Cursor is still Cursor’s MCP config. The model is not a second SiteLine server.

Setup walkthroughs that stay on one client’s wiring, rather than this category page: MCP for Search Console + analytics with Cursor, same for Claude.

Twelve client URLs are now one setup page

This cluster used to publish a separate URL for each client: Cursor, Claude Code, Claude, ChatGPT, OpenAI Codex, Grok, Windsurf, GitHub Copilot, Continue, Aider, Gemini CLI, and Cline. Those twelve pages repeated the same pricing and the same definition of “best.” The sentence that was actually different was the config: a filename, a transport key, OAuth or a bearer token, and a warning that belonged to that client alone.

That material is one page now, SiteLine MCP setup for agents. If you bookmarked a client page, open the matching section:

• Cursor
• Claude Code
• Claude
• ChatGPT
• OpenAI Codex
• Grok
• Windsurf
• GitHub Copilot
• Continue
• Aider
• Gemini CLI
• Cline

The argument on this page did not move with them. Agents still need callable Search Console and callable on-site analytics, kept as two unit systems. The setup page is where the JSON, the CLI flags, and the OAuth-versus-bearer choice live.

What is not in this category

Plausible, Fathom, Umami, and Simple Analytics are honest cookieless counters. They do not import query-level Search Console into a warehouse the agent can page through, and they do not ship SiteLine’s two MCP servers. GA4 can dump to BigQuery if you build the pipeline; that is a data-engineering project, not an agent connector. PostHog and Mixpanel are product analytics. Different job. Comparisons: privacy-first analytics comparison, SiteLine vs Google Analytics.

Nothing here is a claim about ranking inside AI Overviews, ChatGPT citations, or any other generative surface. Generative engines do not get a special ranking API from SiteLine. The cluster is agent-readable measurement of your own Search Console property and your own tracker.

Money, because agents still bill you

Starter $4.99 / 1M events, Growth $19.99 / 10M, Scale $99.99 then $2.99 per extra 1M. Unlimited Search Console sites, unlimited analytics domains, MCP and CSV on every tier. Soft cap on Starter/Growth: ingest continues, charts hide overflow until you upgrade. MCP is not an add-on and it is not billed per tool call. You pay for the subscription and for billable analytics events (pageviews and custom events), not for Search Console import rows. Billing. Trial: 7 days, no card to start. Register.

A prompt that does not embarrass you

Use SiteLine Search Console. Totals from get-site-overview only. Never average position or CTR. Never sum query or page rows to match the site. Respect data_through. Web search type unless I name another. Then use SiteLine Analytics for the same URLs and dates, and do not equate visitors with clicks.

Paste that into the agent’s project instructions. Then ask it to change a page only after it has named the query, the URL, and the coverage dates.

Paste that into the agent's project instructions. Then ask it to change a page only after it has named the query, the URL and the coverage dates.

The loop that should ship a diff

1. Coverage. get-import-status on Search Console. Read data_through. If the agent is talking about yesterday, stop.
2. Site totals. get-site-overview for a closed range. This is the only whole-site figure. Do not sum query rows.
3. What moved. get-movers between two completed periods. Name the query and the page. The investigate-traffic-drop prompt on the server walks steps 1 to 3 so the false alarms go first.
4. Cannibalisation. get-pages-for-query and get-queries-for-page before merging or splitting URLs.
5. On-site. Same dates, same path: get-analytics-breakdown on page, then get-analytics-goals if /thanks is the point. Report pageviews and visitor-days in their own sentence.
6. Edit. Change the template, heading or internal link that corresponds to that URL. Do not ask the agent to request indexing; SiteLine cannot. Do not treat realtime as the SEO result of a deploy.

Call-by-call detail and prompts: how to query Search Console with MCP.

Jobs agents are actually good at

• Striking distance. get-striking-distance returns queries roughly in positions 4 to 20. The agent compares the current title and H1 to the query without a separate keyword tool. Do not average those positions. The free opportunity analyzer does the same check on an export.
• Copy versus intent. The Search Console query on /pricing is the promise. The analytics path from /pricing to /signup is the landing. SiteLine does not auto-join query to session; the agent joins on page. How to combine GSC and on-site analytics.
• Deploy regression. Compare closed Search Console days with analytics timeseries over the same calendar. If analytics fell and Search Console did not, look at the tracker, the hostname allowlist or a redirect. If Search Console fell and analytics did not, look at the SERP and query mix, not the React tree.
• Internal links. get-top-results by page, then grep the repo for orphaned paths. A marketer in the Search Console UI cannot rg.

Jobs to keep away from the agent

• Publishing lag. Empty days after data_through are not a collapse.
• Discover and News. No queries, no position. Fields come back null, not 0.
• CTR algebra. 0.0412 is 4.12%. Position is already impression-weighted. Re-averaging is always wrong.
• Indexing. The scope is read-only webmasters.readonly. The agent cannot submit sitemaps or call the URL Inspection API through SiteLine.
• Ads and attribution. Not offered. Keep GA4 for paid. Why GA4 is a bad fit for agent workflows is about organic measurement, not a demand that you delete Ads.

Cursor and Claude Code sit on the repo, so step 6 is native. ChatGPT and Claude.ai are better at the briefing than the pull request.

FAQ

Is this “GEO” or “SEO for AI Overviews”?

Both, if you are sloppy with labels. This cluster is agent-readable measurement: your own Search Console and on-site numbers, callable from the tools that edit the site. It is not a claim that SiteLine ranks you in ChatGPT answers. Generative engines do not get a special ranking API from us.

Can I point the agent at GA4 instead?

Not as a first-class MCP server from Google. Exports, Looker Studio, and screenshots are not tool calls. That is the whole point of why GA4 is a bad fit for agent workflows.

Do I need two MCP connections?

Yes if you want both ledgers. One token can authorise https://siteline.tools/mcp/search-console and https://siteline.tools/mcp/analytics. They remain two servers with two unit systems. Visitors are not clicks.

Should the agent watch realtime analytics?

get-analytics-realtime covers roughly the last 30 minutes. Use it to confirm the tracker after a deploy, not to judge SEO. SEO is closed Search Console days.

Can the agent set goals?

No. Goals are defined in the SiteLine dashboard from paths and event names you already send. The agent can read get-analytics-goals but cannot create goals over MCP.

What if Search Console and analytics disagree on a URL?

Normal. The Search Console page is the URL Google counted; the analytics path is where the browser ended up. Redirects, trailing slashes and hostname allowlist misses show up here. Do not tell the agent to make the integers match.

I bookmarked a page that was only about one client

Open that client’s section on the setup guide. The twelve client write-ups are headings there. This page is still the reason to connect them at all.