GuidesAI agents

How to run an SEO audit with Cursor, and check the fixes worked

Connect Cursor to an SEO audit tool with one JSON entry, run the audit, fix issues by cause and audit again. Includes project versus global config, troubleshooting and what the agent gets wrong.

6 min readUpdated 2026-11-08By the Auditmatic team
On this page

Cursor's agent can edit your code but cannot see how search engines see your live site. An SEO audit tool connected over MCP supplies that view: it crawls the deployed site, the agent reads the findings and changes the code, and you audit again to confirm. This guide covers the parts that are specific to Cursor, which are the config file, the sign-in and how to troubleshoot a server that will not connect, and links to the general workflow for the rest.

Project: this site only
.cursor/mcp.json
Lives in the repository
Can be shared with a team
Global: every project
~/.cursor/mcp.json
Lives in your home folder
Applies everywhere
Illustration of the two places Cursor reads MCP servers from. Use the project file for one site and the global file for every project.

What you need before you start

  • Cursor installed, with your site's folder open.
  • An Auditmatic account to sign in with. The free audit works without one, but the agent connection needs it.
  • A site that is live on the internet. The crawler reads the public site, so a server on your laptop cannot be audited.

1. Add the server

Cursor's documentation says to create .cursor/mcp.json in your project for project-specific tools, or ~/.cursor/mcp.json in your home folder for tools available everywhere. For a remote server the entry is a name and a url:

{
  "mcpServers": {
    "auditmatic": {
      "url": "https://auditmatic.app/mcp"
    }
  }
}

If the file already has other servers, add the auditmatic entry beside them inside the same mcpServers object rather than pasting a second one. A JSON file with two top-level objects will not load.

2. Sign in

Cursor documents that sign-in to a remote server uses the OAuth authorization code flow with PKCE, so you approve the connection in your browser instead of pasting a key. We followed Cursor's documentation for this client rather than testing it ourselves, and its menu labels have changed between versions, so if what you see differs from this page, trust the screen. Cursor's own page says servers can be switched on and off from Customize in the sidebar.

3. If it does not connect

Open the Output panel with Cmd+Shift+U on a Mac, then choose MCP Logs from the dropdown. Cursor's documentation points there for connection and sign-in errors. Three causes are common:

  • Invalid JSON. A trailing comma or a second top-level object stops the file loading. Paste it into a JSON checker.
  • Wrong file. You edited the project file but opened a different folder, or edited the global file and expected it to appear only in one project.
  • Sign-in never finished. If you closed the browser tab, remove the sign-in and start it again.

4. Ask for the report, not just the issues

Audit example.com. Start a site audit with a limit of 50 pages,
wait for it to finish, then read the audit report. List only the
errors and warnings, grouped by cause, with the pages affected.
Do not change any code yet.

Naming the report matters. A crawl produces raw issues; the report groups them and adds page speed and homepage checks. In our own testing an agent once read only the raw list and called the site nearly clean while the report showed five errors. Save the first result as a baseline.

5. Fix one cause at a time

Most findings share a root cause, such as one template or one missing header. Ask for a single cause and an explanation before any edit:

Fix the pages missing a canonical tag. Show me the diff first and
explain what the tag does. Do not touch pages that should stay out
of search results.

Review each diff in the editor before you accept it. The agent finds the right file quickly but does not know your intent, so say which pages must stay private. Commit each fix separately so one bad change is easy to undo.

6. Deploy, audit again, then check by hand

A fix in the code is not live until you deploy it. Afterwards, run the audit again and ask for a comparison:

Run the audit again and compare it with the last one. Which issues
are gone, which remain, and did any new ones appear?

Then confirm one or two key claims yourself:

curl -sI https://example.com | grep -i -E "^HTTP|x-robots-tag|strict-transport"

What a good first run looks like

Keep the first run small. Set a page limit of 50, ask for errors and warnings only, and fix a single cause before you touch the rest. That gives you a short diff to read and a clear before and after. If the second audit shows the cause gone and nothing new, repeat for the next cause. If it shows new issues, undo that one commit and look at what the change affected. A slow, checked loop beats one large edit that you cannot review.

Keeping credentials out of the file

You do not need a key for the sign-in route above. If you use a token instead, for example in a headless setup, Cursor's documentation says config values support interpolation such as ${env:NAME}, which reads an environment variable. That keeps the token out of a file you might commit. Never put a real token in .cursor/mcp.json if the file is in your repository.

What the agent gets wrong

  • It reads the wrong output. Raw issues and the report differ. Name the report every time.
  • It overfixes. Not every notice needs action. Ask it to stop after errors and warnings.
  • It trusts its own edit. It may say a fix worked before it is deployed. Only the second audit settles it.

Where this fits

After the connection, the loop is the same in every agent. The full version, with the reasoning behind each prompt, is in how to run an SEO audit with Claude Code, and the command-line version for OpenAI's agent is in SEO audit with Codex. New to audits? Read the SEO audit checklist first. Setup for other clients is in the MCP docs, and audits use credits, explained on the pricing page.

Frequently asked questions

Can Cursor run an SEO audit by itself?

Not without a tool. It can read your project but cannot crawl your deployed site, so it needs an audit server connected over MCP.

Should I use the project file or the global file?

Use the project file when only one site needs the tool or you want a team to share it, and the global file when you want it in every project.

Is it safe to let the agent change my site?

Treat it like any contributor: review each diff, commit fixes separately and deploy yourself. The audit tool only reads your public site and reports.

Why does the agent say the site is fine when the report shows errors?

It probably read the raw issue list instead of the report. Ask for the audit report by name and compare.

Run the audit first

You can try a free audit without connecting anything, then connect Cursor once you want the agent to fix what is found.