Claude Code SEO: The Agent That Edits Your Site, Not Your Drafts

Search “claude code seo” and most of what comes back is prompt roundups: paste your draft into Claude and ask for meta descriptions, generate ten title variants, brainstorm keywords. All of it treats Claude Code as a typewriter with opinions — which misses what the thing actually is. Claude Code is Anthropic’s terminal agent. Its native abilities are reading files, editing files, and running git. And on a modern website, that list happens to describe almost the entire surface of SEO — because your title tags, canonicals, sitemap, robots rules, redirects, and structured data are not settings in a dashboard. They are lines of code in a repository.

That is the reframe this guide commits to: Claude Code does not assist with SEO, it turns SEO into repo work — find the problem in Search Console, edit the real source files, open a pull request, and verify the movement in Search Console weeks later. This is the hands-on spoke of our Claude for SEO pillar: not what the model can write, but what the agent can ship.

Your SEO problems are files

Walk through what an SEO audit flags and where each item actually lives on a framework site. The weak title on your money page is a generateMetadata export. The duplicate URLs splitting your signals are a canonical rule in one layout file. The pages Google never found are an entry missing from app/sitemap.ts. The staging block that shipped to production is one line in app/robots.ts. The rich result you are not getting is a JSON-LD component that drifted out of sync with the page. None of these are marketing artifacts. They are code, versioned in git, editable in seconds.

The traditional workflow ignores this. A tool finds the problem in a browser, a marketer writes it up in a ticket, a developer picks it up two sprints later, and nobody re-checks the number afterward. The finding was instant; the shipping took a month; the proving never happened. That gap is not a talent problem — it is what you get when the people who find SEO problems and the people who can edit the files live in different tools. A coding agent that can query Search Console and edit the source collapses the gap into one session.

What Claude Code needs: evidence it can query, files it can edit

Out of the box, Claude Code running in your website repo has the hands but not the evidence. It can read every template, but it cannot know which query sits on page one earning nothing, which pages Google shows but nobody clicks, or what the competing results look like. That knowledge lives in Google Search Console and in the SERPs — outside the repo, behind APIs.

The bridge is MCP, the Model Context Protocol — the open standard, introduced by Anthropic, that lets Claude Code call remote tools as naturally as it reads local files. Connect an MCP server that exposes your Search Console data and a shared task board, and the agent suddenly has both halves of the job: it can run a GSC query to find the underperforming page, grep the repo for the template that renders it, edit the file, and record the whole transaction on a board that outlives the session. How that server is built — scopes, tools, the board as system of record — is the subject of the sibling guide on MCP servers for SEO; the practical wiring is a single claude mcp add command, covered in the connect guide.

The loop, end to end: find, edit, PR, verify

Here is the whole mechanism, run as one continuous motion instead of four disconnected jobs. It is the concrete implementation of the find → fix → verify cycle our closed-loop SEO guide describes in the abstract — with Claude Code as the hands at every step.

1. Find — the evidence comes from Search Console

The agent queries GSC over MCP for the patterns worth acting on: queries ranking on page one with a click-through rate far below what the position should earn, pages with impressions and no clicks, striking-distance queries hovering at position eleven, URLs the sitemap declares but the index ignores. On a site we audited, a commercial query sat comfortably on page one and earned almost nothing — the title Google was showing was a template default that said nothing a buyer would click. No crawler flags that; the evidence only exists in the query-level Search Console data. Each finding becomes a task with the metric that will judge the fix committed in advance: this one is a CTR problem, so CTR will be the judge.

2. Edit — the fix is a diff, not a suggestion

Now the part no dashboard can do. The agent greps the repo for the route, reads thegenerateMetadata export or the layout that produces the weak title, and edits it — in the real file, in the style of the surrounding code. Template-level bugs get template-level fixes: one edit to a layout file corrects every page that layout renders, something a page-by-page CMS workflow cannot express. The same motion covers schema components, canonical logic, internal links, redirects — the whole repo-first audit surface.

