SEO tools that live inside your coding assistant are a newer category than either "SEO tool" or "coding assistant". Claude SEO is one of them: a free, MIT-licensed plugin for Claude Code that turns the assistant into an SEO auditor. A plugin like that is only worth the findings it produces, so this guide is not a feature list. We ran two of its tools against a real, live website, wrote down what they reported, and then checked those reports by hand against the pages themselves.
The site we audited is this one, The Smart AI Stack. That is a disclosure and a method note at once: we could not pick a friendlier target, and every finding below could be checked against files we know by heart.
What Claude SEO is
Claude SEO is a plugin for Claude Code published by Daniel Agrici under the MIT licence, in two parallel versions: a public open-source release and an early-access community mirror. The version installed on our machine, and the one every plugin-sourced number in this guide comes from, is 2.2.4, whose README describes 25 sub-skills and 18 specialist agents. The public site currently advertises a newer release, v2.5.0, with different counts, so read the version badge before trusting any capability list.
Every browser screenshot below was captured on 2026-11-03 in a real browser, with optional analytics declined through the page's own consent control where one appeared. Two figures are formatted presentations of captured output rather than screenshots: the fetcher comparison (built from the two raw fetch results) and the content-quality table (built from the scorer's retained JSON result files), each labeled as such.
The plugin covers technical SEO, E-E-A-T, schema markup, sitemaps, Core Web Vitals, backlinks, local SEO, e-commerce, and generative-engine optimization, which is the practice of making a page the kind of source an AI assistant cites. It installs at user scope and adds slash commands. One honest scope note before anything else: this guide exercised two of the plugin's lower-level tools, not its orchestrated audits. What the full audit commands find on a site like this one is a question this guide did not test.
How we set it up and what we ran
The plugin was already installed on our machine at version 2.2.4, so this guide covers no install journey. Verification was direct: the plugin's own runtime manifest reported claude-seo, version 2.2.4, with the runtime state showing its browser component ready. No /seo setup step was needed for the parts we used.
The audit target was five live pages on this site, fetched through the plugin's page fetcher: the homepage, one blog article, one guide, the Runway review, and the Vietnamese homepage. We ran the plugin's content-quality scorer against each captured page, and we fetched robots.txt, sitemap.xml and llms.txt with the same tool. One command, one output each, nothing simulated.
Two things the fetcher turned out to be worth knowing. It has a --render flag (never, auto, or always) that delegates to a Playwright-based renderer for JavaScript-rendered sites. On this static site the two modes returned the same page, which is the expected result here and exactly the difference the flag exists to make on a client-rendered one. And on our machine the render path needed one missing Python package installed before it would run; a fresh install of the plugin may or may not hit that.
One limitation worth naming before any findings: the content-quality scorer reads the text of the HTML you give it. On a static site like this one the HTML is the product, so that is fine. A broken instrument fails toward absence, and absence agrees with whatever you were about to conclude; hand the scorer a JavaScript shell and it will grade the shell with the same confidence.
What the audit found, and what checking showed
The scorer's read of the five pages was consistent: content-quality scores of 88 to 91 across all five, with zero flagged filler and zero flagged AI-writing patterns. The one flag it did raise, on every one of the five pages, was its repetition dimension. Those are the scorer's own quality dimensions, a read of our prose, not an SEO ranking or an overall site grade. The useful part of the run came from what we did next, because each tool is an instrument and an instrument needs a control.
Two findings survived checking as real, one collapsed under checking, and one was a near-miss that ended in the site's favor.
Finding one, real: the sitemap grew past the documentation. The plugin's sitemap fetch counted 234 URL entries. The site's own documentation, written earlier in its life, said 95 indexable pages. We re-counted with an independent fetch, then broke the number down by locale: 78 English, 78 Vietnamese, 78 French. The site grew; the doc did not. A tool that makes the discrepancy visible in one command did its job, and the doc now needs updating.
Finding two, real, with its meaning corrected by the primary sources: llms.txt ships and lists the tool directory. The file is served at the root, names the site's positioning, and ends where the tool directory ends. What we first wrote about that file was too strong: we called it "the exact file AI assistants look for". It is more honest to say what the sources support. llms.txt is an open proposal for a machine-readable site map for language models, published in 2024, and whether any given assistant or crawler reads it is that consumer's choice, not a property of the file. Google's own documentation on AI features and Google Search says the opposite of "required": "You don't need to create new machine readable files, AI text files, or markup to appear in these features." So the finding stands as a serving fact (the file exists and says what it says) and as a check the plugin wraps, and the inference stops there.
Finding three, the one that collapsed: we first reported that hreflang lived in the sitemap but was missing from the page heads. That was wrong, and the instrument that failed was our own case-sensitive grep. React serializes the attribute as hrefLang, and a search for hreflang=" missed it. Re-checked case-insensitively, every sampled page head carries the full four-tag set: x-default, en, vi and fr, matching the sitemap's xhtml:link alternates on all 234 URLs. The site does hreflang correctly by both mechanisms Google documents. The audit finding worth keeping is about us, not the site: a case-sensitive search reports an absence that is not there, and a clean-looking negative is the most convincing false result an instrument can produce.
The miss: image alt coverage. On the Runway review, a hand-run count in the browser found two images whose alt attribute is empty. The content-quality scorer, which reads text, had nothing to say about them, because alt coverage is not in what that instrument measures. Those images turn out to be decorative brand monograms sitting inside anchors that carry full text names, the accessible pattern our own image rules require, so the near-miss ended in the site's favor. But the near-miss is the lesson: what one tool measures is not what a page is.
What the tools got right
The strongest thing the two tools did was also the least glamorous: they produced findings we could check, and the checkable ones held. The sitemap count was right. The llms.txt content was right. The hreflang half of the run that the fetcher surfaced (the alternates in the sitemap) was right, and it was our own negative claim about the heads that failed verification.
The content-quality scorer also did something subtle and correct: it scored the Vietnamese homepage the same way it scores English, 90 against the homepage's 91, without treating either as anomalous. A tool that flags a non-English page as "low quality" is a tool that will waste an afternoon on a multilingual site.
Where the tested tools have limits
Four limits, each from this run rather than from the feature list. None of them is a verdict on parts of the plugin we did not run.
The scorer audits what you hand it. It read the exact HTML we fetched and passed judgment on nothing else. It measures text quality dimensions: filler, AI-writing patterns, information density, repetition. It does not evaluate metadata, hreflang, or anything else a full audit command might reach, and it did not see the alt attributes at all.
The tested tools do not make judgement calls, which is exactly why a human remains in the loop. When a check surfaces something, deciding what it means for your site, what to fix, and what a fix is worth is the part that stayed with us. The plugin's documentation commits to recommendations grounded in primary sources; the commitment we could verify in this run is narrower: the tools report facts, and the interpretation is yours.
No first-party search data was analyzed in this audit. The plugin's Google APIs skills read Search Console, CrUX and GA4. We did not run them, so this guide says nothing about rankings, impressions, clicks, or any traffic outcome for any site, including ours. Absence of that measurement is the guide's limitation, not a finding about the site.
They are not fixers. They find and report. The plugin has opinions about what to fix, but the fixing, and the decision about which fixes are worth a change to a working site, stayed with us.
Can it help with AI search and GEO?
The honest answer from this run: the checkable half of generative-engine optimization is mechanical, and these tools check it. Machine-readable files, sitemap hygiene, citation-ready passages, semantic HTML: those are verifiable, the tested tools verify some of them, and Google's own documentation on AI features describes the inputs as ordinary indexing: technical eligibility, crawlable content, textual content, matching structured data. "There are no additional requirements to appear in AI Overviews or AI Mode." No tool can promise an AI Overview citation, and we found no claim in the plugin that it does.
What the plugin adds over a checklist is that it runs the checks where the content lives. On this site the machine-readable layer, the sitemap, the source ledgers: these are build artifacts a plugin can verify against the same repository that produces them, which is a genuinely better loop than exporting a site and auditing a stranger's copy of it.
Who should use it
If you already run Claude Code and you maintain a site whose HTML you can serve or export, Claude SEO is a low-cost addition: free, MIT-licensed, and it turns questions like "is the sitemap consistent with reality" into one command. If your site renders entirely in the browser, use the fetcher's --render modes rather than judging the plugin by raw-HTML runs: the renderer exists, and on this static site the two modes returned the same page and the same link set, though their serialized outputs were not byte-identical.
If you need rank tracking, backlink intelligence at scale, or anything the paid API tiers provide, this is not that product, and its own docs point at optional extensions for live data rather than pretending otherwise.
The verdict we would give a colleague: useful, cheap, honest about what it measures, and best treated as a set of instruments rather than an authority. Every finding the two tools produced here was a lead that a human confirmed, corrected, or in one case disproved, which is exactly what we ask of any tool we would let near a page a reader acts on.
Notes on method
Every figure in this guide is from the session that wrote it, November 2026. The plugin version tested is 2.2.4; the plugin's public site advertised v2.5.0 on the day of capture, and the two versions' capability counts differ. The audit ran against the live production site, and every browser screenshot above was captured that same session in a real browser, with optional analytics declined through each page's own consent control; the fetcher comparison and the content-quality table are formatted presentations of the raw captured output, labeled as such. The page-source checks, the sitemap recount, the hreflang comparison and the alt-attribute audit were run by hand, separately from the plugin, so that the guide's conclusions rest on two instruments rather than one. Our methodology page describes why that habit matters more than any score.