Use Claude for SEO, Don’t Let It Do SEO

Give AI execution authority and it produces what looks finished, not what’s correct. The fix isn’t a better model, it’s a loop around it.

A client challenged my recommendation with a screenshot this month. The screenshot was confident, well written, and produced by a session that had never seen the site.

Will Scott’s piece in Search Engine Land this week shows the mechanism underneath: give an AI execution authority and it produces what looks finished, not what is correct.

The fix isn’t a better model, it’s a loop around it. Memory, tool access, meeting transcripts, a verification checklist and a learning mechanism. Plus ten SEO MCP servers I verified myself this week, and the WebMCP support OpenAI just shipped.

This week’s topic didn’t come from the news, it came from the consulting desk. A scene that keeps repeating: I present a recommendation with the reasoning and the dated data behind it, and I get back, “But I asked Claude, and that’s not what it says.”

The first time it happened I wanted to defend the recommendation. Then I looked closer and realised the client wasn’t wrong, the question was being asked in the wrong place. That chat window had never visited the site, didn’t know what was agreed in last month’s meeting, had no idea which page makes the money, and nobody had audited its answer. But the answer looked confident and read beautifully. Grab your coffee.

The thesis: it’s not the model, it’s the loop

AI is genuinely strong at research and analysis. The trouble starts when you give it execution authority: it produces what looks finished rather than what is correct, and it does so with total confidence.

The fix isn’t swapping models, it’s building a loop around one. Memory, tool access, meeting records, a verification checklist, a learning mechanism. Without those five, an SEO analysis done in a standalone chat window is not decision-grade.

The case: the cloned homepage

Will Scott’s piece this week says it in the title: “Use Claude for SEO. Don’t let Claude do SEO.”

On his own site, Scott had the model read Search Console data, asked it for target keywords, and told it to build the pages those keywords needed. Instead of writing purpose-built content, the model cloned the homepage into two new URLs and changed nothing but the title tag and the H1. On paper, two new pages. In practice, the homepage’s content living at three URLs, competing with itself.

He left those pages live on purpose. Six months of Search Console data: zero impressions, zero clicks. Every query they were built to win still goes to the homepage, and the homepage sits at the bottom of page one for those exact terms (“content grader,” 487 impressions, average position 9.2).

One case and we’d call it a bad prompt. The same failure happened months later on a completely different site run by someone else, with no shared prompt or workflow between them. Scott’s own framing is honest, and worth keeping: this is not one vendor’s bug, it’s a category problem with autonomous AI execution.

Why it happens

There is no signal inside the model that says “I don’t actually have a good answer to this.” It produces the most plausible-looking output it can generate. Sometimes that’s a real answer, sometimes it’s a page-shaped object. Reshaping an existing page is faster and, from the model’s perspective, lower risk than generating genuinely differentiated content.

Let me add my own observation, because this is the one I catch most often in client work: a standalone chat window will tell you it visited a page it never visited. With no browser access, all it has is training data and probability. When a client puts that output on the screen, we’re arguing with a guess that has seen nothing.

The fix: not a chat, a loop

Start with Anthropic’s own definition: a loop is an agent repeating cycles of work until a stop condition is met. The Claude Code team splits them into four types: turn-based, goal-based, time-based and proactive. Boris Cherny, who leads that team, put it like a manifesto: “I don’t prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.”

Two pieces of guidance from that same post land directly on SEO: split the agent that checks from the agent that does the work (a model grading its own output is too generous), and when a result misses the standard, don’t just fix that one instance, encode it so the system improves for every future run.

The five layers

• Persistent memory. Open commitments, decisions already made, pages that must not be touched, all in one file. Every session starts by reading it. This is the single biggest gap in a chat window.
• Tool access. Search Console, analytics, a browser, a crawler. The rule is blunt: if a number doesn’t come from a live source, that number does not exist.
• Meeting memory. We use tldv.io’s MCP connection, so transcripts flow straight into the client’s project folder. The reason behind an SEO decision usually isn’t in a spreadsheet, it’s in a sentence someone said two months ago.
• A verification checklist. An itemised list that runs before delivery in a checker role, with an “audit it, don’t defend it” instruction, ideally in a clean session that sees only the deliverable and the list.
• A learning mechanism. Every client correction produces three things: a dated lesson entry, a matching new checklist item, and an update to the affected scheduled task. All three, every time.