3. Ship — the pull request is the review gate

The agent branches, commits, and opens a PR whose description carries the evidence: the query, the numbers that flagged it, the expected impact, the metric that will verify it. A human reviews the diff and merges — or pushes back. Nothing lands silently. The merged PR does double duty: it ships the fix and it timestamps it, and that timestamp is what the verification clock runs from. The task flips to done with the PR URL attached.

4. Verify — Search Console renders the verdict

About three weeks later — enough time for a recrawl and for fresh query data to accumulate on both sides of the change — the committed metric is re-read on the exact query the task named. It moved and held: confirmed, and the site now has one proven fact it did not have before. It moved the wrong way: regressed, and the task reopens with better information. It cannot yet say: inconclusive, an honest null. A weekly monitor does the re-reading, so no human has to remember thirty verification dates.

Why the PR makes this safer, not slower

The reflex objection to an agent editing your website is risk — and it has the risk exactly backwards. Compare the failure modes. A CMS bulk edit or a plugin’s “auto-optimize” toggle changes pages with no diff, no reviewer, and no clean way back. A pull request is the opposite of all three: every change is a readable diff, a human approves it before it exists in production, and git revert undoes it in one motion. The PR workflow that software teams adopted precisely because unreviewed changes burn you is the same gate that makes agentic SEO trustworthy.

An agent that suggests is safe and useless. An agent that ships silently is useful and dangerous. An agent that ships through a pull request is both useful and reviewable — that is the entire design.

The gate also fixes something subtler: attribution. Because every fix is a merged commit with a timestamp, the question “what changed and when?” — the question that makes most SEO retrospectives dissolve into shrugs — has an exact answer. Verification is only as good as the record of what shipped, and git is the best change record ever built.

Claude Code vs. Claude in a chat window

The same model sits behind both, which is exactly why the comparison is clarifying: the difference is not intelligence, it is agency. A chat window can reason about SEO brilliantly and still leave every finding stranded on your side of the glass — you carry the insight to the CMS, you remember to re-check, you are the loop. Claude Code with MCP access is the loop.

What this honestly can’t do

Four limits, stated plainly. First, the loop needs its data: without Search Console connected over MCP, Claude Code is auditing blind — it can read every file and still not know which of them matters, because importance is a property of queries, not code. Second, verification obeys the physics of the data source, not your sprint cadence: Search Console’s own reporting lags by roughly two days, recrawls take days more, and a fair before-and-after needs impressions on both sides — read the number at day five and you are grading noise. Third, run honestly, a real share of fixes will verify inconclusive, especially small hygiene changes; a system that confirmed everything would be lying to you.

Fourth — and this is the one the prompt roundups get wrong in the other direction — repo access does not make content strategy free. An agent that writes articles without SERP evidence produces confident, well-formatted guesses. The writing loop has its own discipline — a teardown of what already ranks, an outline that beats it, scoring gates before anything ships — which the Claude for SEO pillar maps out across the cluster. The same caveat applies to sites that are not repos at all: a hosted CMS with no source access falls back to crawl-based tools and API integrations, which work, but give up the template-level leverage that makes the repo path so efficient.

How to set it up

The working setup is four steps, and none of them is exotic. Install Claude Code. Open a terminal in your website’s repository — the same one your developers work in. Connect an MCP server that exposes your Search Console data and a task board (one command, then authenticate). Then ask it to work the board: find, edit, PR, and let the monitor read the verdicts. From that point the constraint is no longer how fast findings can be shipped — it is how good the findings are, which is where the agent’s access to real query data compounds cycle over cycle.

If you want to see the find half run against your own property first, the free SEO report connects your Search Console and surfaces the queries where shipping a file edit would actually move a number — page-one rankings earning nothing, pages shown and never chosen. And if you would rather the whole loop ran for you — agent, board, PRs, and the three-week verdicts — book a call and we will walk through it on your data.