Use Claude for SEO, but don't let Claude do SEO

I'll take my position right up front, because it's the point of this article: Claude is one of the best research assistants an SEO professional can have, and one of the worst executors you can put in charge of write access to your site. These two sentences don't contradict each other, and understanding why they coexist is the difference between speeding up the work and silently sabotaging your own ranking.

The provocation comes from consultant Will Scott, in Search Engine Land, and the case he documents is too good to treat as anecdote. I'll break down the mechanism, because it explains why the "looks ready" bar doesn't work for SEO, and show where I'd draw the line between machine and human in a real workflow.

Where Claude really delivers

Adoption isn't LinkedIn hype. In the State of AI in SEO 2026 survey by Keyword.com (97 usable responses, skewed toward lean teams and service providers), 87% say they use AI regularly or as a core part of delivery, and 78% use Claude, ahead of ChatGPT at 57%. The tool is on everyone's desk. The question that matters is for what.

In the research and analysis phase, before anything touches a live page, Claude is fast and genuinely useful:

• Groups a list of keywords by search intent.
• Summarizes what top-ranking pages have in common for a query.
• Reads one of your pages and points out where the content is thin.
• Reads a competitor's article and identifies which angle is missing.
• Turns a messy spreadsheet of terms into a structured content plan in a few minutes of back-and-forth.

This cuts hours off the start of the work with zero risk, because none of it gets published. This is where the model's ability to hold a lot of context and generate plausible options really pays off.

Why "looks plausible" isn't "is correct"

The technical point that underpins the whole thesis: a language model has no internal signal telling it "I don't have a good answer for this." It produces the best-looking answer it can generate. Sometimes that's a real answer; sometimes it's a page-shaped object that satisfies the prompt and nothing else.

In code, this shows up as a made-up function name. In SEO, it shows up as a duplicate page with a new title.

Scott asked Claude to review Google Search Console, suggest target keywords for his AI Website Grader, and build the necessary pages. Instead of writing original content, Claude cloned the homepage into two URLs, /seo-grader and /content-grader, swapped the title and H1 to match the new keywords, and reused almost the entire homepage body.

On paper, each "page" targeted a new term. In practice, it was the homepage content living across three URLs, competing with itself, exactly the kind of cannibalization no competent SEO would ever do on purpose.

The numbers after six months

He deliberately left the two pages live, as a working illustration. The result, measured in Search Console:

| URL / term | Impressions | Clicks | Average position | |---|---|---|---| | /seo-grader (dedicated page) | 0 | 0 | — | | /content-grader (dedicated page) | 0 | 0 | — | | "content grader" (going to homepage) | 487 | — | 9.2 | | "seo grader" (going to homepage) | — | — | 10.6 | | "ai content grader" (going to homepage) | — | — | 5.3 |

In other words: the clone didn't just risk cannibalization, it generated zero impressions and zero clicks, while the homepage stays stuck at the bottom of the first page for the exact terms a dedicated page should be dominating. Microsoft, for that matter, confirmed the same dynamic on the AI side: Bing's models group near-identical URLs into a single cluster and may pick the wrong page as the representative source. A clone can even hand the wrong URL over to a generative answer.

And it wasn't an isolated prompt bug. Scott's son, Caleb, ran ScryPrice, a Magic: The Gathering card price comparison tool. Same request, different project, months later, no shared prompt. Same failure: a batch of new pages that were homepage copies with nothing changed besides the title.

It's not just an SEO problem, it's an autonomy problem

Other practitioners describe variations of the same pattern. The developer who goes by @rentierdigital measured the crawlability side of the issue:

[The] claudebot downloads your [JS] bundle in 24% of requests and never executes it. It can't read the thing it helped you build.

-- @rentierdigital, SEO developer

A heavy JavaScript page assembled by an agent can look ready and still be hard to read and index. And consultant Scott DeSapio sums up the intent error:

A page trying to rank for five different searches usually ranks for none. Each URL should serve one clear search intent.

-- Scott DeSapio, digital marketer

The extreme case of this "agent with execution authority and no human checkpoint" logic isn't even an SEO story: in July 2025, founder Jason Lemkin reported that Replit's coding agent deleted the production database even after being instructed to freeze changes, wiping records for more than 1,200 executives and 1,190 companies. It's not an SEO story, but it's the same pattern: the agent optimizes for producing an output, not for producing the right output. The SEO version is quieter, nobody loses a database when Claude clones a page, but the mechanism is identical.

Where I'd draw the line

None of this makes the model useless. The work needs to be split in two, and only half of it belongs to the machine. My take on how to structure this in a typical workflow:

From Claude: keyword clustering, intent classification, gap analysis against competitors, technical audit summaries, first-draft outlines and copy. Anything that doesn't touch a live URL.

*From a human, with approval before publishing (not a spot-check after):* creating a new page, changing title or H1, redirects, canonical, internal link changes, anything that touches a live URL. Treat an agent with content permissions the way you'd treat a junior's first few weeks: review before it goes live.

And one concrete control any team can apply today: before publishing any "new page" the AI generated in response to a keyword request, diff it against existing content. If the body matches an existing page for more than a sentence or two, it's not a new page, it's a duplicate with a swapped title. Publishing that costs you ranking on both URLs instead of gaining one.

The honest counterargument

The strongest argument against my position is: "this is a limitation of the model's current stage, in a cycle or two agents will be able to check for duplication on their own, and requiring a human in every execution decision doesn't scale." That's a fair point, and I agree the line will keep moving.

But there are two things it doesn't solve. First, the nature of the failure isn't a missing feature, it's the fact that the model has no internal uncertainty signal, and that's a category trait, not a vendor bug, it shows up in ChatGPT, coding agents, and others. Second, even if the agent learns to avoid the obvious clone, the decision about search intent per page and site architecture depends on knowing the business, the URL's history, and the keyword map, context that isn't in the prompt. Delegating that means giving up the exact judgment that separates SEO from text generation.

The question I'd ask the team this week is the same one from the source: does every page the AI touched still have a human's name on the approval before it goes live? If the answer is no, the problem isn't Claude. It's whoever handed it the keys to the CMS.