A typical SEO audit export is a spreadsheet with a few hundred rows: "Missing canonical (18 pages)," "Duplicate title (11 pages)," "Orphan page," "Redirect chain." Pasting that into Claude Code, Cursor, or Codex with "fix these" usually goes badly. The agent edits the wrong template, "fixes" a warning that didn't matter, or changes robots.txt in a way nobody reviews.
Coding agents are good at SEO fixes because most technical SEO problems are template problems, and a template is code. The trick is the translation step between the audit and the agent. This post is the process I use.
Not every SEO finding is a coding task. Before anything goes to an agent, I sort the list.
Delegate to the agent (deterministic, lives in code, easy to verify): Missing, duplicate, or self-contradicting rel="canonical" tags Duplicate or empty and meta descriptions produced by a template Leftover noindex (meta tag or X-Robots-Tag header) on production routes Sitemap problems: wrong host, non-canonical URLs, URLs that 404 or redirect Internal links pointing at redirects or 404s Redirect chains (A→B→C) that should be a single hop Missing or invalid JSON-LD (Organization, SoftwareApplication, BlogPosting, BreadcrumbList) Missing alt attributes on content images, and heading-level order in components
Do it with the agent, but decide yourself (code changes that encode a business decision): robots.txt rules, especially for AI crawlers Which URL is canonical when two pages overlap Redirect maps after a URL restructure hreflang sets
Keep away from the agent (not code problems): Content quality, search intent, and topic gaps Backlinks and authority Anything that's really a keyword-strategy decision
The first bucket usually covers most of what a technical audit flags. The second bucket is where an agent can do real damage if you let it decide on its own.
Audits report symptoms per URL. Agents fix causes. "Missing canonical on 18 pages" isn't 18 tasks. It's usually one layout or one generateMetadata-style function that never sets a canonical. Before writing tasks, look at the affected URLs and ask what they share: a route pattern (/blog/[slug]), a layout, a CMS content type.
One task per cause keeps diffs small and reviewable, and it stops the agent from patching 18 pages one by one, which you'd then have to maintain.
What each part does: Evidence stops the agent from "fixing" something that isn't broken. If it can't reproduce the evidence, it should say so. Likely cause is a hint, not an order. Agents are good at confirming or correcting it once they open the file. Scope is the most important line. Without it, agents tidy up nearby code, and that's how a canonical fix turns into a 40-file diff. Acceptance criteria are what you'll review against. Make them observable in rendered HTML, not in source code. Verify gives the agent a way to check its own work before handing it back.
Rules that apply to every SEO task belong in the repository, not in each prompt. Codex and Cursor read an AGENTS.md file in the repo. Claude Code reads CLAUDE.md, and you can pull in a shared file from there with an @AGENTS.md import line. I keep the SEO rules in one place:
That last rule matters most. It turns "looks right" into a command with an exit code.
SEO bugs live in the HTML a crawler receives. A diff can look perfect while a parent layout overrides the canonical, or a client component injects a second . So the check should fetch real pages. Here's a small standard-library Python script I give agents (and use myself). It takes a file of URLs, fails on missing or duplicate canonicals, canonicals pointing elsewhere, noindex, redirects, error status codes, and titles duplicated across pages:
Run it against a local production build (npm run build && npm start) with a URL list that covers one page per template, then again against production after deploy. List URLs in their canonical form. A trailing-slash mismatch counts as a failure on purpose, because it's a real inconsistency.
It's deliberately narrow. It doesn't judge title wording or content. It checks the invariants an agent is most likely to break.
Even with good tasks, review SEO pull requests more strictly than ordinary UI changes, because mistakes are quiet. A wrong canonical or a stray noindex doesn't throw an error. It slowly removes pages from search. What I look for: The diff stays inside the stated scope. No changes to robots.txt, redirects, middleware, or sitemap generation unless the task asked for them. The verification output is pasted into the PR description. Structured data passes Google's Rich Results Test for one example URL.
After deploying, re-crawl the affected URLs and use URL Inspection in Search Console on one or two of them. Search engines take days to weeks to reprocess changes, so judge the fix by the HTML now and the rankings later.
Most of the work above is translation: turning "18 pages missing canonical" into one scoped, verifiable task. That's the part I got tired of doing by hand, and it's why I built Siteory. It audits a site for SEO, AI-search readiness, and security, and every finding comes with evidence and a fix prompt you can paste into Claude, Codex, Cursor, or OpenCode. Paid reports also export Markdown files like prioritized-fixes.md. It doesn't edit your code. You review the change, ship it, and re-scan.