Claude Code SEO: Wire the Loop, Not Another Skill Pack

Claude Code is already good at the SEO work that touches files: rewriting a title to match the query it ranks for, deepening the section that half-answers a search, adding an internal link with honest anchor text. What it can't do on its own is pick which page to touch, or tell you whether the edit worked. Both of those answers live in your Search Console data.

Neither arrives by installing another skill pack. What follows is the loop that actually closes, the wiring gotcha that makes an agent quietly ignore data you just connected, and the line past which its judgment stops being worth trusting.

TL;DR:

• Claude Code owns the editing step by default. Reading your real numbers and checking the result afterwards are the two halves you have to wire yourself.
• Skills and MCP servers aren't competitors. Anthropic's own split: "MCP connects Claude to data; Skills teach Claude what to do with that data."
• Tool count is the wrong axis. One popular pack ships 25 sub-skills and 18 agents. That's capability, not a decision about your site.
• When a skill and a tool cover the same job, the skill tends to win, because a procedure written into the prompt outweighs a tool description sitting in a list. That's how a working connection ends up unused.
• No amount of wiring lets the agent see the competing results page or anything past the click. Every edit stays a bet you measure.

What can Claude Code do for SEO on its own?

It executes. Give Claude Code a file change with a clear target and it's genuinely strong: rewrite this title, add the missing answer to this section, link this page from three related ones. It reads the repo, makes the edit, runs your tests. That half of SEO work needs no setup at all.

The half it can't do unaided is the half that decides. Your agent has no idea which of your 200 pages is bleeding clicks this month, because that fact isn't in your codebase. It's in Search Console. And the gap is not a Claude Code weakness so much as a missing input, which is why bolting on more instructions doesn't fix it.

A Search Engine Land walkthrough of a real agency workflow lands on the same seam after wiring up Search Console, GA4, and Google Ads: "Claude Code is reading your data and finding patterns across sources faster than you can manually. It's not telling you what to do about those patterns." That's the honest state of the default setup. Fast reading, no verdict.

So the loop worth building has four steps, and most setups only cover one. Read your own data. Decide the single change with the most upside. Make the edit, which is the part Claude Code was already good at. Then check whether the numbers moved, which is the step almost everyone skips.

Skills or an MCP server: which one does what?

They do different jobs, and Anthropic draws the line cleanly: "MCP provides a standardized way to connect Claude to your tools and data sources," while "Skills are folders containing instructions, scripts, and resources that Claude discovers and loads dynamically when relevant to a task." The one-line version from the same page: "MCP connects Claude to data; Skills teach Claude what to do with that data."

Read that against the four-step loop and the division of labor falls out. A Skill is procedural knowledge, so it's the right home for your own conventions: how you write a title, which pages are money pages, what your team does before shipping a change. That's knowledge Google doesn't have and your repo does.

An MCP server is connectivity, so it's the right home for anything live: your clicks, your ranking queries, your indexing state, all of which changed since yesterday and none of which can be baked into a folder of markdown. Anthropic's own recommendation is to stop treating this as a choice: "Use both together: MCP for connectivity, Skills for procedural knowledge."

The practical read is that if your SEO setup is all skills, you have a very well-informed agent reasoning about a site it can't see. If it's all connectivity, you have live numbers and no house style. Most people notice the second gap and miss the first.

Does a bigger skill pack make a better SEO agent?

Not by itself, and the open-source packs are better than this question makes them sound. AgriciDaniel's claude-seo runs "25 sub-skills and 18 specialist agents in parallel" across technical SEO, schema, and AI-search optimization, it's MIT licensed with "no per-domain pricing, no telemetry," and it reads Search Console through OAuth or a service account. It's a serious piece of work and it costs nothing.

mxfschr's claude-code-seo takes a different shape: "a 26-section knowledge base distilled from the most credible practitioners, plus 9 slash commands that turn it into live audits against your real Google Search Console and DataForSEO data." Note what the second half of that sentence concedes. The knowledge base alone is not the product. It becomes useful when it's pointed at live data, and that pairing costs real money on the SERP side, at "$0.02 to $0.18 per command run."

So the number to compare isn't sub-skills or slash commands. It's what happens after the pull. Twenty-five skills reading a 25,000-row export still hand you twenty-five ways to look at it, and looking is not deciding. The useful question about any pack is whether it ends on a ranked answer: this page, this change, this reason, checked on this date.

Tool count also has a cost people underrate. Every extra endpoint is another thing the agent can call and another turn it can spend fetching instead of concluding. The trade-offs behind choosing a Search Console server come down to the same three axes, and none of them is how many tools it exposes.

Why does the agent ignore the server you just connected?

Because a skill and a tool aren't weighted the same way. A skill's instructions land in the prompt as a procedure to follow. A tool arrives as a description in a list, passive metadata the model weighs against everything else. When both cover the same job, the procedure usually wins, and the live connection sits there unused while the agent does it the old way.

