Cursor SEO: Rules, Skills, MCP, and the Loop That Works

Cursor is already good at the part of SEO that lives in files. Point it at a page and it rewrites the title to match the search, fills the section that only half answers the question, and adds an internal link with a sensible anchor. What it cannot do alone is pick which page deserves the edit, or tell you a month later whether the edit worked. Both answers sit in your Search Console, not in your repo.

So Cursor SEO comes down to three pieces of setup: a live read of your own search data, written rules that say how your site does things, and a date on which you check the result. This post covers each one, in the files Cursor actually reads.

TL;DR:

• Cursor makes the edit. Reading your real numbers first and checking the result after are the two halves you wire in yourself.
• Rules (.cursor/rules/*.mdc, or AGENTS.md) hold your conventions. Skills (SKILL.md folders) hold procedures the agent picks up when relevant. MCP servers hold live data.
• Connect Search Console with one entry in .cursor/mcp.json. Cursor handles the OAuth sign-in for remote servers that need it.
• Add one rule that names the live connection as the source for search data, or the agent may keep doing it the old way.
• Judge each edit from the day Google recrawls the page, against the rest of the site over the same weeks.

What does Cursor do for SEO without any setup?

It edits, and it edits well. It reads the codebase, finds the template the title comes from, and changes it in the right place. For a site that is a repo, that is most of the labour of on-page SEO.

What it lacks is the input. Cursor has no idea which of your pages lost clicks this month, which searches Google already shows you for at position 12, or which page Google credits for a search you care about. Those facts are not in the code. Asking a stronger model the same question without the data still gets you a guess, phrased more confidently.

Rules, skills or MCP: which file does which job?

Rules are standing context. Cursor's documentation is plain about why they exist: "Large language models don't retain memory between completions," and "Rules provide persistent, reusable context at the prompt level." Project rules live in .cursor/rules, versioned with the code, and they must use the .mdc extension: a plain .md file in that folder is ignored. Cursor also reads AGENTS.md in the project root and subdirectories. This is where your house conventions go: how titles are written, which pages make money, what has to pass before a change ships.

Skills are procedures. Cursor describes a skill as "a portable, version-controlled package that teaches agents how to perform domain-specific tasks," stored as a folder with a SKILL.md file in .cursor/skills/ or .agents/skills/. The agent decides when one is relevant, or you call it with /skill-name. An SEO skill is a good home for a checklist you run often, such as how your team audits a page before a rewrite.

MCP servers are live connections. In Cursor's words, MCP "enables Cursor to connect to external tools and data sources." This is the only one of the three that can know what changed in Search Console since yesterday, because the other two are text you wrote.

Most Cursor SEO setups pick one. A pack of SEO skills gives you an agent that knows a lot about SEO and nothing about your site. A data connection with no rules gives you live numbers and no house style.

How do you connect Search Console to Cursor?

Add the server to an MCP config file. Cursor reads .cursor/mcp.json in the project for tools scoped to one repo, and ~/.cursor/mcp.json in your home directory for tools available everywhere. A remote server needs only its URL:

{
  "mcpServers": {
    "queryscope": { "url": "https://mcp.queryscope.dev/mcp" }
  }
}

That is the hosted QueryScope server, which speaks Streamable HTTP, one of the three transports Cursor supports alongside stdio and SSE. "Cursor supports OAuth for servers that require it," so the first call opens a browser where you approve read-only access to Search Console and pick the site. The grant is webmasters.readonly, and you can revoke it from your Google account at any time. The MCP setup page has the same steps for Claude Code, Cline and Windsurf.

If you would rather run a Search Console server yourself, the same file takes a local command instead of a URL. The trade-offs between hosting it and running it are in the self-host vs hosted comparison.

Why add a rule once the server is connected?

Because a connected tool is only an option on a list. The agent sees the tools and decides for itself whether to call them. A rule is an instruction it reads every session, and an instruction usually wins. If the agent also knows an older routine, such as asking you for a Search Console export and parsing it, it can keep doing that while the live connection sits unused. Nothing errors. The answers are just staler than the data one call away.

The fix is a short project rule that says which source wins. Save it as .cursor/rules/search-console.mdc:

---
description: "Search performance comes from the connected Search Console server"
alwaysApply: true
---

The QueryScope MCP server is the source for this site's search data:
clicks, impressions, CTR, position, queries and indexing.

- Never ask for a Search Console export or parse exported files.
- Before changing a page for SEO, read how it is doing on the search first.
- If the tools error, say so and stop. Do not fall back to exports.

alwaysApply: true puts it in every chat. Cursor's guidance is to keep rules under 500 lines and split large ones, so keep this one about data and put your writing conventions in a rule of their own.

What does the loop look like inside Cursor?

Four steps, and the default setup covers only the third.

1. Read. The agent pulls your own Search Console for the site: which searches each page shows for, at what position, with how many clicks. Take totals from the page level and treat the query list as a sample, because Google drops rare queries from it for privacy. Page vs query data explains the gap.
2. Decide. One change, on one page, for one search. A page at position 6 that wins fewer clicks than that position usually earns is a title job. A page at position 14 needs a better answer, not a better title. A search with no page at all needs a page.
3. Edit. Cursor makes the change in the repo, and you review the diff like any other commit.
4. Measure. Wait for Google to recrawl the page, then compare the search's numbers before and since, against what the rest of the site did over the same weeks. Rankings move on pages nobody touched, so a change read without that comparison is mostly noise. The guide to tracking SEO changes covers the waiting windows.

The step people skip is the fourth, and it is the one that makes the next decision better.

Where does Cursor's judgement stop?

Three places, however it is wired. It sees the competing results page only for the searches it is pointed at, and even then it sees who ranks above you, not why Google prefers them. It sees nothing past the click, so it cannot tie an edit to a signup or a sale. And it cannot check its own reasoning, which is why the numbers it acts on should come from the source and be reread after the change.

There is a fourth limit that shows up later. Search Console keeps 16 months of data and then drops it. An agent reading live sees only what Google still has, so a question about last year's change can become unanswerable. Keeping a longer view means storing the data before Google deletes it.

So how should you set up SEO in Cursor?

Wire the two ends and leave the middle alone, because the middle already works. Connect your own Search Console over MCP so the agent decides from real numbers. Put your conventions in .cursor/rules, and add the one rule that names the live connection as the source. Then check every change from Google's recrawl, on a date you set before you made it.

That is the loop QueryScope runs from Cursor. It reads your own Search Console, holds the plan for the searches you chose, hands back one change at a time (the search, the page, what to change), and measures each edit with the rest of the site's movement taken out. It stops at the click: whether the extra visits convert is a question for your analytics. The same setup in Claude Code is covered in Claude Code SEO, and other tools that run where developers work are in SEO tools for developers.

Sources

• Cursor Docs, Rules ("Large language models don't retain memory between completions"; "Rules provide persistent, reusable context at the prompt level"; project rules are stored in .cursor/rules and must use the .mdc extension, and "A plain .md file in .cursor/rules is ignored by the rules system"; AGENTS.md is supported "in the project root and subdirectories"; "Keep rules under 500 lines").
• Cursor Docs, Agent Skills ("A skill is a portable, version-controlled package that teaches agents how to perform domain-specific tasks"; project skills load from .agents/skills/ and .cursor/skills/; "The agent is presented with available skills and decides when they are relevant based on context").
• Cursor Docs, Model Context Protocol (MCP "enables Cursor to connect to external tools and data sources"; .cursor/mcp.json for a project and ~/.cursor/mcp.json for every project; stdio, SSE and Streamable HTTP transports; "Cursor supports OAuth for servers that require it").