Can Cursor do SEO? Rules, agent prompts and MCP servers

The short answer

Cursor writes the code. It doesn’t know which SEO and GEO jobs matter, and it can’t see your live site the way an AI crawler does unless you make it look. Three layers fix that, and each does a different job:

Most people start with the second layer, after “optimize SEO” did nothing. Why that prompt fails, and fifteen jobs that work instead, are on I asked Cursor to optimize SEO.

Layer 1: a rule file

Cursor reads project rules from .cursor/rules, and they must be .mdc files. The header takes a description (so the agent can decide when the rule applies), globs (attach it when matching files are in context) and alwaysApply. Cursor recommends keeping rules under 500 lines, and also reads a plain AGENTS.md at the project root (Cursor docs, “Rules”, read 15 Oct 2026).

Example: .cursor/rules/seo.mdc

---
description: SEO and GEO rules for public pages, robots.txt, sitemap and schema
globs: src/pages/**,app/**,public/robots.txt
alwaysApply: false
---
- Read research.md before changing any public page.
- Public pages render their text on the server or at build time. Check with
  curl, never only in the browser.
- One title and one meta description per page, from a single source.
- JSON-LD only with facts visible on the page. Never invent prices,
  ratings or reviews.
- robots.txt never contains "Disallow: /". OAI-SearchBot, ChatGPT-User,
  Claude-SearchBot and PerplexityBot stay allowed.
- App screens behind a login get noindex and stay out of the sitemap.
- After each change, list the files you touched and the command that proves it.

Adjust the globs to your framework’s folders.

Layer 2: prompts with a finish line

A rule says how to work. A prompt says what to do now, and the acceptance check says when it’s done. Three jobs to start with:

Cursor’s agent can run these commands itself, but run them yourself too before you accept a change. The six one-minute tests for sites built with AI tools are on My vibe-coded site is invisible to ChatGPT.

Layer 3: an MCP server

Cursor reads MCP servers from .cursor/mcp.json in the project or ~/.cursor/mcp.json for every project, and can take keys from your environment with ${env:NAME} (Cursor docs, “MCP”, read 15 Oct 2026). Use the user file for anything with a key, so the key never lands in a commit.

Which server depends on the job. Data servers (DataForSEO, Ahrefs, Search Console) pull numbers; workflow servers audit and tell the agent what to change. We compared seven on SEO MCP servers. Adding Katman looks like this:

{
  "mcpServers": {
    "katman": {
      "command": "npx",
      "args": ["-y", "katman-mcp"],
      "env": { "KATMAN_KEY": "${env:KATMAN_KEY}" }
    }
  }
}

Then ask the agent to call katman_start; it returns the next step. Full setup for every editor: Getting started.

Where Katman fits

Katman MCP fills the third layer and feeds the second. katman_scan_code reads your repo and reports how pages render; katman_audit_site requests the live pages as AI crawlers do, through your CDN; katman_prompt returns fifteen fix prompts (P0 to P14), each with its acceptance check, filled in for your framework; katman_page_brief writes briefs for the pages you’re missing; katman_visibility_run asks ChatGPT, Claude, Gemini, Perplexity and Grok whether they name you, on your own OpenRouter key (about $2.40 a run on the default panel). Katman Pro is $99 a month for up to 3 sites, with fix prompts and page briefs uncapped. Or have us do it: Growth writes 30 pages a month for you. More on the Katman page.

What it can’t do: it doesn’t edit the site by itself (Cursor’s agent does), doesn’t write to WordPress, doesn’t track daily rankings or keyword volumes, and full audits are counted per month. The rule file and the prompts above work without it.

Written by the Katman team, Rnify Limited. Cursor docs read 15 October 2026.