SEO Audit With an AI Coding Agent: A Pre-Launch Check That You Can Prove Worked

You have built the product and the launch is close. A checklist tells you what to set: a title, a description, a sitemap. It cannot tell you whether those things reached the live site. An AI coding agent is good at the first half, reading your code and fixing templates. It cannot see what Google receives from your server, so it needs an audit tool for that and you need a few commands to double-check it.

This guide covers the whole loop for a small site, which is the case most launches fall into.

Disclosure: this guide features Auditmatic, an SEO audit tool built for AI coding agents. Every manual step below works without it, and it points out where an agent gets things wrong.

Quick answer: connect an SEO audit tool to your coding agent (Claude Code, Codex or Cursor all work over MCP), ask it for the audit report, fix one cause at a time, deploy, then check the live site yourself with curl. The check on the live site is the step most checklists skip, and it is the one that catches a staging noindex still switched on in production.

What the Agent Can and Cannot See

A coding agent reads your repository. Search engines read your deployed site. The two differ more often than you would expect, and the differences are where launch problems hide.

That table is the reason for the loop in this guide. The agent edits the left column. You need to measure the right one.

Step 1: Connect the Tool to Your Agent

Any agent that supports MCP (a standard way for an AI agent to call tools) can use an audit server. Here is the setup for three:

Claude Code

claude mcp add --transport http auditmatic https://auditmatic.app/mcp

Then run /mcp inside Claude Code and sign in.

Codex CLI

codex mcp add auditmatic --url https://auditmatic.app/mcp
codex mcp login auditmatic

The first command adds the server to ~/.codex/config.toml as a streamable HTTP entry. The second opens the browser sign-in; OpenAI documents codex mcp login for servers that use OAuth. Run codex mcp list to confirm it is there. Headless setup, config options, and Codex-specific pitfalls are in the SEO audit with Codex guide.

Cursor

Add this to .cursor/mcp.json in your project, or ~/.cursor/mcp.json for every project:

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

Cursor's documentation says remote servers sign in with an OAuth flow. If your Cursor version words the sign-in differently, trust the screen over this page. Troubleshooting a server that will not connect is covered in the SEO audit with Cursor guide.

You need a site that is live on the internet for any of these, because the crawler reads the public site. A server running on your laptop cannot be audited.

Step 2: Record a Baseline Before You Change Anything

Ask for the audit and keep the result. A before-number is what makes the after-number mean something.

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.

Two details matter. Say "audit report," because a raw list of issues and the report can differ; an agent that reads the raw list instead can call a site nearly clean while the report shows real errors. And say "do not change code yet," so you can read the findings first. Save the score and the counts in a note with today's date.

Step 3: Rank What You Find

A launch site rarely needs every finding fixed. Use two questions:

1. Does it block a page from search at all? A leftover noindex, a robots rule that blocks the site, a redirect loop, a server error. These come first even if they touch one page.
2. How many pages share it? One template fix can clear dozens of pages. Do these next.

Single-page polish such as a description a little too long comes last. If you want the full ranking method, see what to fix first in an SEO audit.

Step 4: Fix One Cause at a Time

Fix the pages flagged for a missing canonical tag. Show me the diff and
explain what the tag does before you apply it. Do not touch pages that
should stay out of search results.

The last sentence is not decoration. An agent does not know your intent. A thank-you page with no links is fine, but a model may add links to it anyway rather than leave it alone. A common example: a crawl flags a signed-in app page as having no outgoing links, when the page is not broken, it is an app screen with nothing to crawl. The right response is to mark every signed-in route noindex with a response header, not to add links. The guide on pages with no outgoing links covers how to tell a real dead end from a false alarm.

Read each diff, then commit each fix on its own. A small labelled commit is easy to undo if it breaks something.

Step 5: Check the Live Site Yourself

This is the step that proves the work. After you deploy, run these against production. They take about a minute.

# 1. Does the page return 200, and is there a noindex header?
curl -sI https://example.com/ | grep -i -E "^HTTP|x-robots-tag"

# 2. Is a noindex tag in the HTML?
curl -s https://example.com/ | grep -i -o '<meta name="robots"[^>]*>'

# 3. Is robots.txt blocking the whole site?
curl -s https://example.com/robots.txt

# 4. Is the canonical tag pointing at your real domain, not localhost or staging?
curl -s https://example.com/ | grep -i -o '<link rel="canonical"[^>]*>'

# 5. Do http and www redirect to one address?
curl -sI http://example.com/ | grep -i -E "^HTTP|^location"
curl -sI https://www.example.com/ | grep -i -E "^HTTP|^location"

What a pass looks like: status 200, no noindex anywhere, a robots.txt that does not say Disallow: / for everyone, a canonical on your real domain, and every variant redirecting to one address.

The staging traps these catch

One distinction trips people up. robots.txt controls crawling; noindex controls indexing. Google's documentation says a page blocked in robots.txt can still end up indexed if other pages link to it, and that a noindex rule is only seen if the page can be crawled. So to keep a page out of results, use noindex and do not also block it in robots.txt. The two Google pages on this are robots.txt introduction and block search indexing with noindex.

Step 6: Audit Again and Compare

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

New issues after a fix are common, because a change that removes one problem can create another. A first audit might score 96 with 5 errors, all missing security headers, which one change in one place fixes for every page. The second audit then scores 99 with no errors, and the remaining warnings are small, such as a homepage description a little too wide for search results. Read the errors before you read the score: the score moves a few points while the real risk falls much further. The full loop is in how to run an SEO audit with Claude Code, and the same steps apply to Codex and Cursor.

A Note on Single-Page Apps

If your product is a client-rendered app, the first response from your server may contain very little HTML, and what a crawler sees can differ from what you see in a browser. Google documents how it renders JavaScript in its JavaScript SEO basics. The practical test is the curl check from step 5: if the page text and links you care about are not in that output, render them on the server for the pages that matter (your homepage, pricing, and anything you want found). Signed-in screens can stay client-rendered.

What This Will Not Do

Be realistic about the limits, because most launch advice is not.

• It does not tell you whether you are indexed. Only Google Search Console does. Verify your site there, submit your sitemap, and use the Pages report to see what Google has and has not indexed.
• It does not promise rankings or a timeline. There is no trustworthy figure for how long a new site takes to appear. Record your baseline, then watch Search Console over weeks.
• It does not replace choosing what to rank for. An audit checks the technical state of pages. What your pages should say, and for whom, is still your call.
• The agent can be wrong. It will sometimes say a fix worked before the change is live. That is why step 5 exists.

Frequently Asked Questions

Try It

If you want to run the audit step on your own site, Auditmatic has a free audit at auditmatic.app, and the agent setup is in the docs. The technical checks are also laid out in the technical SEO audit checklist. Whatever you use, the order is the same: baseline, fix, deploy, check the live site, audit again.