Let me open up layer four, because it’s the one most often skipped. The instruction at the top of our checklist reads: “You are in the checker role. Audit the output against this list, do not defend it. Independently reproduce every number and every count. Append the result to the deliverable: how many checks passed out of how many, plus any failures and their fixes.” That last sentence matters. If you don’t force it to write out the result, the model says “checked” and moves on.

In layer five the lesson format is fixed too: date | source, mistake / rule / impact. The file is append-only; nothing is ever deleted. Without this layer the other four erode. The third time you make the same mistake, it means the system isn’t remembering it, you are.

Ten SEO MCP servers I verified

The connection standard for the tool layer is MCP (Model Context Protocol), the open standard Anthropic published in 2024. I verified all ten below one by one, and I’ve written down how I verified each. Rows marked “live” are tool counts I personally counted in my own client on 28 August; rows marked “vendor” come from the provider’s own documentation.

Three honest notes. There is an MCP for Bing Webmaster Tools, but it isn’t an official Microsoft product; the “40+ tools” figure doing the rounds belongs to a community build. Tool count isn’t quality: a 180-tool server isn’t better than a 19-tool one, it’s just wider. And don’t connect all ten; keeping every server open slows the model down with long tool lists on every command. Starting with two and growing is easier than starting with ten and pruning.

We use Semrush MCP most. But it isn’t enough on its own, because it gives you market data, not the truth about your own site. Alongside it we always run Search Console (first-party truth), GA4 (conversions), Screaming Frog (technical truth), browser access, and meeting transcripts.

One last rule: traffic numbers come from one source only. Putting two different tools’ two different traffic figures in the same report is a loss of trust the loop manufactured itself.

The other end opens up: WebMCP

We build MCP on our side. On 27 August the other end opened up: OpenAI added WebMCP support to the browser inside the ChatGPT desktop app.

With classic MCP you connect a server. With WebMCP, the page being visited offers tools to the agent itself. A site registers JavaScript functions as tools, complete with names, descriptions and structured input schemas. In OpenAI’s words: “Instead of leaving agents to guess their way through your UI, you define exactly how they can use your app.”

This one is personal for me: the WebMCP check has been in our GEO score cards since June. The Agentic Browsing section in PageSpeed Insights measures registered WebMCP tools and missing declarative definitions on forms. On nearly every site we audited the result was identical: no registered tools. Until now that wasn’t a gap, because nothing consumed it. This week something does.

Without overselling it: the specification is a W3C draft, not on the standards track. It needs GPT-5.6 Sol or Terra, and it isn’t available in Enterprise or Edu workspaces. The documentation draws no connection to rankings, citations or discoverability; if someone tells you “add WebMCP and AI will recommend you,” ask for the source. OpenAI also flags data exfiltration and prompt injection risks in its own documentation.

Don’t rush to implement it today. Do open PageSpeed Insights and look at your site’s Agentic Browsing section: if your accessibility tree is incomplete, those results are already making agent access harder, entirely independent of WebMCP.

My own data: what a loop actually looks like

One client project’s memory layer, as of 25 August. No client name, no client data, just the loop’s own measurements: a 34-section state file, 25 dated lesson entries, a 79-item verification checklist, 12 scheduled task definitions. Roughly 292 KB of project memory in total.

The KB count isn’t the point. Two examples are.

The checker caught the maker. On 11 August the weekly report was produced and the checklist was run in checker role. Across two passes it caught 17 defects. They were fixed before the report reached the client.

And this one is the same species as Scott’s case. The lesson entry dated 19 August is titled: “A closed task is not a shipped page.” Five pages had shown as complete on the board across three sprints; a live check said otherwise. The cloned homepage and the closed task are two faces of the same illness: looks finished versus is finished.

My favourite item on the list came out of that: every countable claim is re-verified live immediately before delivery. An inherited number, even one labelled “verified,” is not evidence.

That list didn’t reach 79 items in a day. Behind every item is a mistake somebody made. The virtue of a loop isn’t avoiding mistakes, it’s never making the same one twice.

Let me not polish this too much. On 20 August, item 5 on the checklist (owner and due date on every action line) was followed exactly, and that is precisely why it produced a defect: the text in question wasn’t a report, it was a comment reply going out in my own voice, and the result was sentences referring to me in the third person. The rule was right, the reader was wrong.

The lesson: a loop doesn’t protect you from mistakes, it makes them cheap and stops them repeating.