We hit this ourselves, and it's worth naming precisely because the symptom looks like nothing at all. The setup had older skills that read Search Console the manual way, by downloading an export and parsing it locally. After wiring in a live connection to the same data, the agent kept reaching for the export procedure. Nothing errored. The answers were just quietly staler than the data sitting one call away, and no log anywhere said so.

The fix wasn't more tooling, it was one line of precedence in the repo's own rules: when the live connection is available, it is the data source, and the export procedure is not to be used. That resolved it, and the general shape is worth stealing. If two things in your setup can do the same job, say which one wins, in writing, somewhere the agent reads every session.

This is also the strongest argument against installing several overlapping SEO packs at once. Three skills that each know how to audit Search Console don't give you three opinions. They give you whichever one the model happened to weigh highest, with no indication that the others existed.

Where do you put an instruction so the agent follows it?

Not everywhere is equal, and the ranking surprises people. Guidance in a tool's output is read on every single call and can never go stale. Rules in your repo are read every session. An MCP server's own instructions string is the weakest of the three, because of exactly when the protocol delivers it.

The specification is explicit that initialization "MUST be the first interaction between client and server," and the server's reply to that initialize request is where the optional instructions field travels. It's handed over once, at connect time. The spec defines change notifications for tool lists, via a listChanged capability, but there is no equivalent for the instructions string. So it's fixed for the life of the connection: update it on the server and every already-connected editor keeps running the old copy until someone reconnects.

That gives you a rule of thumb worth writing on the wall:

• Guidance that must always apply goes in the tool's output, where it rides along with the data it's about and updates the moment you ship.
• Your house conventions go in the repo rules, where they apply to every tool and survive any reconnect.
• Anything in a server's instructions should be treated as a hint that might be a version behind, not as a control you can rely on.

There's a related honesty problem the output is the right place to carry. Search Console's query table always under-reports, because Google drops rare queries from it for privacy while still counting them in your site totals. An agent handed those rows with no warning will happily add them up and report a number that can't reconcile. The honest handling is to take volume from the page level and treat the query list as intent, and the tool that returns the rows is the only thing positioned to say so every time.

What can't the agent do, however you wire it?

Three things, and no configuration reaches any of them. It can't see the competing results page, so it can't tell you why the pages above you are above you. It can't see anything past the click, so it can't connect an edit to a signup. And it can't confirm its own reasoning, which is why the Search Engine Land piece pairs its workflow with a blunt instruction to "trust but verify" and "spot-check the numbers against the source data."

There's a fourth limit that only shows up later. Search Console keeps a rolling 16-month window and then deletes, with no backfill. An agent reading live sees only what Google still has, so "did this change work" quietly becomes unanswerable for anything older than the window. Keeping a longer view means snapshotting the data forward before Google drops it, which is a job someone has to actually run.

None of this makes the workflow not worth building. It makes the fourth step non-negotiable. If the agent can't prove the edit worked, the edit was a bet, and a bet you never settle teaches you nothing on the next one.

So how should you wire SEO into Claude Code?

Wire the two ends, not the middle. The middle, making the change, already works. Give the agent a live read of your own Search Console so it decides on real numbers instead of guesses, keep your house conventions in the repo where they apply every session, and settle in writing which source wins when two of them overlap. Then check the result on a date you picked in advance.

That's the shape QueryScope ships: your own Search Console connected to your editor over MCP, returning a ranked answer about which page to fix first rather than rows to sort out, with the history kept past the point Google forgets it. If you'd rather run the server yourself, the open-source packs above are free and good, and the loop matters more than who hosts it. Either way it reads one machine, search traffic, and stops at the click. Any metric in here that reads oddly is defined, with the caveat that makes it misleading, in the Search Console glossary.

Sources

• Anthropic, Skills explained: How Skills compares to prompts, Projects, MCP, and subagents ("MCP provides a standardized way to connect Claude to your tools and data sources"; "Skills are folders containing instructions, scripts, and resources that Claude discovers and loads dynamically when relevant to a task"; "MCP connects Claude to data; Skills teach Claude what to do with that data"; "Use both together: MCP for connectivity, Skills for procedural knowledge").
• Model Context Protocol specification, Lifecycle (initialization "MUST be the first interaction between client and server"; the initialize result carries an optional instructions field; listChanged is defined as a capability for prompt, resource, and tool list-change notifications).
• Search Engine Land, How to turn Claude Code into your SEO command center ("Claude Code is reading your data and finding patterns across sources faster than you can manually. It's not telling you what to do about those patterns"; advises users to "trust but verify" and spot-check against the source data).
• AgriciDaniel, claude-seo (open-source SEO skill pack for Claude Code: "runs 25 sub-skills and 18 specialist agents in parallel"; MIT licensed, "no per-domain pricing, no telemetry"; reads Search Console via OAuth or service account).
• mxfschr, claude-code-seo ("a 26-section knowledge base distilled from the most credible practitioners, plus 9 slash commands that turn it into live audits against your real Google Search Console and DataForSEO data"; "GSC API: free. DataForSEO: prepaid credit, $0.02-0.18 per command run").